Following up on our brainstorming sessions at the JS work week, I'd like
to get your feedback on SpiderMonkey's priorities and document them in
an ordered list that we can use as our "moral compass". :)
Below I also propose a lightweight planning process to keep our focus
trained on those project priorities.
EXAMPLE LIST OF PROJECT PRIORITIES:
1. Chemspill bugs
2. sec-crit bugs
3. Release tracking bugs: Beta
4. Release tracking bugs: Aurora
5. Release tracking bugs: Nightly
6. topcrash bugs
7. Crashes and assertion failures
8. Misc regressions
9a. Firefox OS performance
9b. Games Initiative
9c. Dev Tools
9d. Firefox features and performance
9e. ES6 features
10a. Shumway
10b. Technical debt?
11a. Infrastructure debt like intermittent orange tests?
11b. sec-high bugs
11c. fuzzblockers?
11d. tsan bugs
11e. ES7 features?
For a lightweight planning process, I propose a stack of three bug
buckets. No sprints or iterations or standups.
* P1: bugs that are currently being fixed or investigated
* P2: bugs that someone thinks should be fixed soon-ish
* Everything else: new, old, low-priority, or ignored bugs
In Scrum terminology, the P1 bucket is like a Sprint Backlog ("fix now")
and the P2 bucket is like a Product Backlog ("fix soon").
Every two or so weeks, a "SpiderMonkey High Council" (i.e. anyone the
feels like showing up with an opinion) meets to review the current state
of SpiderMonkey. The 20 or so most important bugs (including feature
work) are given Priority P1 and assigned to an owner. Bugs to be worked
on soon-ish or to be reconsidered for P1 at the next meeting are given
Priority P2. Here is an example wiki dashboard (using live Bugzilla
data, separated into various categories) that could be useful for bug
triage:
https://wiki.mozilla.org/User:Cpeterson
In an ideal world, P1 bugs would preempt all other bugs, but the real
world is more complicated. Critical new bugs can just be set Priority P1
immediately and worked on as needed. Between meetings, anyone can set an
interesting bug as Priority P2 so it will be reviewed at the next meeting.
The JS team has used whiteboard tags like "[js:p1:fx31]" in the past,
but I suggest using the Priority field because it prevents typos and,
because it is not very configurable, it also discourages process
bikeshedding. :) Everyone understands when P1 means, even though very
few Mozilla teams seem to use the Priority field. And unlike whiteboard
tags, the Priority field can be safely changed en masse by Bugzilla's
"Change Several Bugs at Once" feature.
The Firefox desktop team has adopted a similar workflow, but they have
added custom flags and permissions to Bugzilla and are using Scrumbugs
to track iterations. Maybe we can get 80% of the value with 20% of the
process?
https://wiki.mozilla.org/Firefox/IterativeDevelopment
chris
_______________________________________________
dev-tech-js-engine-internals mailing list
[email protected]
https://lists.mozilla.org/listinfo/dev-tech-js-engine-internals
