feat: add issue approval workflow

[Manancode]

TL;DR
New Issue Created / Reopened

Automatically labels contributor issues with status/to-be-triaged.
Posts a welcome / info comment explaining that a maintainer must triage/approve first.
Issues opened by CODEOWNERS (maintainers) skip the queue and get status/triaged.
Bot‑created issues are ignored and left alone.
Maintainer Triage on Issues

When a CODEOWNER comments on an untriaged issue, it’s auto‑triaged to status/triaged.
Conflicting labels like status/not-needed or status/to-be-triaged are cleaned up.
Issues by CODEOWNERS are auto‑triaged as soon as they’re opened or reopened.
Automated Issue Reminders & Soft Closure

For issues stuck in status/to-be-triaged:
2–3 weeks: Posts first reminder comment
5–6 weeks: Posts second reminder comment
60+ days: Adds bot/to-be-closed label and pings maintainers to decide (triage/close/keep-open).
Issues closed without being marked “done” are normalized to status/not-needed.
A keep-open label lets maintainers override the closure pipeline.
Pull Requests – Linking to Approved Issues

Linked issues are discovered via GraphQL with regex fallback on the PR body.
If no linked issue is found, the PR gets a no-linked-issue label and a comment asking to link an approved issue.
PRs from CODEOWNERS are exempt from this enforcement.
Pull Requests – Issue Approval Enforcement

If a PR links to an issue that is still status/to-be-triaged:
A bot comment asks the contributor to pause work until maintainers approve the issue.
The PR is kept out of in-review status.
If a PR links to a status/triaged issue:
The issue is moved to status/in-progress.
The PR is labeled status/in-review (and no-linked-issue is removed if present).
PR Activity & Contributor Response Flow

When maintainers are waiting on contributor changes, they can move the PR to status/waiting-response.
If new commits are pushed after that:
status/waiting-response is removed.
status/ready-for-rereview is added so reviewers know to look again.
For PRs in status/waiting-response:
1–2 weeks since last commit: gentle ping asking for updates.
2–3 weeks since last commit: PR is marked bot/to-be-closed and maintainers are asked to review/close.
PRs Without Linked Approved Issues

For PRs with no-linked-issue:
1–2 weeks since PR creation: first reminder to link an approved issue.
2–3 weeks: second, stronger reminder.
3–4 weeks: bot/to-be-closed added and maintainers are pinged to decide.
Merged & Closed PRs

When a PR is merged:
PR labels like status/in-review and no-linked-issue are removed.
PR is marked status/done.
Linked issues have “in‑progress / triage” labels removed and are marked status/done.
When a PR is closed without merge:
Review/triage labels are removed (status/in-review, no-linked-issue).
PR is marked status/not-needed.
Reopened PRs

When a PR is reopened:
Any closure labels (status/not-needed, status/done) are removed.
Linked issues are re‑detected via GraphQL + regex.
If no linked issue: no-linked-issue label + comment asking to link one.
If linked issue is still status/to-be-triaged: comment tells contributor to pause until approval.
If linked issue is status/triaged:
Issue is moved to status/in-progress.
PR is labeled status/in-review.

ps: some of the commits were made after screenshot timings. will be updated

[github-actions]

Welcome to AsyncAPI. Thanks a lot for creating your first pull request. Please check out our contributors guide useful for opening a pull request.
Keep in mind there are also other channels you can use to interact with AsyncAPI community. For more details check out this issue.

[princerajpoot20]

FYI: asyncapi/website#3742 (comment)
It is not ready for review. The design is yet to be finalized.

[princerajpoot20]

/dnm

[Manancode]

new flow: discussed here

TL;DR

New Issue Created / Reopened

• Automatically labels contributor issues with status/to-be-triaged.
• Posts a welcome / info comment explaining that a maintainer must triage/approve first.
• Issues opened by CODEOWNERS (maintainers) skip the queue and get status/triaged.
• Bot‑created issues are ignored and left alone.

Maintainer Triage on Issues

• When a CODEOWNER comments on an untriaged issue, it’s auto‑triaged to status/triaged.
• Conflicting labels like status/not-needed or status/to-be-triaged are cleaned up.
• Issues by CODEOWNERS are auto‑triaged as soon as they’re opened or reopened.

Automated Issue Reminders & Soft Closure

• For issues stuck in status/to-be-triaged:
  • 2–3 weeks: Posts first reminder comment
  • 5–6 weeks: Posts second reminder comment
  • 60+ days: Adds bot/to-be-closed label and pings maintainers to decide (triage/close/keep-open).
• Issues closed without being marked “done” are normalized to status/not-needed.
• A keep-open label lets maintainers override the closure pipeline.

Pull Requests – Linking to Approved Issues

• Linked issues are discovered via GraphQL with regex fallback on the PR body.
• If no linked issue is found, the PR gets a no-linked-issue label and a comment asking to link an approved issue.
• PRs from CODEOWNERS are exempt from this enforcement.

Pull Requests – Issue Approval Enforcement

• If a PR links to an issue that is still status/to-be-triaged:
  • A bot comment asks the contributor to pause work until maintainers approve the issue.
  • The PR is kept out of in-review status.
• If a PR links to a status/triaged issue:
  • The issue is moved to status/in-progress.
  • The PR is labeled status/in-review (and no-linked-issue is removed if present).

PR Activity & Contributor Response Flow

• When maintainers are waiting on contributor changes, they can move the PR to status/waiting-response.
• If new commits are pushed after that:
  • status/waiting-response is removed.
  • status/ready-for-rereview is added so reviewers know to look again.
• For PRs in status/waiting-response:
  • 1–2 weeks since last commit: gentle ping asking for updates.
  • 2–3 weeks since last commit: PR is marked bot/to-be-closed and maintainers are asked to review/close.

PRs Without Linked Approved Issues

• For PRs with no-linked-issue:
  • 1–2 weeks since PR creation: first reminder to link an approved issue.
  • 2–3 weeks: second, stronger reminder.
  • 3–4 weeks: bot/to-be-closed added and maintainers are pinged to decide.

Merged & Closed PRs

• When a PR is merged:
  • PR labels like status/in-review and no-linked-issue are removed.
  • PR is marked status/done.
  • Linked issues have “in‑progress / triage” labels removed and are marked status/done.
• When a PR is closed without merge:
  • Review/triage labels are removed (status/in-review, no-linked-issue).
  • PR is marked status/not-needed.

Reopened PRs

• When a PR is reopened:
  • Any closure labels (status/not-needed, status/done) are removed.
  • Linked issues are re‑detected via GraphQL + regex.
  • If no linked issue: no-linked-issue label + comment asking to link one.
  • If linked issue is still status/to-be-triaged: comment tells contributor to pause until approval.
  • If linked issue is status/triaged:
    • Issue is moved to status/in-progress.
    • PR is labeled status/in-review.

[princerajpoot20]

@Manancode
I’ll take a look at this next week.

From the screenshots you added, we don’t need a workflow for /assign and /reject. I have mentioned the reasoning in the discussion itself.
In short, it simply does not make sense. If you want to close an issue, why would you (as a maintainer) write /reject and wait for the workflow to close it, when we already have a close button below? Just click it. Its like making things unnecessarily complicated.

The same goes for /approve.
If the issue is approved, simply update the project board status. It’s just two simple clicks. Hence, we don’t need those.

[princerajpoot20]

Can you please attach the screenshots and evidence for all the scenarios, if any are left?

Also, please document the scenarios and explain what we will be doing in each case.

[princerajpoot20]

One more point: we don’t need to clutter the issue with these bot messages. Let’s keep it simple and not complicate it too much for new contributors.

For example, if we move an issue to the triaged state, there’s no need to add any comment on the issue, like "this issue is now approved by @ maintainer". Just update the label. that’s good enough.

Also, there’s no need to mention the timeline anywhere at the start. It feels repetitive. For users who already know the timeline, it’s just the same thing repeated again and again, and it can be frustrating sometimes. We can do this when the timeline is near exhaustion.

[Manancode]

From the screenshots you added, we don’t need a workflow for /assign and /reject. I have mentioned the reasoning in the discussion itself. In short, it simply does not make sense. If you want to close an issue, why would you (as a maintainer) write /reject and wait for the workflow to close it, when we already have a close button below? Just click it. Its like making things unnecessarily complicated.

The same goes for /approve. If the issue is approved, simply update the project board status. It’s just two simple clicks. Hence, we don’t need those.

yes i removed all of this as we discussed. The screenshots attached above is from the first commit itself. i will attach new screenshots here with the current flow.

One more point: we don’t need to clutter the issue with these bot messages. Let’s keep it simple and not complicate it too much for new contributors.

For example, if we move an issue to the triaged state, there’s no need to add any comment on the issue, like "this issue is now approved by @ maintainer". Just update the label. that’s good enough.

Also, there’s no need to mention the timeline anywhere at the start. It feels repetitive. For users who already know the timeline, it’s just the same thing repeated again and again, and it can be frustrating sometimes. We can do this when the timeline is near exhaustion.

sure will do it.

[Manancode]

@princerajpoot20 added screenshots here; lmk if u find anything while replicating it locally.