Program Management/ProjectPlanTemplate/Firefoxdesktop

From MozillaWiki
Jump to navigation Jump to search

Project Name

problem statement or why we do this project

Project Introduction

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 Iterations (Sprints)

Firefox 40 Release

  • Iteration 40.1: Tuesday March 31 - Monday April 13
  • Iteration 40.2: Tuesday April 14 - Monday April 27
  • Iteration 40.3: Tuesday April 28 - Monday May 11

Firefox 41 Release

  • Iteration 41.1: Tuesday May 12 - Monday May 25
  • Iteration 41.2: Tuesday May 26 - Monday June 8
  • Iteration 41.3: Tuesday June 9 - Monday June 29
    • Note: IT 41.3 is a 3-week iteration.

Firefox 42 Release

  • Iteration 42.1: Tuesday June 30 - Monday July 13
  • Iteration 42.2: Tuesday July 14 - Monday July 27
  • Iteration 42.3: Tuesday July 28 - Monday August 10

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.
  • Theme with multi-parts update:
    • Server end: hit bumps with updated module causing failure and is currently diagnosing 503 errors before deploying. (include bug number)
    • Client-end: Continues through at least this iteration. Discovered issue with encryption key generation that will require re-authentication after upgrade, working on UX change now.
  • Continuing CSS clean-up in SDK. landing small pieces - as it's pretty tangled - and keep spinning off and landing more.
  • break-down/UX clarification for Link-clicker and in-conversation chat continue
  • Metrics
    • If time, telemetry patches (marked Metrics in Backlog). They are low risk/small changes and vital to making informed decisions, we will be requesting uplift to 39 for those landing in this iteration.
    • Adding more Google Analytic metrics for _____

No results.

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


Past

Iteration 40.1 (through April 13)

  • Theme:
    • Client-end: Learning some js code that was anticipated does not work how we need. Working with desktop folks on options to resolve or implement new.
    • Server side updated Bug 1141105 for Context, found issues in this iteration - next iteration.
    • Preliminary design for encrypted room context (name, description, etc). This encryption work will enable future features.
  • Continuing CSS clean-up in SDK and how that impacts Hello code today - continued into next iteration based on priorities
  • Technical estimates/break-down for Link-clicker and in-conversation chat (not work - just working out if there are any unanswered questions)
  • Share Plane was backed out of 39 - fixed test and re-landing for uplift to 39.

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

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.

Retrieved from "https://wiki.mozilla.org/index.php?title=Program_Management/ProjectPlanTemplate/Firefoxdesktop&oldid=1069789"