Triaging

From postmarketOS

This page explains the triage process for issues and merge requests. It's written for pmaports and pmbootstrap but also applies to other postmarketOS maintained repositories.


🚧 This page is a work-in-progress. Some information contained within may be inaccurate or incomplete.
In particular: Missing issue lifespan and MRs


Issues

New issue

Initial status and type

New issues get statusreported and are also given one of:

  • typebug - the issue is a well defined bug report
  • typesupport - the issue is a question or support request, not a bug
  • typefeature - the issue describes a missing feature

Device category

If the issue affects devices, a device-category label for the highest affected device category is added.

  • device-categorymain - affects at least one device in the main category
  • device-categorycommunity - affects at least one device in the community category
  • device-categorytesting - affects at least one device in the testing category

For devices in main and community categories, we also have one issue label per device, for example device-nokia-n900. These get added as well.

Status change

During the lifetime of the issue, the status may change:

  • statusconfirmed - issue has been confirmed (bug reproduced or it has been agreed upon implementing a feature request)
  • statusneedsmoreinfo - issue is blocked because the reporter needs to provide more information
  • statuswontfix - the bug report describes intended behaviour or for some reason we won't fix this
  • statusnotourbug - this issue describes a bug in an upstream project.
  • statusinvalid - this is not a valid issue
  • statusduplicate - this is a duplicate of an existing issue.
  • statusfixed - the issue has been fixed!

Upstream issue

If the issue reported is an upstream bug, it doesn't always make sense to close it immediately. If having a local issue to track it adds value, for example if this is a very important bug and we need to know when it is fixed in postmarketOS, statusnotourbug is applied but the issue is kept open. Once it's fixed upstream AND fixed in postmarketOS, the statusfixed gets applied and the issue gets closed.

On the other hand, if it it doesn't add value to keep the bug around in postmarketOS, it should be closed after applying statusnotourbug.

In any case, a link to the upstream issue should be added to the issue - preferably edited into the top post so it's immediately visible when reading the issue.

Merge Requests

Similarly to issues, MRs should be assigned type of either typefix or typefeature. As well as appropriate device and device-category.

status labels only necessary for MRs that are closed instead of merged, only statusinvalid makes sense here.

See also