Support /assign and /unassign comment commands for self-assignment and unassignment

[yugalkaushik]

Increasing Access

These commands make it easier for contributors to take and release ownership of tasks with a simple comment. It encourages participation from newcomers, reduces reliance on maintainers, and helps avoid duplicate or concurrent work by clearly showing who is (or isn’t) working on an issue.

Feature request details

Add a GitHub Action that listens for issue and PR comments:

• When someone comments /assign, they are assigned to the thread.

• When they comment /unassign, they are removed.

[raclim]

Hey, thanks for raising this issue!

I think this is a great idea to start with! Looking at the attached PR, maybe we could update the comment to be a bit more specific and intentional? For example, something like “I’d like to be assigned to this issue”, so a maintainer has a chance to review the issue first before it’s assigned and someone begins working on it.

From my understanding of your PR, it seems like the current flow is that someone can be automatically assigned right after opening an issue if they note that they're interested. I wonder if there's a way to add a step in between so a maintainer can confirm if we're ready to move forward with an issue before someone invests time into one we might not be able to accept. Let me know what your thoughts are on this!

[samarth-na]

We can add a step where it only assigns if a contributor comments /confirms

[NalinDalal]

Yes, working on it with @samarth-na @raclim

[NalinDalal]

So what if the maintainer can directly add a comment action like /approach or /go-ahead
How about it

Proposed Flow Using /goahead or /approach
Flow Summary:

Contributor comments /assign → Not assigned yet.
Maintainer reviews and if it’s a valid issue, they comment /goahead or /approach or /confirm.
Once /goahead is present, the next /assign by the contributor will succeed.

Why This Is Better
Maintains contributor initiative — they show intent with /assign.
Keeps maintainers in the loop — they can approve what's worth working on.
Prevents wasted work — contributors don’t start working on invalid, duplicate, or sensitive issues.
Clean UX — no need to guess if it's okay to self-assign.