Skip to main content

Notice: This Wiki is now read only and edits are no longer possible. Please see: for the plan.

Jump to: navigation, search

Papyrus-RT/Bug Guidelines


Bug Guidelines


This page describes the guidelines and governance for managing Papyrus for Real Time bugs in Bugzilla.



  • Product Lead (a.k.a., product owner, product manager)
    • The person responsible of determining the content of a release, milestone, etc.
  • Development Lead (a.k.a., development owner, development manager, Scrum Master)
    • The technical responsible for the development of the software, e.g., code, build, etc.
  • Committer: Someone who is working on the development of the Papyrus-RT project.

New Bug

  1. When a bug is entered, it starts life as unconfirmed, unless entered by a committer in which case it is marked as new
    • If a bug is created by copying information from another (source) bug, then to ensure full history and traceability, this must be indicated in the new bug with a "See Also" link to the source bug. The source bug must also be included in the new bug's "See Also" list.


  1. On a weekly basis, the Product and Development Leads will look at unconfirmed bugs and transition them to the new state or close them with one of: invalid, duplicate, won’t fix. The fix version will also be set at this time if it can be decided. The Product and Development Leads for Papyrus-RT will be responsible for backlog grooming, where "Fix Versions" are updated as we progress through a release.
  2. The bug is then be assigned for someone to fix and the status is set to assigned. Assignment of a bug can be done in one of several ways:
    • Someone volunteers for a bug and assigns it to themselves
    • A Product Lead or someone assigned the task of managing backlog will do this.
    • Bugs should not be worked on unless they are assigned.
  3. When a bug is assigned to someone to be fixed, a "fix version" must be set. This is important so that the Product and Development Leads can see if risky fixes are being considered and evaluate the risk based on how close we are to a milestone.
  4. Bugs should not be pulled back from later releases without the Product Lead’s approval.

Tagging Dependencies on base Papyrus

  1. If a bug has or is suspected to have a dependency on base Papyrus:
    • The bug must be identified as being blocked by using the "depends_on_papyrus" Whiteboard tag
    • A new bug must be created on base Papyrus, explaining the problem encountered in the context of Papyrus - it is not sufficient to simply copy the content of the Papyrus-RT bug into this new bug.
    • This new bug must be identified has blocking Papyrus-RT by using the "blockingpapyrusrt" Whiteboard tag.

Resolving bugs

  1. Once the bug has been addressed, the bug will be marked as resolved by the assignee. The status should also indicate how it has been addressed: fixed, invalid, “works for me”, duplicate, won’t fix. If appropriate, a test should also be submitted at the same time. If a test is required, but not submitted, then the bug stays in open or assigned and the "test" keyword is added to the bug. The comments must also indicate that the bug only lacks a test.

Verifying bugs

  1. The bug fix then needs to be verified that it addresses the original problem. Ideally this is done by the originator, but can be done by anyone, including, for simple fixes only, the person who resolved it. The bug status is then set to verified. If the originator or anyone else has a strong view on who should test the fix, then the QA contact field can be filled in

Closing bugs

  1. Verified bugs are then closed by either the originator or by the Product Lead

Back to the top