Hey Philipp. All these proposals make sense to me.
Sybren On Mon, 23 Nov 2020 at 15:08, Philipp Oeser via Bf-committers <bf-committers@blender.org> wrote: > > Hi all, > there was some recent talk amongst triagers about some issues / open > questions in our triaging process. This mail tries to sum them up and bring > forth possible ways to improve here. > Feedback is welcome, everyone interested is also invited to join the new > https://blender.chat/channel/blender-triagers > > > Problem 1 - Many reports marked with "Needs Triage" are 'stuck' > ================================================================ > We already have guidelines on the triaging process such as > https://wiki.blender.org/wiki/Process/Bug_Reports/Triaging_Playbook > https://wiki.blender.org/wiki/Process/Help_Triaging_Bugs > https://wiki.blender.org/wiki/Process/A_Bugs_Life > But still, there are reports that are tagged "Needs Triage" longer than > desirable. > > Examples of these are > > *** No access to hardware/software needed to reproduce the problem *** > In order to find someone quicker who could be able to reproduce > hardware/software specific issues, it would be good to gather this > information somewhere. > ==> Proposal: The most obvious place would be the user profiles in > Phabricator where GPU (driver, OS, tablets, ...) could be stored, similar to > what **System Information** gives when reporting a bug > > *** It is a technical problem, but it is unclear if it involves a bug in > blender or the user's system *** > These come in many different flavors like "installation problems", "computer > administration problems", "user support questions", "driver issues", "system > configuration issues". > Often times, it can also take a bit of back and forth until it becomes > clearer if the issue is one of the above [in which case it could be closed]. > There might also be cases where only core developers can make that call. > ==> Proposal: Triagers responsibility to add more canned responses that cover > more of these cases. > ==> Proposal: Triagers responsibility to improve upon > https://docs.blender.org/manual/en/dev/troubleshooting > > *** It is unclear if the current behavior is a bug, a known limitation or > works as designed (but not in a user friendly way) -- or is a request *** > There are many cases where this is not easy to decide. For all of these > cases, it is generally already well covered by our existing triaging process > documents on how to act. > Issue is more getting to the point where it is clear enough to make the call > (often though only core developers can make that) > ==> Proposal: More communication amongst triagers, synergetic effects will > happen. For this, https://blender.chat/channel/blender-triagers was set up. > > For the cases where only core developers can make a call, this also led to > questioning the usefulness of the "Needs Developer to Reproduce" status. This > was rarely used and/or its meaning not clear. Instead, a status indicating > the handover of responsibilty from the triaging team to the module teams > would be needed. This should only be used appropriate triaging already took > place. > ==> Proposal: Add a "Needs Information from Developer" status (or even > better: rename the existing "Needs Developer To Reproduce" status) > > Problem 2 - Classification > ================================================================ > In practice, until now, the triagers did a lot of classification [setting a > task's subtype] in their daily work (and hopefully the majority of it was > actually "correct"). > According to https://wiki.blender.org/wiki/Process/A_Bugs_Life, this is a job > for the module owners and development coordinators though. This has also led > to confusion when triagers set something e.g. as TODO - because this would > add to the responsibility of a particular module without consent. > ==> Proposal: Refrain from setting task subtype (unless absolutely obvious or > prior approval was given [esp. TODO]) > > Problem 3 - report priority / schedule > ================================================================ > It was decided to align the ordering of reports to be looked at. > Since different strategies were used ("daily fresh reports first", "previous > day's reports first", ...), this led to an unbalanced impression of sharing > 'enjoyable' workload. > So while it might still make sense to have an eye on fresh reports as well to > catch bad bugs early on (esp. close to release), older reports should be > looked at first > ==> Proposal: Prioritize older reports more > > > If you actually reached the end of this: thx for reading! > _______________________________________________ > Bf-committers mailing list > Bf-committers@blender.org > https://lists.blender.org/mailman/listinfo/bf-committers _______________________________________________ Bf-committers mailing list Bf-committers@blender.org https://lists.blender.org/mailman/listinfo/bf-committers
