MozillaWiki

Firefox/Iterative Hello Development: Difference between revisions

Page Discussion

Firefox/Iterative Hello Development (view source)

Revision as of 14:35, 27 May 2015

2 bytes added ,  27 May 2015
ordering
(→‎Meetings: update)
(ordering)
Line 1: Line 1:
==Cross-Team Project Calendar==
{{#widget:Widget:Google Calendar
|id=bW96aWxsYS5jb21fNTY0NW1uMWpnamQ5aG8zaXNodHRodnQybHNAZ3JvdXAuY2FsZW5kYXIuZ29vZ2xlLmNvbQ
}}


==Project Introduction==
==Product Backlog==
 
<p> </p>
===Key Bugzilla Queries===
* [http://mzl.la/1AglJsA Bugzilla Ranked "Firefox-backlog+" list]
**Add the "Rank" Column to your results and sort on Rank
***The option to "Change columns" is at bottom of search results
**Search is based on "Flags" - "contains the string" - firefox-backlog+
* [http://mzl.la/18Xoxhm Un-triaged bugs]
* [http://mzl.la/1tTiXXC Tech-debt bugs] priority based on [https://etherpad.mozilla.org/brainstormtesthello etherpad discussion - though if you want one that's lower priority but impacting you - grab it]
 
<p> </p>
<p> </p>
* '''Team Mailing list:''' [[Firefox/dev-media]]
The goals of the Product Backlog and dynamic Planning are to:
* '''Team IRC Channel:''' [irc://irc.mozilla.org/loop #loop]
**Simplify prioritization & planning so the team is always working on the most important features.
**Improve visibility to everyone to clear priorities - so we make the best decisions about the direction of the product (call out risks early, relative priorities, trade-offs).<p> </p>
 
===Triage Guidelines===
The Product Backlog is continually maintained by the Hello Management team to ensure new priorities are available for each Sprint Planning meeting.
* Priorities follow the Firefox Desktop 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.
 
*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>
<p> </p>
===Links to Current info===
*The Firefox-backlog flag is used to track bugs that are approved for the Backlog "+"
The [https://wiki.mozilla.org/Loop/wiki Loop/wiki page] is the central location for current focus, Roadmap, Metrics, UX, Marketing, tech-architecture, and more.
*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 (if nothing set - assumed a "1" or very small).  Most relevant if taking a bigger bug so we know when bugs are large bits of work.
*"Iteration" should be updated when a bug is being worked on during a particular Sprint.  


===Roles and Responsibilities===
===Filing a bug===
The [https://wiki.mozilla.org/Loop/Contacts cross-team Loop/Contacts Page] has the Roles and Responsibilities for Hello, webRTC, partner teams, and external partners involved in this project.
** Open a bug under Product:"Loop" || Component: "General" or "Client"
** Hello team reviews for inclusion into a release backlog every 2 weeks, and will mark "firefox-blocking" accordingly
*If there is a bug that should be considered for taking ASAP - you can mark "firefox-backlog"+
**Before it can be given a Rank it should:
*** be in an actionable state
*** 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
*** has a difficulty/user-impact ratio low enough that we can reasonably expect to spend time fixing the bug within the next 6 months
<p> </p>


===Meetings===
===Definition of Done===
<p> </p>
* The [https://etherpad.mozilla.org/HsVyzOogAr Definition of Done] ensures a potentially shippable product increment is released at the conclusion of a release cycle.
<p> </p>
* A potentially shippable product increment means compliance with the work's individual acceptance criteria and not the full story under development.
<p> </p>
<p> </p>
{| class="wikitable"
|-
! Meeting !! Day of week !! Pacific Time !! Eastern Time !! Central European Time !! Vidyo Room !! Notes
|-
| "Daily Stand-up" || Monday, Tuesday, Wednesday, Thursday || 8:00AM - 8:30AM || 11:00AM - 11:30PM || 5:00PM - 5:30PM || webRTC-Apps || [https://etherpad.mozilla.org/haeLwWEkZV etherpad]
|-
| "Retrospective" || Friday || 8:00AM - 9:00AM || 11:00AM - 12:00PM || 5:00PM - 6:00PM || webRTC-Apps || [https://etherpad.mozilla.org/loop-retrospectives etherpad]
|-
| "Cross team alignment" || Tuesday || 11:30AM - 12:00PM || 2:30AM - 3:00PM ||  ||  ||
|}


==Contribute to Hello Development==
<p> </p>
===Good First Bugs===
<p> </p>
These are tagged as [good first bug] in a bug's Whiteboard field.  The challenge of a "good first bug" is only peripherally about the bug itself. The focus, for a new contributor, should be on getting your development environment set up and learning how to navigate Mozilla's contribution process. We are working on better documentation to help you get started with Hello (expect an update Q1 2015), and the #introduction IRC channel exists just to help people getting started as contributors.
<p> </p>
* '''Hello Backlog Good First Bugs - [http://mzl.la/1zNfmeV View in Bugzilla]
<p> </p>
==Objectives==
<p> </p>
The Iterative Development Model implemented for Firefox Desktop aims to accomplish six key objectives:
* '''Transparent - '''Who is working on what, when, and why.
* '''Predictable and Repeatable - '''Know what to expect from the process.
* '''Inclusive - '''Include all key participants (Eng, UX, QA, Security, Product) and stakeholders in the process.
* '''Clear Direction and Decision Making - '''Know what we should do and who makes the call.
* '''Clear and Stable Priorities - '''Be clear on what is most important for each iterative cycle.
* '''Innovative - '''Provide flexibility to engage in experimental and original projects.
<p> </p>
<p> </p>


Line 177: Line 226:
<p> </p>
<p> </p>


==Product Backlog==


<p> </p>
==Cross-Team Project Calendar==
===Key Bugzilla Queries===
{{#widget:Widget:Google Calendar
* [http://mzl.la/1AglJsA Bugzilla Ranked "Firefox-backlog+" list]
|id=bW96aWxsYS5jb21fNTY0NW1uMWpnamQ5aG8zaXNodHRodnQybHNAZ3JvdXAuY2FsZW5kYXIuZ29vZ2xlLmNvbQ
**Add the "Rank" Column to your results and sort on Rank
}}
***The option to "Change columns" is at bottom of search results
**Search is based on "Flags" - "contains the string" - firefox-backlog+
* [http://mzl.la/18Xoxhm Un-triaged bugs]
* [http://mzl.la/1tTiXXC Tech-debt bugs] priority based on [https://etherpad.mozilla.org/brainstormtesthello etherpad discussion - though if you want one that's lower priority but impacting you - grab it]


==Project Introduction==
<p> </p>
<p> </p>
The goals of the Product Backlog and dynamic Planning are to:
* '''Team Mailing list:''' [[Firefox/dev-media]]
**Simplify prioritization & planning so the team is always working on the most important features.
* '''Team IRC Channel:''' [irc://irc.mozilla.org/loop #loop]
**Improve visibility to everyone to clear priorities - so we make the best decisions about the direction of the product (call out risks early, relative priorities, trade-offs).<p> </p>
 
===Triage Guidelines===
The Product Backlog is continually maintained by the Hello Management team to ensure new priorities are available for each Sprint Planning meeting.
* Priorities follow the Firefox Desktop 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.
 
*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>
<p> </p>
*The Firefox-backlog flag is used to track bugs that are approved for the Backlog "+"
===Links to Current info===
*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
The [https://wiki.mozilla.org/Loop/wiki Loop/wiki page] is the central location for current focus, Roadmap, Metrics, UX, Marketing, tech-architecture, and more.
**"+" 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 (if nothing set - assumed a "1" or very small).  Most relevant if taking a bigger bug so we know when bugs are large bits of work.
*"Iteration" should be updated when a bug is being worked on during a particular Sprint.  


===Filing a bug===
===Roles and Responsibilities===
** Open a bug under Product:"Loop" || Component: "General" or "Client"
The [https://wiki.mozilla.org/Loop/Contacts cross-team Loop/Contacts Page] has the Roles and Responsibilities for Hello, webRTC, partner teams, and external partners involved in this project.
** Hello team reviews for inclusion into a release backlog every 2 weeks, and will mark "firefox-blocking" accordingly
*If there is a bug that should be considered for taking ASAP - you can mark "firefox-backlog"+
**Before it can be given a Rank it should:
*** be in an actionable state
*** 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
*** has a difficulty/user-impact ratio low enough that we can reasonably expect to spend time fixing the bug within the next 6 months
<p> </p>


===Definition of Done===
===Meetings===
<p> </p>
* The [https://etherpad.mozilla.org/HsVyzOogAr Definition of Done] ensures a potentially shippable product increment is released at the conclusion of a release cycle.
<p> </p>
* A potentially shippable product increment means compliance with the work's individual acceptance criteria and not the full story under development.
<p> </p>
<p> </p>
{| class="wikitable"
|-
! Meeting !! Day of week !! Pacific Time !! Eastern Time !! Central European Time !! Vidyo Room !! Notes
|-
| "Daily Stand-up" || Monday, Tuesday, Wednesday, Thursday || 8:00AM - 8:30AM || 11:00AM - 11:30PM || 5:00PM - 5:30PM || webRTC-Apps || [https://etherpad.mozilla.org/haeLwWEkZV etherpad]
|-
| "Retrospective" || Friday || 8:00AM - 9:00AM || 11:00AM - 12:00PM || 5:00PM - 6:00PM || webRTC-Apps || [https://etherpad.mozilla.org/loop-retrospectives etherpad]
|-
| "Cross team alignment" || Tuesday || 11:30AM - 12:00PM || 2:30AM - 3:00PM ||  ||  ||
|}


==Contribute to Hello Development==
<p> </p>
===Good First Bugs===
<p> </p>
These are tagged as [good first bug] in a bug's Whiteboard field.  The challenge of a "good first bug" is only peripherally about the bug itself. The focus, for a new contributor, should be on getting your development environment set up and learning how to navigate Mozilla's contribution process. We are working on better documentation to help you get started with Hello (expect an update Q1 2015), and the #introduction IRC channel exists just to help people getting started as contributors.
<p> </p>
* '''Hello Backlog Good First Bugs - [http://mzl.la/1zNfmeV View in Bugzilla]
<p> </p>
==Objectives==
<p> </p>
The Iterative Development Model implemented for Firefox Desktop aims to accomplish six key objectives:
* '''Transparent - '''Who is working on what, when, and why.
* '''Predictable and Repeatable - '''Know what to expect from the process.
* '''Inclusive - '''Include all key participants (Eng, UX, QA, Security, Product) and stakeholders in the process.
* '''Clear Direction and Decision Making - '''Know what we should do and who makes the call.
* '''Clear and Stable Priorities - '''Be clear on what is most important for each iterative cycle.
* '''Innovative - '''Provide flexibility to engage in experimental and original projects.
<p> </p>
<p> </p>
Sescalante
Confirmed users
1,094

edits

Retrieved from "https://wiki.allizom.org/Special:MobileDiff/1076854"