From 1dac95ec891714c6f09b72bf5135e27eb49dbecd Mon Sep 17 00:00:00 2001 From: see-quick Date: Wed, 11 Mar 2026 12:23:26 +0100 Subject: [PATCH 1/3] Asynchronous Issue Triage Signed-off-by: see-quick --- 133-async-triage.md | 91 +++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 91 insertions(+) create mode 100644 133-async-triage.md diff --git a/133-async-triage.md b/133-async-triage.md new file mode 100644 index 00000000..53beb2c1 --- /dev/null +++ b/133-async-triage.md @@ -0,0 +1,91 @@ +# Asynchronous Issue Triage + +This proposal introduces an asynchronous triage process for GitHub issues, allowing maintainers and component owners to triage issues outside of the community call using emoji reactions. +The process starts as a manual workflow with the goal of automating it in the future. + +## Current situation + +Currently, issue triage happens synchronously during community calls. +This takes up valuable call time and can delay triage for issues that are straightforward to evaluate. +Issues may sit untriaged until the next community call, even when maintainers already have a clear opinion on them. + +## Motivation + +Asynchronous triage allows maintainers to review and vote on issues at their own pace, freeing up community call time for issues that genuinely need discussion. +It also reduces the triage backlog by enabling continuous progress between calls. + +## Proposal + +> [!IMPORTANT] +> An issue is eligible for asynchronous triage when it is labeled `needs-triage`. +> Anyone creating a new issue (or any maintainer) can add the `needs-triage` label to mark it for async triage. + +### Voting mechanism + +Maintainers and component owners indicate their opinion using emoji reactions on the issue: + +| Reaction | Meaning | +|----------|---------------------------------------------------------------------------------| +| 👍 | We should keep this issue | +| 👎 | We should close this issue (with an explanatory comment) | +| 👀 | I saw this but want to discuss it further (ideally with an explanatory comment) | + +Only votes from maintainers and component owners count toward the triage decision. + +### Decision rules + +After at least **5 days** since the last major comment on the issue, the following rules apply: + +- **Approved (keep):** +No 👀 and no 👎, and at least 3 👍 reactions. +The issue is considered triaged and should be kept. +The `needs-triage` label is removed. +- **Rejected (close):** +No 👀 and no 👍, and at least 3 👎 reactions. +The issue is considered triaged and rejected. +It should be closed with an explanatory comment or with acknowledgment of another maintainer explanation. +- **Needs discussion:** +Any other mix of reactions (e.g., presence of 👀, mixed votes, or fewer than 3 votes). +The issue remains labeled `needs-triage` and is discussed at the next community call. + +### Additional labels + +- **`needs-proposal`:** +Can be added at any point by anyone who thinks the issue requires a formal proposal. +If the issue is approved via async triage, the label will remain. +- **`good-start` / `help-wanted`:** +The person marking the issue as triaged (or anyone else later) can add these labels if desired, but they should be ready to provide guidance to whoever wants to work on it. + +### Pre-call check + +Until automation is in place, the person running the community call should do a manual check of `needs-triage` issues before the call. +This ensures that issues which reached consensus asynchronously are cleaned up, and remaining issues are queued for discussion. + +### Future automation + +A bot, scanner, or cron job (to be investigated separately) could automate the process: + +- Monitor `needs-triage` issues for vote counts after the 5-day (i.e., 120 hours) window +- Automatically remove the `needs-triage` label when consensus is reached (based on decision rules stated above) + +## Affected/not affected projects + +This proposal affects the Strimzi project's issue triage workflow across all repositories. +No code changes are required initially (i.e., this is a process change). +Future automation tooling may be developed separately. + +## Compatibility + +This process is additive and does not replace synchronous triage during community calls. +Issues that do not reach async consensus are still discussed during the call as before. + +## Rejected alternatives + +### Using comments or commands instead of emoji reactions + +Using comments or bot commands (e.g., `/strimzi-triage +1`) was considered but rejected in favor of emoji reactions only. +Emoji reactions provide a quicker, more visible way to see the current vote count at a glance without cluttering the issue with additional comments. + +### 72-hour triage window + +An initial 72-hour window was discussed but extended to 5 days to give maintainers enough time to review issues, especially across different time zones and work schedules. \ No newline at end of file From 7b1a71211e5bfc50081dff0d957607a5bda93a90 Mon Sep 17 00:00:00 2001 From: Maros Orsak Date: Wed, 11 Mar 2026 16:05:56 +0100 Subject: [PATCH 2/3] Apply suggestions from code review Co-authored-by: Jakub Scholz Signed-off-by: Maros Orsak --- 133-async-triage.md | 7 ++++--- 1 file changed, 4 insertions(+), 3 deletions(-) diff --git a/133-async-triage.md b/133-async-triage.md index 53beb2c1..2839a663 100644 --- a/133-async-triage.md +++ b/133-async-triage.md @@ -18,11 +18,11 @@ It also reduces the triage backlog by enabling continuous progress between calls > [!IMPORTANT] > An issue is eligible for asynchronous triage when it is labeled `needs-triage`. -> Anyone creating a new issue (or any maintainer) can add the `needs-triage` label to mark it for async triage. +> All new issues should be marked with the label `needs-triage` when/after they are created. ### Voting mechanism -Maintainers and component owners indicate their opinion using emoji reactions on the issue: +Maintainers and component owners with merge rights in the given repository indicate their opinion using emoji reactions on the issue: | Reaction | Meaning | |----------|---------------------------------------------------------------------------------| @@ -30,7 +30,8 @@ Maintainers and component owners indicate their opinion using emoji reactions on | 👎 | We should close this issue (with an explanatory comment) | | 👀 | I saw this but want to discuss it further (ideally with an explanatory comment) | -Only votes from maintainers and component owners count toward the triage decision. +Any user is encouraged to share their opinion. +But only votes from maintainers and component owners with merge rights in the given repository count toward the triage decision. ### Decision rules From bf6f69e9ecd749ae8003e9b2e163fb3f6ae36c46 Mon Sep 17 00:00:00 2001 From: see-quick Date: Fri, 13 Mar 2026 10:08:30 +0100 Subject: [PATCH 3/3] address reviews Signed-off-by: see-quick --- 133-async-triage.md | 16 ++++++++++------ 1 file changed, 10 insertions(+), 6 deletions(-) diff --git a/133-async-triage.md b/133-async-triage.md index 2839a663..a41a11a0 100644 --- a/133-async-triage.md +++ b/133-async-triage.md @@ -16,13 +16,13 @@ It also reduces the triage backlog by enabling continuous progress between calls ## Proposal -> [!IMPORTANT] -> An issue is eligible for asynchronous triage when it is labeled `needs-triage`. -> All new issues should be marked with the label `needs-triage` when/after they are created. +> [!IMPORTANT] +> Issues that require triage should be marked with the label needs-triage when or after they are created. +> Straightforward issues (e.g., simple fixes or dependency version bumps) do not necessarily require triage and may proceed directly with a pull request. ### Voting mechanism -Maintainers and component owners with merge rights in the given repository indicate their opinion using emoji reactions on the issue: +Maintainers and component owners with merge rights in the given repository indicate their opinion using emoji reactions on the original issue post: | Reaction | Meaning | |----------|---------------------------------------------------------------------------------| @@ -35,7 +35,7 @@ But only votes from maintainers and component owners with merge rights in the gi ### Decision rules -After at least **5 days** since the last major comment on the issue, the following rules apply: +After at least **5 days** since the issue was created, the following rules apply: - **Approved (keep):** No 👀 and no 👎, and at least 3 👍 reactions. @@ -60,7 +60,11 @@ The person marking the issue as triaged (or anyone else later) can add these lab ### Pre-call check Until automation is in place, the person running the community call should do a manual check of `needs-triage` issues before the call. -This ensures that issues which reached consensus asynchronously are cleaned up, and remaining issues are queued for discussion. +Specifically, this means: + +- Removing the `needs-triage` label from issues that reached consensus (approved or rejected) +- Closing rejected issues (with an explanatory comment if not already provided) +- Preparing the remaining unresolved issues as discussion items for the call agenda ### Future automation