Page MenuHomePhabricator

Guideline (for triagers) to avoid cookie-licking of tasks
Closed, ResolvedPublic

Description

It would be useful to have a written guideline to address tasks assigned to someone for years without any reported activity, usually with a priority that doesn't reflect the reality either, like "Normal".

Someone like @Aklapper, whose job is to keep Wikimedia Phabricator in good shape, does remove assigned users from tasks and does reset the priority accordingly. However, for occasional triagers having such guideline would be useful, to be certain about when such action is appropriate and avoid potential discussions.

Event Timeline

Qgil raised the priority of this task from to Needs Triage.
Qgil updated the task description. (Show Details)
Qgil subscribed.

If I was to add a section about cookie-licking (assigned to on open tasks field not changed for ages) for triagers specifically, I'd probably add it somewhere in

Bugzilla offered querying for open tickets with no assignee change for 12 months. The Phabricator search UI does not (see list of queries I'm missing).

Teaching assignees (=developers etc) to keep their plate clean is another target group. I hope that's easier now that the default Maniphest frontpage shows your assigned tasks but I don't think that a guideline would solve the problem (I believe more in pinging the folks on their tasks with a stock answer that I had in Bugzilla).

Changing the priority value based on inactivity is a related topic; could also be covered on above pages but hard to generalize IMHO as you don't want to mess up "this is more important than that". No simple rule like "triagers can decrease the high priority after 12 months of no activity in a task".
Need to also check how other priorities are used in that project and not destroy a "but that task was really more important than the other task and now they both have the same priority).
Ironically I did decrease some priorities last night in some volunteer projects (mostly WLM) by moving nearly every open task one priority level down.

A subset of these tasks are tracking bugs, which usually take a long time to resolve. I'm not sure whether it is worth mentioning this in a guideline, but should tracking bugs have an assignee at all? See for instance T3932: [DO NOT USE] ENotif/EConfirm & further enhancements (tracking) [superseded by #MediaWiki-Email].

In T85446#947156, @Qgil wrote:

In general the assignee on tracking bugs has little effect. In this case, it's fine because it tells you one person with knowledge on the topic: that assignee is the person who introduced the feature and most of the code is still the original one, plus he does care about the product.

Aklapper renamed this task from Guideline to avoid cookie-licking of tasks to Guideline (for triagers) to avoid cookie-licking of tasks.Feb 5 2015, 10:15 PM
Aklapper set Security to None.

Note that https://phabricator.wikimedia.org/maniphest/report/ offers "Oldest (All)" and "Oldest (Pri)" columns per assignee, but that refers to the creation age of the ticket and not to the time that went by since setting an assignee...

Rough explanation (ping after 12m without assignee activity) that seems to be clear enough added to https://www.mediawiki.org/w/index.php?title=Bug_management%2FHow_to_triage&diff=1397208&oldid=1345699

Decided not to mention on Bug management/Triage tasks because it's not a specific task that someone be gone for (as there are no queries in Phab).

Thanks for the "How to triage" addition!