|
|
| Line 140: |
Line 140: |
|
| |
|
|
| |
|
| Component: Installer/updater | | === Component: Installer/updater === |
| Owner: Rob Strong or Add-ons team | | * Owner: Rob Strong or Add-ons team |
| Tasks: | | * Tasks: |
| | | * Build stub installers for Windows and Linux |
| Build stub installers for Windows and Linux | | * Change installer to pull locale pack from AMO as a separate download |
| | | * Figure out how locale updates need to work |
| Change installer to pull locale pack from AMO as a separate download | |
| | |
| Figure out how locale updates need to work | |
| | |
| | |
| </p>
| |
| Things we want to do - but not starting until higher priorities are done:
| |
| *TBD - add as things come up
| |
| <p></p>
| |
| Other common Themes that will be mixed in the backlog as they come up:
| |
| *'''UX:''' this tag is less a theme - more a marker so UX knows we need something from them on that bug- it often lives with other Themes and the UX comes off when we get the info. Unless it's a unique UX bug - then UX stays.
| |
| *'''error:''' bug we've seen come in that we prioritize along side Theme work - often not Theme specific.
| |
| *'''tech-debt:''' work to make development smoother (test harness, dev tools, documentation, etc.)
| |
| *'''metrics:''' work specific to improving visibility into the product - but not required for a feature
| |
| *'''investigation''' or '''watch:''' needs investigation or just watching to see if it's reproducible and get an idea of the impact / cause.
| |
| <p></p>
| |
| At this point we are wrapping up other project work, risk is that it will carry over beyond 40.3. Need to clarify/set expectations for Search Suggestion timelines/features.
| |
| <p> </p> | | <p> </p> |
|
| |
|
| Line 173: |
Line 156: |
|
| |
|
| <p> </p> | | <p> </p> |
|
| |
| =Product Backlog=
| |
| Work related to the ongoing development of Go Faster are collected and prioritized in the Product Backlog. The goals of the Product Backlog are to:
| |
| * Improve work prioritization, so the team is always working on the most important features.
| |
| * Simplify continual planning, so the plan matches reality.
| |
| * Improve visibility so that the stakeholders make the best decisions about the direction of the product (call out risks early, relative priorities, trade-offs)
| |
| <p> </p>
| |
| <p> </p>
| |
|
| |
| ==Triage Guidelines==
| |
| The Product Backlog is continually maintained by the Go Faster team to ensure new priorities are available for each Sprint Planning meeting.
| |
| * '''Priorities''' follow this Standard:
| |
| ** Priority 1 - Blocker, must-fix before shipping.
| |
| ** Priority 2 - Major impact, considering severity × probability. Not a blocker for shipping.
| |
| ** Priority 3 - Average Bug. definitely a problem, but doesn't stop someone from using the product.
| |
| ** Priority 4 - Minor or polish bugs that are real issues (especially in aggregate) and annoying.
| |
| ** Priority 5 - Low-impact. something we'd fix, but mostly only bothers the discerning user. Little impact on usability.
| |
| <p> </p>
| |
| *'''RANK''': As priority buckets start to have a large amount of bugs in them, the Rank field can be used to call attention to higher or lower rank and provide a way to sort easily in bugzilla. To have some rhyme/reason to the order - Rank should relate to Priority. The "Ranking" number does not need to be unique. Unless there is a reason to for a bug to be considered before (or after) others in the Priority bucket - default to mid-range value.
| |
| ** P1 Rank options=1-19, default 15
| |
| ** P2 Rank options=20-29, default 25
| |
| ** P3 Rank options=30-39, default 35
| |
| ** P4 Rank options=40-49, default 45
| |
| ** P5 Rank options=50-59, default 55
| |
| ** any that we don't think we can get to in the next 6 months should go in "backlog-" area
| |
| <p> </p>
| |
| *The '''Firefox-backlog''' flag is used to track bugs that are approved for the Backlog "+" (or Backlog - to not be looked at for a while)
| |
| *Add '''whiteboard''' tag to bugs [fxsearch] as bugs for this team may span Product:: Component areas.
| |
| *'''QE-Verify''' is a flag that developers should be setting on bugs they are working on. This is used for QE to filter which bugs they check
| |
| **"+" means that QE should look at the bug and it can be verified with human eyes
| |
| **"-" means QE should not look at
| |
| ***Typically goes with in-testsuite set to "+", to show testing via another method.
| |
| *'''Points''' should be set when known.
| |
| *'''Iteration''' should be updated when a bug is being worked on during a particular Iteration.
| |
| <p> </p>
| |
|
| |
| ==Filing a bug==
| |
| ** Open a bug under Product:"___" || Component: "___" or "_____"
| |
| ** Team reviews for inclusion in Backlog every 2 weeks
| |
| *If there is a bug that should be considered for taking ASAP - you can mark "firefox-backlog"+ and set a Priority with a reason. This makes it simplest to triage those bugs quickly.
| |
| **Before it can be given a Rank it should:
| |
| *** be in an actionable state (for the team taking it)
| |
| *** for defects, the problem is ready for Engineering or UX: diagnosis, measurement, design, or fixing
| |
| *** for feature requests or enhancements, it means that there's a clear problem statement or suggestion
| |
| <p> </p>
| |
|
| |
| =Project Health=
| |
| Include clear, executive level summary that will be included at the [[https://mana.mozilla.org/wiki/display/PM/Firefox+Program mana page overall view level]:
| |
| *for company goal x, we are in _____ state because ______. Please consider ______(propose fix or adjustment of goal).
| |
| *for release goal for ______ , we are in _____ state because ______. Please consider ______(propose fix or adjustment of goal).
| |
|
| |
|
| ==Project Introduction== | | ==Project Introduction== |