Websites/Mozilla.org/Roadmap 2011: Difference between revisions

Jump to navigation Jump to search
m
No edit summary
Line 52: Line 52:
* [[Mozilla.org/Roadmap_2011/Q2|Q2]]
* [[Mozilla.org/Roadmap_2011/Q2|Q2]]


=Open Questions=
= Open Questions =


Is there an overview of what process we should follow when fixing bugs? How to nominate a bug for a milestone, when asking for QA, when to mark a bug as fixed in bugzilla, what are the new roles for trunk/stage/prod branches, stuff like that.
1. Is there an overview of what process we should follow when fixing bugs?  
 
2. How to nominate a bug for a milestone, when asking for QA, when to mark a bug as fixed in bugzilla, what are the new roles for trunk/stage/prod branches, stuff like that.  
 
3. How do we best handle "one-offs" - defined as changes tied to a moving date that falls between our scheduled releases? These will be fairly common; I'd estimate there will be 2 small "one-offs" every cycle.
 
Here's one good current example of what I'll officially name "The Case of the One-Off":
 
PMMs want a promo on the homepage to support Firefox Beta 9. Beta 9 ''probably ''goes live 5 days after our first scheduled site release. It's a very small task. There's enough of a business case to warrant precious webdev time. Now how do we: 
 
a) Flag this as a one-off and prioritize this in Bugzilla properly
 
b) Make sure this gets assigned to a webdev-er and that that developer properly works this one-off into their sprint alongside their normal scheduled programming
 
c) Budget for these so they stop feeling like favors. These are constant changes that happen when software schedules are unpredictable as they mostly are at Mozilla. These are different in nature than a patch. Perhaps we reduce the amount of bugs in each sprint in order to budget for two "one-offs" each cycle?<br>


=A Note On Naming=
=A Note On Naming=
Confirmed users
685

edits

Navigation menu