Notice: this Wiki will be going read only early in 2024 and edits will no longer be possible. Please see: https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/wikis/Wiki-shutdown-plan for the plan.
Difference between revisions of "SWT/Devel/Triage"
m (→Triage Process (Tentative preview)) |
m |
||
| Line 1: | Line 1: | ||
| − | == | + | == Page todos (Page under construction) == |
| − | + | [ ] Migate new/relevant info from: https://www.eclipse.org/swt/triage.php | |
| + | |||
| + | == Triage Process Overview == | ||
| + | The goal of "Triage" is a '''quick''' initial response to incoming bug submissions from users. The goal is for users to receive initial feedback on their submission and for bugs to be categorized properly. | ||
| + | <br> Users typically don't know the code base as well, so developers should: | ||
| + | * Check for duplicate bugs | ||
| + | * Set/update meta data correctly | ||
| + | * Link to relevant bugs | ||
| + | * Briefly investigate if bug is real (i.e, reproducible on latest master) | ||
| + | * Ask user to test with newer version if reported version is very old | ||
| + | * Request versions of SWT/OS/java | ||
| + | * Request a snippet (or clear steps to reproduce) if it's not clear as to how to reproduce issue | ||
| + | * Ping/CC developers involved in related issue (especially when regressions occur) | ||
| + | * [Optionally] try to bisect codebase for regression reports | ||
| + | |||
| + | If the bug has sufficient information, then add the "'''Triaged'''" Keyword to it and optionally leave some message for the user e.g "Thank you for bug submission, we should investigate". The bug status should remain "NEW" and it should not be re-assigned to legacy "swt-triage@" user. (see history). | ||
| + | |||
| + | Subsequently, when we look for new bugs to work on, we can check bugs that have the "Triaged" keyword (See queries below). <br> | ||
| + | When you take ownership of the bug (i.e you intend to work on the bug), you can assign it to yourself. When you start working on the bug, you can set the status to "ASSIGNED". | ||
| + | |||
| + | [[File:Platform-Triage-Process-v2.png|thumbnail|left]] | ||
| + | |||
| + | |||
| + | |||
| + | |||
| + | |||
| + | |||
| + | |||
| Line 24: | Line 51: | ||
* To be added: Cocoa specific | * To be added: Cocoa specific | ||
| − | |||
| − | + | ||
| + | |||
| + | == History == | ||
| + | In the past, triaged bugs were re-assigned from a platform-swt-inbox@eclipse.org to a stw-triaged@eclipse.org user. Instead we now just add the "Triage" keyword. | ||
| + | |||
| + | In the distant past, bugs were assigned to component owners, but that lead to component owners to have large amount of bugs that they did not actually work on. | ||
| + | |||
| + | Some projects used to use platform-inbox, but to mark a bug as triaged, the "ASSIGNED" status was used. But this could lead to confusion where users could think that | ||
Revision as of 14:54, 16 June 2017
Contents
Page todos (Page under construction)
[ ] Migate new/relevant info from: https://www.eclipse.org/swt/triage.php
Triage Process Overview
The goal of "Triage" is a quick initial response to incoming bug submissions from users. The goal is for users to receive initial feedback on their submission and for bugs to be categorized properly.
Users typically don't know the code base as well, so developers should:
- Check for duplicate bugs
- Set/update meta data correctly
- Link to relevant bugs
- Briefly investigate if bug is real (i.e, reproducible on latest master)
- Ask user to test with newer version if reported version is very old
- Request versions of SWT/OS/java
- Request a snippet (or clear steps to reproduce) if it's not clear as to how to reproduce issue
- Ping/CC developers involved in related issue (especially when regressions occur)
- [Optionally] try to bisect codebase for regression reports
If the bug has sufficient information, then add the "Triaged" Keyword to it and optionally leave some message for the user e.g "Thank you for bug submission, we should investigate". The bug status should remain "NEW" and it should not be re-assigned to legacy "swt-triage@" user. (see history).
Subsequently, when we look for new bugs to work on, we can check bugs that have the "Triaged" keyword (See queries below).
When you take ownership of the bug (i.e you intend to work on the bug), you can assign it to yourself. When you start working on the bug, you can set the status to "ASSIGNED".
Triage Process
( # Proposed Triage Process)
- New bugs are analyzed for Quality, additional information is requested from reported if needed.
- If bug submission is of sufficent quality (e.g bug can be reproduced and contains relevant information), then "Triaged" keyword is added.
- We select bugs with "Triaged" keyword to work on.
- See workflow diagram below
New Bug Queries:
- Highest voted bugs
- Highest Priority, then Votes, then Severity
- To be added: Linux specific
- To be added: Win32 specific
- To be added: Cocoa Specific
Triaged Bug Queries:
- Triaged bugs ALL OS's (Priority, Votes, Severity)
- Traiged bugs Linux/CentOS (Sort: Priority, Votes, Severity)
- To be added: Win32 specific
- To be added: Cocoa specific
History
In the past, triaged bugs were re-assigned from a platform-swt-inbox@eclipse.org to a stw-triaged@eclipse.org user. Instead we now just add the "Triage" keyword.
In the distant past, bugs were assigned to component owners, but that lead to component owners to have large amount of bugs that they did not actually work on.
Some projects used to use platform-inbox, but to mark a bug as triaged, the "ASSIGNED" status was used. But this could lead to confusion where users could think that