[Bf-committers] Suggestions for improving the triaging process

[Sybren A. Stüvel]

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 at 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 at blender.org
> https://lists.blender.org/mailman/listinfo/bf-committers