Disclaimer: the processes described here might change as the project evolves. We will update this page each time something changes. Audience: Anyone who is interested in participating in the SUMO project.

Confused by this?: Please contact the SUMO team.

Component owners and Tools

For each functional area of the SUMO project we have component owners assisted by back-ups. Their main responsibilities are:

Act as main point of contact and for their functional area.
Actively use and work with their functional area on a daily basis.
Act as component owners in Bugzilla for their functional area.
Are subscribed to the corresponding Bugzilla component and have an active role in responding to questions and clarifications in bugs.
Work with the Community Managers to drive conversations with the community related to their functional area.
Act as main drivers of projects that relate to their functional area.
Act as the ultimate decision maker (e.g. to accept or reject a proposed solution to a bug or to decide whether a bug can be closed).
Work with the PM to set the priority for each bug/user story , establish a timeline and get it into the next sprints.
Work with the PM to bring the attention of other component owners or stakeholders when questions cross functionality borders.
Are involved in all discussions and corresponding bugs which are directly impacting your functional area.

You can find a full list of component owners here

During a sprint

assignees to bugs for that sprint, move their bugs forward daily

Followup at the beginning of every marketing sprint

At the beginning of every marketing sprint (sprints last 2 weeks, so approximately every 2-2.5 weeks), the component owners should ensure that the bugs in their component are prioritized correctly and that all high priority bugs are moving forward.
All: Try to zero your needinfos at the beginning of every sprint. If you can't, ask for help or needinfo somebody else or leave the needinfo if it's a low priority bug. Needinfos shouldn't be a burden. More important to move the current sprint, high priority bugs forward.
All component owners: Once every six months (e.g. at All Hands) look at bugs that are: WONTFIX AND component: feature request or severity: enhancement and see if they need to be re-opened.

Q2 2017 Sprints

Sprint 3, starts May 15, ends Wed May 31, 2017
Sprint 4, starts Monday June 5, 2017

Q3 2017 Sprints

Sprint 1
Sprint 2
Sprint 3
Sprint 4

Do's

Bugzilla isn't a meta discussion area; if you want to discuss workflow or meta e.g. how to triage,
please DO post your meta/workflow issue in a contributor forum thread
Do assume positive intent. 99% people are great :-) ; it's really hard to communicate with a positive tone in online writing! Much easier to appear to be not happy or mis-interpret others as being unhappy.
Do be concise and if you have multiple requests or questions, numbering them and placing them in a summary aka 'tl;dr' section at the beginning of your contributor forum post or bugzilla comment would be lovely.
Do be positive; we are super lucky to be working on a great open source software project like Mozilla and Firefox.

Don'ts

Don't assign bugs to anybody if you aren't 100% sure the assignee agrees with your assignment and has time at the moment (^D)
Don't worry if low priority bugs remain unassigned; this leaves bugs for volunteers and new folks to tackle
Don't be a killjoy to new volunteers and users. New folks are great and don't have all the context and experience. Cheerfully and briefly help them and revel in the "beginner's mind"

Lithium specific stuff

If a Lithium support case needs to be filed for a bug:

If you know the bug needs a Lithium support case, please ask a SUMO staff member to file a Lithium support case for you. Triagers should be able to figure out if a Lithium support case is needed if you are un-certain.
Unfortunately however the SUMO staff triager will probably have figure out when it's appropriate to file a Lithium support case. It's not a line that's obvious to non SUMO staff or volunteers; the very hazy line is that anything that isn't fixable in Lithium settings needs a Lithium support case.

The SUMO staff member should:

File the Lithium support case and in the "Additional Notes" field of the Lithium support case link to the bugzilla bug which we like to call the "shadow" bug
In the bugzilla "shadow" bug:
- Add the case number to the bugzilla summary and whiteboard (^E) using the convention: [li-<case>] e.g. [li-00134461]
- Add a link to the case (e.g. https://supportcases.lithium.com/50061000009MCTs) in the bugzilla field: Details -> URL field
- As updates are received from the not-public Lithium case system, copy and paste them into the bug (at least the updates that are relevant)

NOTES

(^A) Component owners are SUMO employees for now, could be volunteers or other employees in the future
(^B) Is the component owner the triager? Are there more triagers? Answer: At the moment, the component owner is the triager for the component, and the backup component owner is the backup triager. Again fine with adding other triagers e.g. experienced volunteers and other employees in the future
(^C) Can we assume a perfect knowledge of the assignee's availability & issue fixing potential by the triager? A: Nothing is perfect, triagers do their best and if they can't figure it out they ask for help via needinfo or other methods
(^D) Does this increase the risk of a bug not being addressed in due time? A: only low priority bugs; unfortunately we don't have the resources to spend a lot of time on low priority bugs, if we had the people we could fix and focus on all bugs but that'll never happen in Mozilla :-)
(^E) What about other whiteboard keywords like "[1st2weeks]"? Answer: all other "pre-switchback-to-kitsune-temporarily" whiteboard keywords e.g. "[1st2weeks]" are obsolete. Got some ideas for useful whiteboard keywords (they are just free form "tags" like instagram or flickr tags)? Please email rtanglao AT mozilla.org or start a SUMO contributor forum thread.

Support:Project Management

Contents