Proposal: Auto-assign contributors to help wanted issues via /assign command

[rtibbles]

❌ This issue is not open for contribution. Visit Contributing guidelines to learn about the contributing process and how to find suitable issues.

Current behavior

When a contributor comments on an unassigned help wanted issue, a Slack notification is sent to #support-dev. A team member then needs to manually review and assign the contributor to the issue. This creates delays and requires manual intervention for every assignment.

Desired behavior

Add a /assign slash command that allows contributors to self-assign to help wanted issues, with safeguards to prevent abuse.

How it works:

• The help wanted header (automatically added to issues) is updated to include instructions to comment /assign and a note about the 2-issue maximum limit
• When a contributor comments /assign on an eligible issue (labeled help wanted, currently unassigned), the bot automatically assigns them and posts a confirmation
• Contributors are limited to a maximum of 2 assigned issues at a time across all community repositories (kolibri, studio, kolibri-design-system, le-utils, .github, ricecooker)
• To prevent issue shopping (dropping issues to grab more interesting ones), issues unassigned within the last 7 days still count toward the 2-issue limit
• When a contributor is at the limit, the bot declines and lists their current assignments (and recently dropped issues with remaining cooldown days)

What stays the same:

• Existing Slack notifications for issue comments
• Existing bot replies for non-eligible issues (BOT_MESSAGE_ISSUE_NOT_OPEN, BOT_MESSAGE_ALREADY_ASSIGNED)
• All close contributor and core team handling

/assign behavior

Contributor type	Issue type	Comment	Action
Core team	Any	/assign	No action (not a contributor)
Close contributor	Any	/assign	No action (not processed)
Other	Unassigned help-wanted	/assign (under limit)	Assign user, bot confirms
Other	Unassigned help-wanted	/assign (at limit)	Bot declines, lists current + recently dropped assignments
Other	help-wanted assigned to someone else	/assign	Bot says already assigned (existing behavior)
Other	Not help-wanted	/assign	Bot says not open for contribution (existing behavior)

Value add

• Eliminates manual assignment overhead for the team - no more monitoring Slack and manually assigning contributors to issues
• Faster turnaround for contributors - they can start working immediately instead of waiting for a team member to assign them
• The 2-issue limit and 7-day cooldown enforce good contribution habits (focus on completing work, not grabbing issues)

Possible tradeoffs

• The GitHub App token needs issue write permissions (assign) in addition to the existing comment permissions - this may need to be verified/updated in consuming repositories
• The 7-day cooldown on recently unassigned issues requires querying issue timeline events across all community repos, which adds API calls
• The 2-issue limit is org-wide across all community repos - a contributor can't have e.g. 2 issues in kolibri and 1 in studio. This is intentional but worth noting for the team

Acceptance Criteria

• The help wanted issue header includes instructions to comment /assign and mentions the 2-issue limit
• Commenting /assign on an unassigned help wanted issue assigns the commenter and posts a confirmation message
• Contributors with 2+ currently assigned issues (across all community repos) are declined with a message listing their assignments
• Issues unassigned within the last 7 days count toward the 2-issue limit
• The decline message shows both current assignments and recently dropped issues with remaining cooldown days
• /assign on a non-help wanted issue or an already-assigned issue is handled by existing bot messages
• Existing Slack notification behavior is unchanged
• Documentation in docs/community-automations.md is updated

[MisRob]

Hi, thanks. When we first considered this some time ago, I felt rather conflicted. With the safeguards in place and the considerations below addressed, I think we can try it and see how it goes. It adds scalability and, during times with many assignment requests, will help the support rotation.

Concerns

• On my projects, I prefer that people don’t self-assign Medium–High Complexity issues. These issues are help wanted, but not good first issue. I do make exceptions, but generally I want to assign these only after I’ve seen a contributor successfully resolve a few Low Complexity issues (labeled good first issue). And in general, I think we should allow ourselves some flexibility.
• If we allow assignment on some issues but not others, we need clear communication so team members don’t have to explain repeatedly.
• I feel hesitant about updating issue headers during the experimental stage of a new approach so we don’t end up with conflicting information over time. I see headers as fairly general and stable, and I also think we’ll need quite a bit of related guidance that may need quick updates as we observe misunderstandings.
• Quite commonly, contributors don’t link PRs to issues properly. To avoid having to explain why self-assignment doesn’t work for someone who has already assigned 2 issues with 2 PRs, we should include clear guidance and ask them to link PRs themselves.
• When someone self-assigns, there’s no need to send a notification to #support-dev.

How to possibly address them

• Only allow self-assignment when an issue is labeled both help wanted and good first issue.
• When the good first issue label is applied, LE bot posts guidance in an issue comment that:
  • This can be self-assigned via the command
  • Before doing so, contributors must link open PRs to assigned issues; otherwise, the detection mechanism won’t allow self-assignment.
  • Explains the limits in place and other relevant information.
• It would be good if the LE bot also communicated that issues labeled help wanted but not good first issues are not available for self-assignment. I’m pretty sure new contributors will expect otherwise after using it on other issues, and I’d like we don't need to explain all the time.
  • Technically I could think of more approaches, but due to async nature of the two labels assignment, I think it'd be simplest to just utilize a similar approach as suggested above "When a contributor is at the limit, the bot declines and lists their current assignments". So when a contributor comments on help wanted & non-good first issue, the bot would decline explaining that only good first issues are to be self-assigned.
• Do not send self-assignment notifications to #support-dev, but do send them to #support-dev-notifications:
  • <contributor handle> requested self-assignment <issue title as link to the issue>

Questions

• Regarding the note about cooldown ~ does it suggest that people will have the option to self-unassign and how will they do it?

Other notes

• All affected workflows need to be tested under all conditions before merge, especially if we aim to start using it during this high-traffic period.
• I appreciate the docs table. The Notion Advocate should be updated with a brief note on this mechanism and reference to it. We will also need to announce the change to the community.
• If this works well, in the long run we could build on it and automate self-assignment of non-good first issues ~ for example, by checking that a contributor has resolved 3–5 good first issues. Or we could even add more nuance and use complexity labels for gradual progression from low → medium → high.

[MisRob]

@rtibbles @akolson how does the above sound and do you have any further thoughts?

Also, I'm marking the original issue as "Proposal". It'd be good to preserve this discussion and I'd be grateful to see the final spec in another issue after we've decide on points in question. I will then link it on the Advocate docs and it can serve as reference whenever needed ~ this will be an area we will likely iterate on.

[MisRob]

Also to confirm do I understand right that the current script, contributor-issue-comment, would newly take care of /assign comments? Rather than having another new script? Seems it'd be simplest, and also in terms of documentation most readable approach. Otherwise I think there would be lots of conflicting areas we'd need to coordinate between the two.

[MisRob]

One more thought ~ if we could send notifications to #support-dev-notifications about other bot activity too, that'd be helpful. Quickly I can think of at least 3 categories:

• When issue assignment requested (by a contributor)
• When issue assignment approved (by the bot)
• When issue assignment rejected (by the bot)

Basically we can just build on the current pattern. I monitor the channel to have an overall sense of activity, to see whether/how all automations work, and on some occasions I chime in with additional guidance.

[MisRob]

Finally, I've just recalled that there's a logic that is able to recognize an assignment request (based on keywords, such as 'work', 'assign', etc.) vs other comment. It'll be important to not remove it because it will still be needed for non-good first issues (if we agree on that suggestion)

On good first issues we could actually utilize it too and in addition to

When the good first issue label is applied, LE bot posts guidance in an issue comment that: ...

have a bot send the same /assign guidance message whenever someone asks for an assignment 'Can I get assigned' etc. not realizing there's the command (many people don't scroll). And the implementation should at the very minimum re-use this optimization to prevent bot overwhelm. Alternatively, we could improve the optimization on this opportunity as discussed in the past ~ that is to rather delete the previous same bot message before re-posting it.