|
1 | 1 | # Issue Lifecycle |
2 | 2 |
|
3 | | -To ensure a balance between work carried out by the NGINX engineering team while encouraging community involvement on this project, we use the following issue lifecycle. (Note: The issue *creator* refers to the community member that created the issue. The issue *owner* refers to the NGINX team member that is responsible for managing the issue lifecycle.) |
| 3 | +To ensure a balance between work carried out by the NGINX engineering team while encouraging community involvement on |
| 4 | +this project, we use the following issue lifecycle. (Note: The issue *creator* refers to the community member that |
| 5 | +created the issue. The issue *owner* refers to the NGINX team member that is responsible for managing the issue |
| 6 | +lifecycle.) |
4 | 7 |
|
5 | 8 | 1. New issue created by community member. |
6 | 9 |
|
7 | 10 |
|
8 | | -2. Assign issue owner: All new issues are assigned an owner on the NGINX engineering team. This owner shepherds the issue through the subsequent stages in the issue lifecycle. |
| 11 | +2. Assign issue owner: All new issues are assigned an owner on the NGINX engineering team. This owner shepherds the |
| 12 | + issue through the subsequent stages in the issue lifecycle. |
9 | 13 |
|
10 | 14 |
|
11 | | -3. Determine issue type: This is done with automation where possible, and manually by the owner where necessary. The associated label is applied to the issue. |
| 15 | +3. Determine issue type: This is done with automation where possible, and manually by the owner where necessary. The |
| 16 | + associated label is applied to the issue. |
12 | 17 | #### Possible Issue Types |
13 | | - `needs more info`: The owner should use the issue to request information from the creator. If we don't receive the needed information within 7 days, automation closes the issue. |
| 18 | + `needs more info`: The owner should use the issue to request information from the creator. If we don't receive the |
| 19 | + needed information within 7 days, automation closes the issue. |
14 | 20 |
|
15 | 21 | `bug`: The implementation of a feature is not correct. |
16 | 22 |
|
17 | | - `proposal`: A new feature, tackling technical debt, documentation changes, or improving existing features. |
| 23 | + `proposal`: An enhancement, tackling technical debt, documentation changes, or improving existing features. In cases |
| 24 | + where the enhancement requires an [Enhancement Proposal](/docs/proposals/README.md), the additional |
| 25 | + label `needs-enhancement-proposal` will be added. |
18 | 26 |
|
19 | 27 | `question`: The owner converts the issue to a github discussion and engages the creator. |
20 | 28 |
|
21 | 29 |
|
22 | | -4. Determine milestone: The owner, in collaboration with the wider team (product management & engineering), determines what milestone to attach to an issue. Generally, milestones correspond to product releases - however there are two special milestones not tied to a specific release: |
| 30 | +4. Determine milestone: The owner, in collaboration with the wider team (product management & engineering), determines |
| 31 | + what milestone to attach to an issue. Generally, milestones correspond to product releases - however there are two |
| 32 | + special milestones not tied to a specific release: |
23 | 33 |
|
24 | | - - Issues assigned to `backlog`: Our team is in favour of implementing the feature request/fixing the issue, however the implementation is not yet assigned to a concrete release. If and when a `backlog` issue aligns well with our roadmap, it will be scheduled for a concrete iteration. We review and update our roadmap at least once every quarter. The `backlog` list helps us shape our roadmap, but it is not the only source of input. Therefore, some `backlog` items may eventually be closed as `out of scope`, or relabelled as `backlog candidate` once it becomes clear that they do not align with our evolving roadmap. |
| 34 | + - Issues assigned to `backlog`: Our team is in favour of implementing the feature request/fixing the issue, however |
| 35 | + the implementation is not yet assigned to a concrete release. If and when a `backlog` issue aligns well with our |
| 36 | + roadmap, it will be scheduled for a concrete iteration. We review and update our roadmap at least once every |
| 37 | + quarter. The `backlog` list helps us shape our roadmap, but it is not the only source of input. Therefore, |
| 38 | + some `backlog` items may eventually be closed as `out of scope`, or relabelled as `backlog candidate` once it |
| 39 | + becomes clear that they do not align with our evolving roadmap. |
25 | 40 |
|
26 | | - - Issues assigned to `backlog candidate`: Our team does not intend to implement the feature/fix request described in the issue and wants the community to weigh in before we make our final decision. |
| 41 | + - Issues assigned to `backlog candidate`: Our team does not intend to implement the feature/fix request described in |
| 42 | + the issue and wants the community to weigh in before we make our final decision. |
27 | 43 |
|
28 | | - `backlog` issues can be labeled by the owner as `help wanted` and/or `good first issue` as appropriate. |
| 44 | + `backlog` issues can be labeled by the owner as `help wanted` and/or `good first issue` as appropriate. |
29 | 45 |
|
30 | 46 |
|
31 | | -5. Promotion of `backlog candidate` issue to `backlog` issue: If an issue labelled `backlog candidate` receives more than 30 upvotes within 60 days, we promote the issue by applying the `backlog` label. While issues promoted in this manner have not been committed to a particular release, we welcome PRs from the community on them. |
| 47 | +5. Promotion of `backlog candidate` issue to `backlog` issue: If an issue labelled `backlog candidate` receives more |
| 48 | + than 30 upvotes within 60 days, we promote the issue by applying the `backlog` label. While issues promoted in this |
| 49 | + manner have not been committed to a particular release, we welcome PRs from the community on them. |
32 | 50 |
|
33 | | - If an issue does not make our roadmap and has not been moved to a discussion, it is closed with the label `out of scope`. The goal is to get every issue in the issues list to one of the following end states: |
| 51 | + If an issue does not make our roadmap and has not been moved to a discussion, it is closed with the |
| 52 | + label `out of scope`. The goal is to get every issue in the issues list to one of the following end states: |
34 | 53 |
|
35 | | - - An assigned release. |
36 | | - - The `backlog` label. |
37 | | - - Closed as `out of scope`. |
| 54 | + - An assigned release. |
| 55 | + - The `backlog` label. |
| 56 | + - Closed as `out of scope`. |
0 commit comments