Program Management/ProjectPlanTemplate/Firefoxdesktop

Project Name

problem statement or why we do this project

Project Introduction

• Team Mailing list: ex: Firefox/dev-media
• Team IRC Channel: ex: #loop
• Summary of our plans for this year (links back to main page for the area - ex: platform or desktop have roll-up pages with very high level goals)
• More detailed Roadmap, noting that the further out the more lose the targets are
• Dependencies: feature, partner, resource, etc. - put links to other project pages.

Links to Current info

The Loop/wiki page is the central location for current focus, Roadmap, Metrics, UX, Marketing, tech-architecture, and more.

Roles and Responsibilities

The cross-team Loop/Contacts Page has the Roles and Responsibilities for Hello, webRTC, partner teams, and external partners involved in this project.

Meetings

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	etherpad
"Retrospective"	Friday	8:00AM - 9:00AM	11:00AM - 12:00PM	5:00PM - 6:00PM	webRTC-Apps	etherpad

Development

Schedule

Release timing

• Firefox main release schedule is the master location for the dates when each Firefox version goes to Aurora, Beta, & Release.

Sprints (if team is using 2 week sprints)

• Sprint schedule for 2 week increments (3 Sprints per Fx Release) (need to update with link from Marco to a better master)
  • Also in Bugzilla there is a field for "Iteration" that has the iteration number and the last day in that sprint:
    • <FxRelease#>.1 - <last day before uplift>
    • <FxRelease#>.2 - <last day before uplift>
    • <Fxrelease#>.3 - <last day before uplift>

Upcoming Priorities

As we plan what's coming next, these are areas being discussed. This is not a commitment to the next projects - just our scratch area.

• finishing Context work (large change)
• market work
• in-conversation chat

Things we want to do - but parking lot until Fx39 goals and the highest priorities are done:

• Moving Faster: add-on investigation
• Android experience improvements
• e10s readiness for e10s patches (e10s in Beta in 41, releases in 42 - so MUST be in for 42)
• Link-Clicker Parity break-down based on the User Story. That already limits the scope to not include sharing from the link clicker in the first go (eventual goal - but needed to break up work).
• Continue quality focus
• WebRTC permission prompt optimization

Risks

• List risks

Current

Iteration 40.2 (through April 27)

• Theme feature landed and verified, uplifting to Fx39. Any pref info.
• Theme with multi-parts update:
  • Server end: update
  • Client-end: update
• Theme 2
• Prep work: ex: break-downs or UX work
• Metrics
  • Update
• Bugs
  • Update

No results.

0 Total; 0 Open (0%); 0 Resolved (0%); 0 Verified (0%);

</p

Past

Iteration 40.1 (through April 13)

• Theme feature landed and release will be in. Any pref info
• Theme with multi-parts update:
  • Server end: update
  • Client-end: update
• Theme 2
• Prep work: ex: break-downs or UX work
• Metrics
  • Update
• Bugs
  • Update

No results.

0 Total; 0 Open (0%); 0 Resolved (0%); 0 Verified (0%);

Product Backlog

All work related to the ongoing development and maintenance of the Firefox Desktop Product are collected and prioritized in the Product Backlog. The goals of the Product Backlog are to:

• Enable work to be prioritized so that the team is always working on the most important features.
• Support continual planning as the product emerges so the plan matches reality.
• Improve forecasts so that the stakeholders make the best decisions about the direction of the product.

Product Backlog

• Bugzilla Ranked "Firefox-backlog+" list
  • Add the "Rank" Column to your results and sort on Rank to view order of work.
    • The option to "Change columns" is at bottom of search results
  • Search is based on "Flags" - "contains the string" - firefox-backlog+
• Un-triaged bugs

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 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.

• 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

• The Firefox-backlog flag is used to track bugs that are approved for the Backlog "+"
• 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.

Filing a bug

• • 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

Templates

Go to Templates page for sample etherpads, invite details, etc. for the following types of meetings.

• stand-ups (daily, weekly, or other)
• retrospective invites with questions/structure of the meeting in etherpad
• cross-team/company meeting invites/etherpads to keep efficient and only when needed
• postmortems

Archive

as iteration information or links get old or if this is replacing an older page and we don't want to lose path to the information...link to an archive page from here.