BMO/UserRoles

From MozillaWiki
< BMO
Jump to: navigation, search

Improve User Workflow in BMO

User Roles

  • Generate different user roles based on what tasks a user is trying to complete when using the BMO system.
  • Possible roles could be:
    • Triager: Someone who spends most of their time trying to determine if bugs are valid, if any additional information is required, and placing the bugs into the correct product/component to get the proper attention.
    • Community Member: Someone involved with using the various products/projects and submitting feedback/bug reports when encountered. They are people who maintain their bugs and make sure that Mozilla has enough information to ensure a proper fix/change.
    • Administrator: Manages the day-to-day duties of making sure that BMO has the proper products/components/versions/milestones/etc. needed for users to find the right place to report their bug. Also is involved with updating permissions for those requesting more access.
    • Patch Reviewer: Normally an engineer or someone well versed in the project's code and inner workings that will review other's patches for anything that can be improved. They would need a helpful UI for viewing the patch, making comments on specific lines/sections, and then setting the proper flags to let the author know the status of the patch. Once the patch is reviewed (r+) they can then pass it off the the proper person to commit.
    • Patch Committer: Once a patch for an issue/feature has been reviewed, the committer (who may be same as reviewer) is responsible for overseeing that the patch is committed to the proper project branch and also that it doesn't cause any regressions. This could be through the Try service or other means of automated building. The patch committer could then possibly pass off to QA to let them test the fix/feature once a new build is available containing the change.
    • And possibly others.

Defining Roles in BMO

  • We would need to figure out how to determine one's role within the scope of data stored in the BMO database.
  • Could be based on groups?
    • Certain groups are required to confirm "canconfirm" bugs, edit "editbugs" other's bugs.
    • Other groups are required to set certain flags such as blocking/tracking/status.
    • Admins normally need even higher groups for editing users, products, etc.
  • Could also based on statistics, how many patches the user has committed, reviewed, etc. How many bugs the user has closed that were not their own.
  • We could come up with an entirely new storage format for defining roles using a BMO extension and custom tables. Then manually (or in an automated way) figure out who would go into which role. BMO could then use that data to change the UI and make other suggestions when viewing a bug report based on the role.
  • With custom tables, users could take on more than one role.
    • Also can switch between them. Could use stats to suggest roles.
  • Simpler route would be to just provide a drop down on the show bug page that would switch the views from for example, 'standard' to 'triage', and then remember the selection for the next page load.
    • This could be done for the first iteration and then refined for more roles later. Triage should be our first goal.
  • Determine using feedback from the different groups what changes need to be done for the page based on role selected.
    • Hide/display certain fields
    • Provide shortcut links to perform common tasks (Next Actions (tm)).

BMO Tool Enhancements Per User Role

  • Triager:
    • We should think of ways to improve the Triager's workflow by providing enhanced bug views providing shortcuts to common changes. Creating custom reports allowing a triager to make changes to bug reports more efficiently. Add support for canned comments so that they can reuse past comment text quickly without having to re-enter each time.
  • Community Member:
    • Provide better documentation on how to create good quality bug reports.
    • Enhance BMO to help direct the user to the right product/component. Guided bug entry has done a good job of this and we can improve other areas in a similar way.
    • Enhanced emails stating what will probably happen next to their bug report and how to keep an eye on its progress. Maybe describing once a bug has been resolved, how to best obtain a binary or new version that may contain the fix/enhancement.
  • Patch Reviewer:
    • Reviewers will need a top quality review tool for managing patches within BMO that need their attention. Utilizing the Dashboard, the user could then see which patches they need to look at in order of importance. Then from the dashboard, go directly to the review tool where the user would be able to approve the patch, mark it up with comments and/or kick it back to the author to be revised.
    • Currently BMO uses Splinter for reviewing patches. It is a goal of Q3 to update Splinter (or replace) to fix some of the outstanding issues with the tool. Splinter has issues with parsing certain patches and needs to have the parsing part split away and handled by server side PatchReader. Also BMO devels are looking at replacing the overlying javascript code with codereview.js which has more features than Splinter and is more actively maintained by the Webkit community.
  • Patch Committer:
    • Once a patch has been reviewed and is ready for further attention, the patch committer user can then post the patch to an automated build system for actual testing. Part of the plans for BMO are to better integrate with the Try system using AutoLand. This will allow the committer role to tag approved patches and have them picked up automatically by AutoLand for submission to Try. AutoLand will then update the bug with the results of the Try run showing if it was a success, or failure and direct the user what to do next.
    • AutoLand is currently unmaintained and part of Q3 goals are to 1) take over ownership, move it to maintained hardware and work to fix an issues still outstanding or 2) work with RelEng who have shown interest in helping out and figure out how to get the system up to speed.
    • Some code already exists in BMO to support AutoLand but it not currently used.

Next Actions Ordered By Priority

  1. Talk to Releng about helping us with support of the AutoLand system and make sure that it becomes maintained properly by IT. Figure out what needs to be done on BMO to support the additional features needed by AutoLand and then get some testing and feedback from engineers.
    • Should start this discussion ASAP.
  2. Revive dkl's past canned comment work and revise for rolling out to production. Needs a couple things done to be production quality.
  3. Improve the current Splinter by fixing some of the smaller issues with regard to patch parsing. Then work toward separating out the patch parsing logic from javascript and use the built in PatchReader code instead. And then lastly, look into replacing Splinter with codereview.js making sure we keep feature parity with the current tool. https://wiki.mozilla.org/BMO/Splinter
  4. Implement user report similar to bugs.gnome.org that shows statistics about a user
  5. Add more detail to the Dashboard such as providing a review link to Splinter directly if an attachment review flag has been requested. Show a list of bugs that have not been acted on after a specified period of time or possibly need to be closed. Show a list of recently visited bugs for the user to get back to quickly.
  6. Work with Byron to decide on how to best implement user roles in BMO and figure out how to migrate people to the proper roles (mozillians.org?).
  7. Work with Triage to decide on how we can improve the current bug view and what documentation could be improved to make the bug report better informed. Also see what statuses/keywords/etc. can be added/changed to make it more apparent that a bug is ready for a developer to look at (think: READY state).
    • Latter is hopefully being solved right now in the "Making CanConfirm default to UNCO state" discussion.
    • Great first role since lizzard is sorting out triage processes right now.