Contribute/Coding/Triage: Difference between revisions

# Dramatically reduce triage and triage-followup friction. We're doing this in two ways: [https://bugzilla.mozilla.org/show_bug.cgi?id=1151745 minimizing the number of steps involved] and by polishing up Gijs' [https://github.com/gijsk/triage-helper triage-helper addon] so we can make adding whiteboard flags (regression-range-needed, etc) and followup boilerplate (can you reproduce with a clean profile, here is a link to how to do that, etc) a matter of a few clicks.

# Make it much easier for community members to become a part of the triage process. This is happening in [https://bugzilla.mozilla.org/show_bug.cgi?id=1153108 bug 1153108] that lets users grant themselves canconfirm permissions, surfacing that contribution avenue in Bedrock, and improving our training documentation.  

# Adding some keywords to Bugzilla and changing some processes so that bugs in-triage are not getting lost. [https://bugzilla.mozilla.org/show_bug.cgi?id=1154031 1154031] proposes to remove the "untriaged" components of Firefox::, Core:: and Toolkit:: and [https://bugzilla.mozilla.org/show_bug.cgi?id=1155386 1155386] proposes adding "in-triage" and "ready" status flags.

Having these things in place, we can then take advantage of Graydon's [https://github.com/graydon/triage triage helper] email tool that lets contributors sign up to triage X number of bugs over Y period of time. Graydon reports that this has been a very successful approach for the Rust community. To our back-of-the-envelope estimates - better numbers coming - the combination of an easier process, better tooling, better documentation and low-cost, low-touch involvement should let us get to a point where we can get our proverbial chins above the tide and keep them there.