Triaging: Difference between revisions
No edit summary |
add sections, iterate content |
||
Line 5: | Line 5: | ||
== Issues == | == Issues == | ||
New issues get | === New issue === | ||
==== Initial status and type ==== | |||
New issues get {{label|status|reported|bgcolor=#0033CC}} and are also given one of: | |||
* {{label|type|bug|bgcolor=#00b140}} - the issue is a well defined bug report | * {{label|type|bug|bgcolor=#00b140}} - the issue is a well defined bug report | ||
* {{label|type|support|bgcolor=#00b140}} - the issue is a question or support request, not a bug | * {{label|type|support|bgcolor=#00b140}} - the issue is a question or support request, not a bug | ||
* {{label|type|feature|bgcolor=#00b140}} - the issue describes a missing feature | * {{label|type|feature|bgcolor=#00b140}} - the issue describes a missing feature | ||
If the issue affects devices, | ==== Device category ==== | ||
If the issue affects devices, a device-category label for the highest affected [[Device_categorization|device category]] is added. | |||
* {{label|device-category|main|bgcolor=#6699cc}} - affects at least one device in the main category | |||
* {{label|device-category|community|bgcolor=#6699cc}} - affects at least one device in the community category | |||
* {{label|device-category|testing|bgcolor=#6699cc}} - 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 {{label|device-nokia-n900|bgcolor=#6699cc}}. These get added as well. | |||
=== Status change === | |||
During the lifetime of the issue, the status may change: | |||
* {{label|status|confirmed|bgcolor=#0033CC}} - issue has been confirmed (bug reproduced or it has been agreed upon implementing a feature request) | |||
* {{label|status|needsmoreinfo|bgcolor=#0033CC}} - issue is blocked because the reporter needs to provide more information | |||
At this point, the issue is "in progress", and updated as needed. | At this point, the issue is "in progress", and updated as needed. | ||
=== Resolution === | |||
Once some conclusion has been reached, one of the {{label|resolution|bgcolor=#ed9121}} labels can be applied: | Once some conclusion has been reached, one of the {{label|resolution|bgcolor=#ed9121}} labels can be applied: | ||
* {{label|resolution|wontfix|bgcolor=#ed9121}} - the bug report describes intended behaviour or for some reason we won't fix this | * {{label|resolution|wontfix|bgcolor=#ed9121}} - the bug report describes intended behaviour or for some reason we won't fix this | ||
Line 24: | Line 37: | ||
* {{label|resolution|closed|bgcolor=#bbb}} - the issue has otherwise been resolved and doesn't need to be open anymore. | * {{label|resolution|closed|bgcolor=#bbb}} - the issue has otherwise been resolved and doesn't need to be open anymore. | ||
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 | ==== 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, {{label|resolution|notourbug|bgcolor=#ed9121}} is applied but the issue is kept open. Once it's fixed upstream AND fixed in postmarketOS, the {{label|resolution|fixed|bgcolor=#ed9121}} 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 {{label|resolution|notourbug|bgcolor=#ed9121}}. | |||
In any case, a link to the upstream issue should be added to the issue - preferably edited into the top post is it's immediately visible when reading the issue. | |||
== Merge Requests == | == Merge Requests == | ||
Similarly to issues, MRs should be assigned {{label|type|bgcolor=#00b140}} of either {{label|type|fix|bgcolor=#00b140}} or {{label|type|feature|bgcolor=#00b140}}. As well as appropriate device and {{label|device-category|bgcolor=#6699cc}}. | |||
{{label|resolution|bgcolor=#ed9121}} labels only necessary for MRs that are closed instead of merged, only {{label|resolution|closed|bgcolor=#bbb}} and {{label|resolution|invalid|bgcolor=#ed9121}} make sense here. | |||
== See also == | |||
* https://gitlab.com/postmarketOS/pmaports/-/labels | |||
* https://gitlab.com/groups/postmarketOS/-/labels |
Revision as of 08:01, 19 October 2022
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
At this point, the issue is "in progress", and updated as needed.
Resolution
Once some conclusion has been reached, one of the resolution labels can be applied:
- resolutionwontfix - the bug report describes intended behaviour or for some reason we won't fix this
- resolutionnotourbug - this issue describes a bug in an upstream project.
- resolutioninvalid - this is not a valid issue
- resolutionduplicate - this is a duplicate of an existing issue.
- resolutionfixed - the issue has been fixed!
- resolutionclosed - the issue has otherwise been resolved and doesn't need to be open anymore.
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, resolutionnotourbug is applied but the issue is kept open. Once it's fixed upstream AND fixed in postmarketOS, the resolutionfixed 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 resolutionnotourbug.
In any case, a link to the upstream issue should be added to the issue - preferably edited into the top post is 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.
resolution labels only necessary for MRs that are closed instead of merged, only resolutionclosed and resolutioninvalid make sense here.