Issue Tracker process improvements

[Andy-Block]

There are a few things I’d suggest could be improved with the bug reporting process:

1. I often find after a bug report is accepted and reproduced, multiple releases are made that don’t mention the issue either in their ‘Known Issues’ or their ‘Fixes’ section. For example: Unity Issue Tracker - Crash on WriteSerializedAssetsV2 when (re)entering the Play Mode in a specific project when IEnumerator Start() is used. This was reported against 6000.0.7f1, and reproduced against 6000.0.13f1. Yet the release notes of 6000.0.14f1 and 6000.0.15f1 make no mention of it. This gives the feeling that the bug is completely forgotten about. Is there a reason why the issue doesn’t show up in those release notes? I could imagine, for example, that it might be because the issue relates to a separate package rather than Unity core; if that’s the case, it woud be really useful if that information could be provided on the issue (apart from anything else so that developers can look out for updates to the package that might fix the issue).
2. Giving some kind of clue about the expected time frame for a fix would be really helpful. Even if it is of the nature of “this is bug 1250 out of 3249 on our priority list”. It’s frustrating not having any clue when it might be fixed (and then trying each new release on the off-chance that it got fixed accidentally / quietly).
3. Could something be done about the spammy comments also found in the above issue? The same user seems to have posted this nonsense on numerous issues without anything being done about it. Shouldn’t there be some kind of reporting system for this? I know this has been raised multiple times in the past over many years. If no reporting system is added, what is the best channel for getting such spam removed?

Yours hopefully,

Andy

[makaka-org]

1. I observed the same experience.
   –
   Moreover, sometimes there are lines in release notes without a link to issue tracker (kinda internal bugs and even not internal). Is there any reason to hide the link?
   –
   Subscription to the status of bug with Email notifications is a feature that I’m really looking forward to. For now, I need to manually save the link to it and monitor periodically because it is removed from the voting list silently when status changes to some values.

2. I guess this is useless because 1250 out of 3249 means that this issue error may take several years to fix, as it often happens.

[Whatever560]

I do find both your suggestions interesting.

Regarding

1. Giving some kind of clue about the expected time frame for a fix would be really helpful. Even if it is of the nature of “this is bug 1250 out of 3249 on our priority list”. It’s frustrating not having any clue when it might be fixed (and then trying each new release on the off-chance that it got fixed accidentally / quietly).

versus

I guess this is useless because 1250 out of 3249 means that this issue error may take several years to fix, as it often happens.

If it ever was possible that would be interesting. I don’t know if it fits there own internal process though. It should probably be 1:1 with them, but any indication of progress/prioritisation/triage would be welcome.

As I recall however, when someone in unity pickups a bug they’ll first report to the issue owner through the atlassian tracker. Also, I believe and hope so, because of confidentiality reasons.

[makaka-org]

@Whatever560

As I recall however, when someone in unity pickups a bug they’ll first report to the issue owner through the atlassian tracker.

Exactly, but without public showing at the 1st stage. So anyway, email subscription is available only for the author of issue, which is not flexible in the public showing stage.