GitHub Action Bot Behaviour for Issue Assignment and Multiple PR Handling

[career-yashaswee]

GitHub Action Bot Behaviour for Issue Assignment and Multiple PR Handling

Describe the bug
Currently, when a user is assigned to an issue using the /attempt command, there is no restriction or notification when another contributor tries to work on the same issue. Additionally, there is no limit preventing a contributor from working on multiple issues simultaneously, which could lead to incomplete or delayed contributions, also, the maintainers have to do the hard work to intervene and handle the multiple PR Situations.

To Reproduce
Steps to reproduce the behavior:

1. Open a GitHub issue in the repository.
2. Use the /attempt command to assign yourself to the issue.
3. Have another contributor use the /attempt command on the same issue.
4. The system will assign both users to the same issue.
5. After the first contributor is assigned, have the first contributor use the /attempt command on another issue.
6. The system will assign the same user (the first contributor) to multiple issues.

Expected Behaviour

1. Issue Already Assigned Notification
   When a user is already assigned to an issue using the /attempt command:

   • If another contributor tries to claim the issue, the bot should tag the new user and reply with the message:
     "This issue is already assigned to another person. Please find more issues here."

2. Reminder to Current Assignee
   After assigning the issue, the bot should prompt the current assigned contributor with a message:
   "Assigned to <username>. Please open a draft PR linking this issue within 48h ⚠️ If we can't detect a PR from you linking this issue in 48h, you'll be unassigned automatically 🕹️ Excited to have you ship this 🚀"

3. Multiple PR Restriction
   If the user already has an open issue assigned to them:

   • The bot should reply with a message:
     "You already have an open issue assigned to you here. Once that's closed or unassigned, only then do we recommend you to take up more."
     This will ensure contributors focus on one issue at a time and avoid overcommitting.

Screenshots
If applicable, add screenshots to help explain your problem.
[https://github.com//issues/495](Check the interaction, in this Issue) with the bot, first contributor, second contributor and the maintainer.

Desktop (please complete the following information):

• OS: macOS Sonoma
• Browser : chrome
• Version : e.g. 22

Smartphone (please complete the following information):
NA

Additional context
Here is a https://github.com/mfts/papermark/issues/631 to an Issue, which takes advantage of such automation and strategy.

[career-yashaswee]

/attempt

[github-actions]

Assigned the issue to @career-yashaswee!

[Aleesssino]

Hi there,

Thanks for suggesting improvements to the bot’s behavior.. I agree with some of the ideas but have a couple of concerns, and I’d like to better understand certain aspects.

48-Hour Draft PR Requirement:

If I understand correctly, this means contributors need to submit a draft PR within 48 hours or they get unassigned? If so, that might be too strict. Many contributors balance open source work with other commitments, and this deadline could discourage participation. Instead, a gentler reminder after 48 hours, without automatic unassignment, would be more flexible and inclusive. We want to encourage contributions, not rush them.

Restriction on Multiple Issues:

I completely agree with the concern about contributors juggling too many issues, but I also think experienced contributors can handle multiple tasks. A more balanced approach could be to apply this restriction only to first-time contributors (if it's technically feasible). That way, newcomers can focus on one issue and learn the ropes, while experienced contributors can still manage multiple tasks if they feel comfortable.

Would love to hear what others think!

@kriptonian1, what’s your take on these suggestions?

[kriptonian1]

I agree with @Aleesssino for most of the part, but I am not totally convinced on the idea of restricting user from working on multiple issue. There might be some issue which are easier and some which are difficult, so let's say someone have a capacity to work on two easy issue at once, then we should allow them to. But one thing that I think we should have is that the bot should ping the contributors with dangling PR, because we have many PR that are just there half-baked, and we have to manually go through all the PR to ping them up.

@rajdip-b what are your thoughts on this ?

[career-yashaswee]

it’s clear that we all want the bot to strike the right balance between encouraging timely contributions and being flexible enough to accommodate different workflows.

48-Hour Draft PR Requirement:

@Aleesssino You’re absolutely right—enforcing a strict 48-hour deadline for draft PRs could feel a bit rushed for contributors with busy schedules. I love the idea of a gentler reminder instead of automatic unassignment. Perhaps we could implement a two-step approach:

• First Reminder at 48 Hours: A soft nudge, encouraging the contributor to share their progress or draft PR.
  Automatic Unassignment After a Week: If there's no activity or response after a week, then the bot can unassign them. This way, we give contributors more time, but still ensure issues are moving forward. And let the other contributors know, the issue is open for other contributors to contribute in.

• Automatic Unassignment After a Week: If there's no activity or response after a week, then the bot can unassign them. This way, we give contributors more time, but still ensure issues are moving forward.

Restriction on Multiple Issues:

• I also hear the concerns regarding the restriction on multiple issues. Maybe we can tweak this to account for contributor experience. For example:

• New Contributors: Restrict to one issue until their first PR is merged, helping them focus and learn the process.
  Experienced Contributors: Allow them to take on more than one issue, based on their capacity. We could include a soft limit (e.g., 2-3 issues max) to prevent overload but allow flexibility.

Dangling PRs:

I absolutely agree with @Aleesssino and @kriptonian1 about the need for a mechanism to ping contributors with unfinished PRs. We could have the bot send periodic reminders to contributors who have open PRs with no updates after a set number of days (e.g., 7 days). This would help reduce stale or half-baked PRs and keep communication active.

Waiting for @rajdip-b for their input, then would see, how we could tweak the system.

[rajdip-b]

No one drafted this issue yet, but I really like that you took the effort to build it from scratch!

As for the clarifications, I have worked with quite a lot of open-source projects. It's just surprising to see that almost all of these projects have the same issue with managing the bots and assigning issues to people. Fair play almost always gets replaced with unnecessary restrictions. So IMO let's do this.:

• Reminder after 48 hours. Unassignment after 2 weeks (some issues are huge to handle).
• We need a way to allow maintainers to specify NOT to unassign someone even if they have not submitted a draft PR after 2 weeks. We need this just so that we can have control over the bot. Maybe something like /keep @ username would help. Needless to say, only people belonging to keyshade will be able to issue this command.
• Let's put a hard cap on 5 concurrent issues at a time. If they try to attempt more, we just block them. Ensure that we are checking for the following conditions: issue open + PR not submitted / PR in draft state

[kriptonian1]

No one drafted this issue yet, but I really like that you took the effort to build it from scratch!

As for the clarifications, I have worked with quite a lot of open-source projects. It's just surprising to see that almost all of these projects have the same issue with managing the bots and assigning issues to people. Fair play almost always gets replaced with unnecessary restrictions. So IMO let's do this.:

• Reminder after 48 hours. Unassignment after 2 weeks (some issues are huge to handle).
• We need a way to allow maintainers to specify NOT to unassign someone even if they have not submitted a draft PR after 2 weeks. We need this just so that we can have control over the bot. Maybe something like /keep @ username would help. Needless to say, only people belonging to keyshade will be able to issue this command.
• Let's put a hard cap on 5 concurrent issues at a time. If they try to attempt more, we just block them. Ensure that we are checking for the following conditions: issue open + PR not submitted / PR in draft state

SGTM

[kriptonian1]

Maybe I'll be working on this issue, if no one else is picking it up

[rajdip-b]

@career-yashaswee lmk if you are working this up, or else i'll make this free to grab

[career-yashaswee]

Yup on it, just tackling my university exams here at the moment, would draft a PR by today possibly.

…

On Fri, 18 Oct, 2024, 5:15 pm Rajdip Bhattacharya, ***@***.***> wrote: @career-yashaswee <https://github.com/career-yashaswee> lmk if you are working this up, or else i'll make this free to grab — Reply to this email directly, view it on GitHub <#497 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/BI2Q33HQNNO4RRMDENF7FILZ4DYEDAVCNFSM6AAAAABQAXTYEWVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDIMRSGI3TSNRZHA> . You are receiving this because you were mentioned.Message ID: ***@***.***>