Testing Failures Board Maintenance Process [WIP]

Goal

Keep the testing failures board accurate and actionable across releases. Ensure that open issues reflect current, reproducible failures, and avoid uncontrolled backlog growth.

1. Issue Lifecycle

• New issue
  Logged during release testing using the template. Triaged and labeled (bug, not reproducible, transferred).

• Needs retest
  Issues older than one release cycle should be re-verified to check if they still occur.

• Known failure
  Confirmed, reproducible issues that cannot be fixed immediately. They remain open and documented in release notes.

• Closed
  Issues no longer reproducible or fixed indirectly. A short comment should explain closure.

• Aging policy
  What expires is the prioritization, not the issue itself. An issue that is a known failure cannot be closed until it is solved. However, if it has not been updated for a release cycle, its priority is reviewed. It may be lowered, re-labeled as known failure, or justified to remain at a higher priority. This keeps the backlog cleaner without losing track of reproducible bugs.

2. Board Management

• Bug triagers (and contributors with capacity) work on fixing issues between releases, at least high-priority ones.

• The test failures board remains active during the full release cycle.

• Priorities shift dynamically according to context, ensuring that the group focuses on the most relevant issues.

• Periodic reviews should identify low-priority items that can be elevated to attract attention.

3. Meetings

• During release windows (8 weeks before cut)

  • Continue with the template agenda (round robin role updates).

  • Dedicate time to reviewing critical high-priority issues.

• Between releases

  • Use quieter meetings to revisit parts of the board (e.g., “needs retest” or long-standing issues).

  • Focus on a manageable subset, not the whole board at once.

4. Prioritization

• Issues are labeled High / Medium / Low.

• During release testing → each new issue is triaged and labeled immediately.

• Between releases → board reviews can adjust priorities and bring forward older low-priority items.

5. Bug Days / Bug Sprints

• Organize periodic “bug days” or “bug sprints.”

• Community members gather to review the full backlog, close irrelevant issues, and focus on the most critical or newly reprioritized ones.

• These events also help onboard new contributors with concrete, time-bound tasks.

6. Metrics

• Metrics are reviewed once per month:

  • Issues opened vs. closed.

  • Number of issues in known failure.

  • Overall backlog trend (growing or shrinking).