Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[chore] diagram defining different states for issues #36975

Open
wants to merge 9 commits into
base: main
Choose a base branch
from
55 changes: 55 additions & 0 deletions issue-triaging.md
Original file line number Diff line number Diff line change
Expand Up @@ -71,3 +71,58 @@ triaged and is ready for work. If someone who is assigned to an issue is no long
| `Sponsor Needed` | A new component has been proposed, but implementation is not ready to begin. This can be because a sponsor has not yet been decided, or because some details on the component still need to be decided. |
| `Accepted Component` | A sponsor has elected to take on a component and implementation is ready to begin. |
| `Vendor Specific Component` | This should be applied to any component proposal where the functionality for the component is particular to a vendor. |

### State diagram

Here is a diagram outlining the potential issue states and how issues move through different stages:
VihasMakwana marked this conversation as resolved.
Show resolved Hide resolved

```mermaid
flowchart TD
n0(["New issue has been opened"]) --> n1
n1(["Needs Triage"]) --> n2["Has good repro steps <br>and/or description?"]
subgraph graph2["**waiting-for-codeowners**"]
n3["Waiting for Codeowners<br>to further validate the issue"]
VihasMakwana marked this conversation as resolved.
Show resolved Hide resolved
end
subgraph graph3["**waiting-for-author**"]
n4["Waiting for author to provide more details"]
end
subgraph graph4["**help-wanted**"]
n8["Waiting on community"]
end
subgraph graph5["**closed**"]
n10(["Close the issue and provide details as needed"])
end
n2 -- Yes --> n3
n2 -- No/Need more details --> n4
n2 -- Invalid configuration/alternative available --> n10
n3 -- Invalid Issue --> n10
n3 -- Valid Issue --> n6["Codeowner has time<br>to fix it?"]
VihasMakwana marked this conversation as resolved.
Show resolved Hide resolved
n6 -- Assign it to codeowner --> n7["Issue in being worked upon"]
n6 -- No --> n8
n7 -- Once PR is merged --> n10
n8 -- When someone volunteers to provide a fix --> n11["Assign it to the person"]
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Should we add another section here for when the assigned person becomes stale? We often see someone starts to work on something but ends up having other higher priorities come up, and can't work on it anymore. Someone else will sometimes volunteer to take over the work, or the issue simply becomes inactive/stale.

I'm not blocking this PR, maybe it's something that can be added later depending on how detailed we're looking to get here.

n12 -- Any activity? --> n8
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is this meant to be a question? I think it would be more clear if we made it a statement in either direction. If there's no activity it's closed automatically which is stated in this chart. So I think it would make sense to simply make this box "Any activity" to remove the stale label.

n8 -. Stale issue .-> n12["Issue in inactive"]
VihasMakwana marked this conversation as resolved.
Show resolved Hide resolved
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

"Issue in inactive" isn't clear as a whole thought.

Should it be "Issue is inactive", or maybe "Issue in inactive state"?

n11 --> n7
n12 -- Closed automatically after 120 days due to lack of activity --> n10
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Should we try to define when an issue should be labeled never stale or let it be closed automatically here? It's a bit of a grey area, but it would be good to have some kind of consistent reasoning behind never stale.

We can probably file a follow up issue to discuss, it doesn't have to block this,

n4 -- Once enough details are available --> n2

n3@{ shape: rect}
n4@{ shape: rect}
n2@{ shape: diam}
n6@{ shape: diam}

n1:::Aqua
n3:::Ash
n4:::Ash
n8:::Ash
n2:::Ash
n2:::Peach
n6:::Peach
n7:::Ash
n10:::Rose
classDef Rose stroke-width:1px, stroke-dasharray:none, stroke:#FF5978, fill:#FFDFE5, color:#8E2236
classDef Aqua stroke-width:1px, stroke-dasharray:none, stroke:#46EDC8, fill:#DEFFF8, color:#378E7A
classDef Peach stroke-width:1px, stroke-dasharray:none, stroke:#FBB35A, fill:#FFEFDB, color:#8F632D
classDef Ash stroke-width:1px, stroke-dasharray:none, stroke:#999999, fill:#EEEEEE, color:#000000
```
Loading