Why does Unity just close bug reports? Users contribute by sending bug reports and receive confirmation, only for these reports to be CLOSED as low priority. There’s no option to vote for priority, either. So why bother reporting bugs? They closed two successfully reproduced bugs this week that did not appear to be ‘very low priority.’ Why don’t they simply mark them as low priority or BACKLOGGED instead of closing them?
So they can lie about how little number of bug reports they get…
https://discussions.unity.com/t/942714
Suppose you have a system that receives bug reports. The more a given bug occurs, the more reports on that bug it will get. That means you can safely close bug reports at random, because that bug will be reported again, which means the more prioritary bug reports will stay and the lower ocurrences will go away.
I don’t think that’s the direct intention in this case, but it’s indirect due to:
-
It’s hard to triage bugs without reproducing and investigating first. That’s expensive, so expensive not even users will prepare a proper reproduction project.
-
Research is gold-mining, the bug could be a cosmic ray flip, or a treasure of knowledge to improve the engine and fix other bugs.
-
Researchers need focus, and being deep in a sea of bugs makes searching hard and it’s demotivating.
-
By the same randomness of research further engine developments will remove bugs… and introduce newer, so the bug landscape is always changing.
Mind telling us what these bugs are? Without knowing that we can‘t assess whether you have a point or not.
Most of my reports have been closed too. That‘s because most of them were either not reproducible, „by design“ or wontfix (somewhat understandably, eg one was graphics driver + windows standby mode related), or simply either a misconfiguration, misunderstanding, incorrect expectations, false assumptions or an issue with the project itself.
The latter is rather common given how much gets stuffed into a project and then you only need one (editor) script that works incorrectly. I mean there are editor scripts around that actually modify .meta or asset files via string replace and other such fudgeups.
That‘s why it‘s so important to try and reproduce the issue in a new project. Most of the time you can‘t. Unfortunately because it‘s so much extra work, most of the time it isn‘t done. So the entire original project gets submitted in the report which may not even work on someone else‘s machine (locally installed packages are not submitted for instance).
Don’t report bugs unless you have no other choice.
I always create bug reproduction examples and empty projects with cleared temp/library just to make reproduction. So you often just can open my repo and see it
For example, here are two of this week that are confirmed and marked as Won’t Do:
Unity now ignores “developer build” and does not compress it for webgl (ok, it can be low priority or by design, but not obvious)
My temp solution - to change server config for tests not to use gzip
The serialization can be broken in prefabs when assemblies used (I made a small project to show reproduction, I found this bug when my Render Features were broken on build.)
My temp solution - to reorganize assemblies.
Bugs usually have a workaround. But they are bugs and sometimes you can spend a day or two to locate Them. I think Unity team needs bug reports even if there is a workaround. I hope quality works like this
Would you mind sharing that? Sounds interesting and frustrating.
Sure, here is the example of reproduction project (it’s a part of outline for render graph, just as example, overlay):
it works in Editor,
Builded successfully,
Render feature is broken in build (it says that size of prefab is changed, tetsted on Mac OS Unity 6000.0b15, webgl, standalone)
The interesting moment that this bug can have different reproductions, and Unity confirms that the problem exists, but they do not solve it. The user does not get user friendly message of the reason of serialization error, just a question: “Did you use UNITY_EDITOR defs?”
Having been having my own problems with what feels to me has to be a bug, ive taken advice from frankly everyone and their dog.
Im prepared to accept i maybe am the cause, but, like so many of you, you have a clear issue, you send it in, and give clear either press run “whoop there it is” or, now do this and “whoop there it is” (yeah in a will smith voice)
you get back “I cant reproduce it” and maybe a picture… of not what you sent in… also, ive had a few where my careful instructions got changed, to well, not the same so yes, produce different results cos you aint doing what I said…
I have 3 which made it through to the inner bug team, but all 3, no matter how true they are are now in short rejected
so where does this leave us the users, well with something we cant get to work and no idea how to move forward
We start looking at other engines and frameworks. The licensing fiasco already convinced me to move on but I’ve only just started looking now thanks to having existing work projects in Unity.
I mean if it is not laziness then I do not know what is
A major bug I reported (a year ago or so) has also been closed today; I reopened it by asking for at least some explanation:
This is not cool.
Short term profit for stock holders.
Any question we can’t explain from an engineering/human point of view has the same answer, short term profit for “investors”.
Welcome to 21th century…
I got a bug closed as won’t fix today
Because 2023.2 is reaching EOL??
Ok, what about other Unity versions? Do I need to re-submit this on new version>
I got like 5 bugs closed with same message. The bugs were not actually closed, though, just the fix versions were changed, as the 2023.2 is now at last version, so fixes will only go to Unity 6 or LTS versions. So I guess in that case nothing to worry about.
“Under Consideration for 2021.3.X, 2022.3.X”
Sadly this may very well be true. This way they show to their supervisors that everything is going fine.
Having inexperienced product managers, barely any TPMs and I assume, no producers, while hiring TONS of junior coders, can have that effect.
You do understand that this is a very common excuse you get from programers who are trying to avoid responsibility right?
In my extensive experience, these things don’t originate from the floor-people. Or at least very rarely. These kind of things happens when there is a considerable pressure from upstairs, written or unwritten “Q&A” rule.
Not really.
Programmers responsibility? Idk who do you call a “programmer” but last I checked, they are usually the main work force of a software company, mainly at the bottom of the decision making hierarchy. They are not hired nor paid to take “responsibility”, they are hired and paid “to do”.
Unless… unity turned into a cooperative, horizontal organization and I didn’t notice?