mirrors/element-web
1
0
Fork 0
mirror of https://github.com/element-hq/element-web synced 2024-11-28 04:21:57 +03:00
Code Issues Projects Releases Packages Wiki Activity

Destroyed Triage process (markdown)

Kat Gerasimova 2021-12-14 08:42:25 +00:00
parent 11dc22dde0
commit bb2761e88a
1 changed files with 0 additions and 76 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

76
Triage-process.md

@ -1,76 +0,0 @@
Element-web has about 100 new issues every week, we want to have a structure for triage which ensures new issues are labelled correctly and are actively processed. Our secondary, longer term, goal is to reduce the backlog.
## Responsibility
The issue wrangler role rotates between developers on the team every week. The responsibility of the issue wrangler is to:
* Do initial assessment on incoming issues
* Redirect issues to appropriate teams if needed
* Re-triage based on corporate priorities as indicated by management
* Pick out highest priority issues and work on them for the allocated time every week
## Initial assessment
The issue wrangler will use the [Issue triage board](https://github.com/vector-im/element-web/projects/27) to:
* Label new issues with:
* One T-* label (usually [T-enhancement](https://github.com/vector-im/element-web/labels/T-Enhancement) or [T-Defect](https://github.com/vector-im/element-web/labels/T-Defect))
* One O-* label and the reasoning for it unless explicitly clear from previous comments
* One S-* label for issues labelled T-Defect and the reasoning for it unless explicitly clear from previous comments
* X-* and A-* labels as needed
* Request more information as needed on new issues
* Update new issue description and titles as needed to be useful
* Review any issues wrangled by community members since their last review
* Review any issues updated with more information
* Check for duplicates and close the new issue, mentioning the duplicate issue so progress can be tracked in the original issue. Older issue should only be closed in preference to newer issue if the newer issue has more detail and relevant discussion.
* Refer issues to Engineering and Product Managers if priority is uncertain post-triage
* Priority issues will automatically be moved to the P1 column on [the web app Team project board](https://github.com/vector-im/element-web/projects/11). These are defects labelled with:
* [A11y and S-Critical](https://github.com/vector-im/element-web/issues?q=is%3Aissue+is%3Aopen+label%3AS-Critical+label%3AA11y)
* [S‑Critical and O-Frequent](https://github.com/vector-im/element-web/issues?q=is%3Aissue+is%3Aopen+label%3AS-Critical+label%3AO-Frequent)
* [S‑Critical and O-Intermediate](https://github.com/vector-im/element-web/issues?q=is%3Aissue+is%3Aopen+label%3AS-Critical+label%3AO-Intermediate+)
* [S‑Major and O-Frequent](https://github.com/vector-im/element-web/issues?q=is%3Aissue+is%3Aopen+label%3AS-Major+label%3AO-Frequent+)
* Defects with other labels which have been agreed by the team as being high priority
* Issues which do not fulfil the criteria for priority focus should not be added to the Web App Team's board
* If possible, confirm that the issue is reproducible
## Prioritisation
Priority was defined as a subjective feel for how important the issue is. Issue priority is, in fact, made up of a number of criteria such as risk, cost, impact, occurrence and severity. To keep the process simple, we use occurrence and severity to create a basic risk assessment matrix to use objective criteria to ease primary prioritisation.
| | Occurrence (score) | 3 | 2 | 1 |
|--------------------|:------------------:|:----:|:------:|:---:|
|**Severity (score)**| | Frequent | Intermediate | Low |
| **4** | Critical | 12 | 8 | 4 |
| **3** | Major | 9 | 6 | 3 |
| **2** | Minor | 6 | 4 | 2 |
| **1** | Tolerable | 3 | 2 | 1 |
Note that scores correspond to the impact of the label. Combinations with a score of 8-12 will be prioritised for picking up by the team in the first instance because they are the most visible with the severest effect on the users. These defects will be added to the “P1” column for developers to pick out as needed.
| Labels | Equivalent priority | What it means |
| ----------- | ----------- | ----------- |
| S‑Critical and O-Frequent<br />S‑Critical and O-Intermediate<br />S‑Major and O-Frequent | P1 | These issues should be worked on in this sprint or next sprint. If the backlog of issues is too long, we should reevaluate why the bugs are not caught earlier. |
| S‑Critical and O-Low<br />S‑Major and O-Intermediate<br />S‑Minor and O-Frequent | P2 | When all the highest priority issues are done, this is the next set to tackle. Ideally we should be fixing a few issues from this group every week. |
| S‑Major and O‑Low<br />S‑Minor and O-Intermediate<br />S‑Tolerable and O-Frequent | P3 | These issues are wishful thinking for now. We hope to get to them one day, but they are low priority. There are likely to be some good new contributor issues in here. |
| S‑Minor and O‑Low<br />S‑Tolerable&nbsp;and&nbsp;O‑Intermediate<br />S‑Minor and O‑Low | P4 and P5 | These issues are unlikely to be actively looked at by the webapp team, but may be picked up by community.|
## Handling X-Needs-Info
Issues need sufficient information in them to be reproducible and therefore for developers to be able to fix them.
### Issues filed using GitHub bot in Matrix rooms
These issues are usually either personal notes or reminders or trackers for ongoing work.
This should be automated and done by a bot in the future (and by issue wrangler for now):
* Comment with “This needs more detail to be useful to other developers, assigning to issue author to update with more info or fix” and assign to developer
* Label with X-Needs-Info and revisit a long way down the line later
This part cannot be automated easily so will continue to be done manually for now:
* Update with more information if it’s obvious to you what the issue is about and that it’s not a personal note, and comment asking the developer to include more information next time.
* Label with any labels that you can, especially A-* labels
* Revisit issues and close them if they have been open for a long time
### Issues filed by external contributors
* Label with X-Needs-Info, comment with “`@<username>` Thank you for opening an issue. Unfortunately there is not enough information there for me to be able to reproduce it. Please update the description with steps/screenshots/video/more details so our developers can have a look at it.” and revisit in a week
* If no update in a week, try to reproduce and update the description.
* If you can’t reproduce because you don’t have the right setup, label with X-Cannot-Reproduce, comment with “`@<username>` Unfortunately I cannot reproduce your issue. Please update your issue with more information. If we don’t hear back from you in a week, we will close the issue as we need to be able to reproduce it before we can fix it.” and leave it open for at least another week
* If you can’t reproduce with the right setup (to the best of your knowledge), then tag with X-Cannot-Reproduce and close with a “Thank you for opening an issue. Unfortunately I wasn’t able to reproduce it. If you keep experiencing this defect, please update your description with steps/screenshots/video/more details and add a comment with `@<your own username>` to let me know that it’s ready to be reopened.”
See [comment templates for more details](https://github.com/vector-im/element-web/wiki/comment-templates)