Proposal for Documenting and Tracking BTR Issues

This is the first attempt at a proposal for a simple process to document issues raised for the BTR Project Board

To assess and discuss each issue, we need to know:

  1. The type of issue: is it a bug? is it a gap in documentation?
  2. The release that is affected.
  3. The severity of the issue.

Each issue should have at least 3 tags (one of each category):


The name of the release.

  • Juniper
  • Koa
  • Lilac



I’m conscious that the relationship between severity and priority can raise a lot of questions/discussions. To simplify things my thought process was centred around the question “How difficult does it make installing or running an instance of Open edX?”.

  • High: This issue stops the installation or core functionality of the platform and has no workaround.
  • Medium: This issue affect a non-core part of the installation or the platform and/or has a workaround.
  • Low: This issue doesn’t impact the usability of the platform.

:warning: These descriptions are non-exhaustive, it’s safe to say that a security patch should fall under high priority even though it doesn’t impact any functionality.

:bulb: If in doubt between two levels of priority, assign the highest level and it can be reviewed by other members of the group.


  • It is the responsibility of the person creating issue to appropriately describe and tag it (affect, type, priority). The tags can be reviewed and modified by the group.
  • It is the responsibility of the Bug triager to link the issues to the appropriate Milestone.

Ideas to improve the experience

  • Add a github action to automatically add new issues to the project board.
  • Auto-assign new issues to the bug triager.
  • Find a way to add a ‘Due date’. I’m not sure how to implement this yet any suggestion is welcome!

Weekly Update

I’m planning to issue a weekly update (see next post for an example). This means that until we have a ‘Due date’ system if you have an issue assigned to you, you will get a weekly nudge to provide an update on the issue. Is there any thoughts against that?


(This is an example)

BTR Issues Weekly Update

:tada: Closed Issues

:rotating_light: Next Milestone: Koa.3

Need volunteers

  • Issue#5: Write Juniper → Koa upgrade instructions

:star: Are you new?

If you are looking to contribute for the first time, these issues can be a good starting point:

  • Issue#7: All emails include the logo which is a sailthru tracking image

Leave a comment on the issue to show let us know you want to contribute.

More on the BTR Project Board.