MDN/Development Process

Product Planning

• Bi-weekly, 15-60m
• Stakeholders
• Product
• Developers
• QA (optional?)

During product planning meetings we set the immediate product goals and objectives. We introduce new features, discuss enhancements to existing features, review new and outstanding bugs, and prioritize. Product planning meetings set the backlog - we create bugs, update bugs, assign milestones to bugs, remove milestones from bugs.

Output

Accurate bugzilla bugs and milestones

Dev Planning

• Weekly, 15-60m
• Product
• Developers
• QA
• IT (optional)

Agenda

• Retro
  • Celebrate all code pushes & give kudos
  • Look back at the last "sprint" - what worked, what didn't, and what should we improve?
• Planning
  • Developers review milestones' bug backlog with Product and adjust according to developer input - implementation details, resources, risk, effort, etc.
• Roadmap
  • Briefly (5m) discuss upcoming non-immediate work so no-one is surprised by anything.

Output

Developer + Product-approved bugzilla bugs for immediately active milestone(s)

Standup

Standup is a very short (5-10m) daily meeting to make sure everyone is on the same page. Round-robin: What I did yesterday. What I'm doing today. Blockers, if any.

• Daily, 5-10m
• Developers
• Product

Bugs

Status Flow

Bugs should typically flow thru the team:

• Product & QA & Dev
  • (Unconfirmed) -> New
• Dev
  • New -> Assigned -> Resolved:Fixed
• QA
  • Resolved:Fixed -> Reopened or Verified:Fixed -> Closed

See also: MDN/QA/Filing Bugs

Severity

• Blocker - cannot push milestone without fixing this bug
  • (e.g., security, total loss of functionality)
• Critical - only okay to push Blockers in front of this bug
  • (e.g., major function broken but workaround in place)
• Major - this bug is part of the major focus of the milestone
  • (e.g., Demo Studio for 0.9.3)
• Normal, etc. - Nice-to-have, work on between other bugs
  • (e.g., style changes, annoyances)