Page MenuHomePhabricator

Get rid of Triagers for now
Closed, ResolvedPublic

Description

The idea behind the Triagers project is to offer the simplest defaults for task creation and editing to new/casual users, leaving more advanced options to whoever joins Triagers with their own feet.

Problems to this approach that we have seen so far:

  • Not easy to discover, even if it is in the homepage and documented, since just too frequently users just dive in into task creation & management.
  • This policy may be triggered (kind of accidentally) in situations where we actually want to allow non-Triagers users to perform a task, for instance, creating a new task under certain circumstances (T576).
  • Ugly error message about lack of permissions, not informing of how to solve the problem.

Since we have more than enough before the Phabricator launch, one possibility is just to get rid of the Triagers idea, moving closer to Phabricator defaults, and also to Wikimedia defaults. We would set the "Can Assign Tasks", "Can Prioritize Tasks", and Can Bulk Edit Tasks" Maniphest policies to "All Users". "Can Edit Task Policies" would still be out of the reach of users by default, with a custom policy of its own.

We can revisit this scenario if any problems arise in the future.

Event Timeline

Qgil created this task.Oct 8 2014, 11:14 AM
Qgil updated the task description. (Show Details)
Qgil raised the priority of this task from to Normal.
Qgil claimed this task.
Qgil added projects: Bugzilla-Migration, Triagers.
Qgil changed Security from none to None.
Qgil added a subscriber: Qgil.
Qgil reassigned this task from Qgil to Aklapper.Oct 8 2014, 11:19 AM
Qgil added subscribers: mmodell, Aklapper.

@Aklapper, your opinion as bugmaster is required. :)

The only reason not to propose this directly and open a task is that we need to add here the perspective of the new users that will join us after the launch. @mmodell and other people here now will most probably agree without hesitation, and I can see their point, but the sample of users we have right now is very biased toward advanced users, de-facto triagers.

I don't really buy the UI simplicity argument here, but it seems to me that a real advantage of a Triagers group is to have a more explicit set of group norms and conventions around bug triage, rather than just exposing a sensitive field to the user without asking them to understand the process and policies for setting priorities, assignments, etc.

Right now it's framed as "Join this project to change the UI" which is odd, but if we actually use this as a way to define norms and conventions, announce bug triage days, etc. IMO it could be very valuable. But yeah, up to our esteemed bug wrangler.

Qgil added a comment.Oct 8 2014, 2:05 PM

if we actually use this as a way to define norms and conventions, announce bug triage days, etc. IMO it could be very valuable.

Just for the sake of experimentation, I just enforced a "Phabricator etiquette" at http://phab-01.wmflabs.org for anybody willing to use the "advanced options". All users can create and edit tasks, comment, CC people, and add projects. However, if you want to get to the business of prioritizing and assigning tasks, then you need to read and sign the etiquette.

@Qgil That's an interesting approach, I continue to be impressed that these kinds of things are even possible. :)

He7d3r added a subscriber: He7d3r.Oct 8 2014, 2:23 PM
luser added a subscriber: luser.Oct 8 2014, 2:48 PM
This comment was removed by luser.
chasemp added a subscriber: chasemp.Oct 8 2014, 2:48 PM

@Qgil, I think there are overlap issues with the right to assign and manage status on tasks (mark as resolved, etc). i.e. without the right to assign tasks no one can manage task states as it must be calling it under the covers. Or at least that was my experience when poking at this for the triagers issues last night.

Qgil added a comment.Oct 10 2014, 3:53 PM

I have been creating, assigning, and prioritizing several tasks in phab-01 combining actions of a user without Bugzilla Etiquette agreement signed and one having signed it. The options seen by each user were always consistent, and I couldn't trigger any error message.

Considering the non-trivial amount of drama we have got over the years in Bugzilla with prioritization (less or no problem with assignment of bugs), maybe it is not a bad idea to make people agree explicitly to the etiquette if they want to enter that game. It is a workflow more predictable than joining a project in order to get permissions.

(Also, I have been thinking secretly if anybody has tested what happens when you add 2606 users to a single project) :)

HOWEVER, if you are not comfortable about trying a Legalpad-based experiment right now, I would understand. If this is the case, we can do two things:

  1. Test the same rounds in phab-01 forcing joining Triagers instead of signing the Etiquette, hoping that we get the same results (I don't see why not, but who knows).
  2. Remove Triagers, focus on Day 1, bring back the topic later.

I'll defer to @Aklapper on the social aspect but I think for the moment my vote would be to open things up

revi added a subscriber: revi.Oct 15 2014, 10:43 AM
hashar added a subscriber: hashar.Oct 16 2014, 8:07 PM

Could we have a use case of a project only allowing the product owner / project manager to set priority ? Wondering whether that can be enforced.

@hashar I believe that the maniphest policies are global and not per-project. We did some custom coding for the security project feature, however, having per project fine-grained policies would be quite a bit of effort to develop.

"Triagers" seems to mean "Advanced users" now in our context so while I liked trying the original idea, the meaning has eroded a bit. To summarize again, the main idea was to simplify the interface for users but the disadvantages (T576) are obvious now so I'd also lean towards killing Triagers for the time being. So let's open up.

As Mukunda wrote in T576, "If we want to hide something for the sake of form simplicity then we should look into simply hiding it rather than adjusting permissions based on project. I could surely come up with a fairly simple way to streamline the default form while leaving the permissions untouched and also leaving the edit form alone for advanced users to poke at."
Wondering which criteria we could base a "display: none" CSS hack on (or such) for the Priority and Assignee fields. I've seen three Bugzilla instances with custom code which link to a "guided bug entry form" with less complexity by default (and offering the normal bug entry form with all fields as 'advanced' instead). That's done by either looking up in the user database whether a user has only recently registered in the issue tracker, or checking for missing 'editbugs' group membership (which we don't have as such in Phabricator).

Refering to a strict understanding of triagers in the sense of a Bugsquad and social aspects brought up: I reached out ~18m ago to some active Wikimedia triagers, trying to resurrect https://www.mediawiki.org/wiki/Project:WikiProject_Bug_Squad. I learned that folks do not want to officially become part of such a project because it could create expectations on their activity. If you find a different spin, please share it... I've seen other FOSS organizations but I'm not aware of any really trying to institutionalize membership in a Bugsquad or Triage Team. Most of the time only heads of such teams are defined (via meritocracy), if at all.

In T583#11412, @hashar wrote:

Could we have a use case of a project only allowing the product owner / project manager to set priority?

That wish (enforcing certain social behaviors via technical implementations) was also brought up by at least two PMs in Bugzilla, being a bit tired of Priority field and reopen edit wars. I don't see any obvious improvement with regard to that specific problem, comparing Bugzilla and Phabricator currently, however many of such edit wars are also related to personal communication styles of involved people IMHO.

Qgil added a comment.Oct 17 2014, 4:24 PM

OK, let's get rid of Triagers now.

I still think it is worth considering the possibility of giving these permissions after making sure that the users understand how to use them, as suggested above in T583#9578, but I will open a new task to discuss that out of the scope of the Bugzilla migration, looking at the post-launch consolidation of Phabricator.

revi added a comment.EditedOct 17 2014, 7:19 PM

Refering to a strict understanding of triagers in the sense of a Bugsquad and social aspects brought up: I reached out ~18m ago to some active Wikimedia triagers, trying to resurrect https://www.mediawiki.org/wiki/Project:WikiProject_Bug_Squad. I learned that folks do not want to officially become part of such a project because it could create expectations on their activity. If you find a different spin, please share it... I've seen other FOSS organizations but I'm not aware of any really trying to institutionalize membership in a Bugsquad or Triage Team. Most of the time only heads of such teams are defined (via meritocracy), if at all.

Ubuntu has an official "bug squad" team, here.

Aklapper closed this task as Resolved.Oct 23 2014, 3:02 PM

On https://phabricator.wikimedia.org/applications/edit/PhabricatorManiphestApplication/ "Custom Policy" was set:

  • Can Prioritize | Allow members of {Triagers, operations, importbots}; Allow admins; If no rules match Deny all other.
  • Can Bulk Edit | Allow members of {security, Triagers, operations}; Allow admins; If no rules match Deny all other.

Now,

  • set both items above to "All users".
  • Archived Triagers project
  • Removed panel on default frontpage dashboard saying "Do you miss managing the Priority status field in tasks? ==== Join Triagers ===="

I feel some bellyache allowing anybody to bulk edit as the UI exposes that functionality way more than Bugzilla did.
If we face vandalism (see T84) we restrict again (and consider resurrecting Triagers)?

Qgil added a comment.Oct 23 2014, 3:11 PM

Maybe batch edits can be restricted to an invitation-only type of group, yes.

Related: T819: Restricting modification of tasks when they enter sprints