search

MarkBind / markbind

MarkBind is a tool for generating content-heavy websites from source files in Markdown format
https://markbind.org/
MIT License
134 stars 123 forks source link

Add github action to automatically unassign issues after a certain period of inactivity #2495

Open yucheng11122017 opened 3 months ago

yucheng11122017 commented 3 months ago

Please confirm that you have searched existing issues in the repo

Yes, I have searched the existing issues

Any related issues?

No response

What is the area that this feature belongs to?

DevOps

Is your feature request related to a problem? Please describe.

Sometimes people forget about their issues after getting assigned but they don't do it. This leads to issue hogging.

Describe the solution you'd like

Add a github action to automatically ping the user after a certain time reminding them about their issue.

Add a github action to automatically unassign user after certain period of inactivity

Describe alternatives you've considered

Existing github action for inactivity

https://github.com/marketplace/actions/unassign-contributor-after-days-of-inactivity

Would need to do some checking to see how this works.

Additional context

No response

KevinEyo1 commented 3 months ago

Hi @yucheng11122017, the definition of inactivity for the github action you mentioned is any form of history to the issue, be it labelling, comments or references. What do you think would be a good timeline to unassign? I think 1 week might be too short since some issues can take longer than that before any PRs are made, especially with users juggling multiple issues. Perhaps 10-14 days will be good? I think any longer would be pointless, considering the timeline of a sem.

As for how it works (assuming action/stale is used):

  1. Stale label added based on inactivity (default 60 days)
  2. This action routinely checks for this Stale label, then checks whether its been a set amount of days after the Stale label has been added with no other activity
  3. For issues passing the check before, it un-assigns users and removes Stale label
yucheng11122017 commented 3 months ago

Hi @yucheng11122017, the definition of inactivity for the github action you mentioned is any form of history to the issue, be it labelling, comments or references. What do you think would be a good timeline to unassign? I think 1 week might be too short since some issues can take longer than that before any PRs are made, especially with users juggling multiple issues. Perhaps 10-14 days will be good? I think any longer would be pointless, considering the timeline of a sem.

As for how it works (assuming action/stale is used):

  1. Stale label added based on inactivity (default 60 days)
  2. This action routinely checks for this Stale label, then checks whether its been a set amount of days after the Stale label has been added with no other activity
  3. For issues passing the check before, it un-assigns users and removes Stale label

Hmmm tbh I think a week is good. Even if there is problems opening a PR for the issue, I feel like the person should be at least updating or commenting after a week.

Is it possible for us to do like after 6 days, ping them to remind them about the issue and the upcoming deadline? Than at 7 days, we unassign.

One problem that I would be concerned about is the pollution of the issue thread with unnecessary comments, where there are just many reminders with no value add to the conversation.

Wdyt? @KevinEyo1

KevinEyo1 commented 3 months ago

Hi @yucheng11122017 I think that would work, where I code it to add the Stale label after 6 days, then have the unassign-contributor-after-days-of-inactivity run 1 day after. I can also only do the check on issues that are actually assigned to someone, so that theres no redundancy.

Are we fine with adding Stale labels added to issues?

yucheng11122017 commented 3 months ago

Hi @yucheng11122017 I think that would work, where I code it to add the Stale label after 6 days, then have the unassign-contributor-after-days-of-inactivity run 1 day after. I can also only do the check on issues that are actually assigned to someone, so that theres no redundancy.

Are we fine with adding Stale labels added to issues?

This sounds like a great idea! Yeah then labels wouldn't spam the issue also :) Please go ahead

KevinEyo1 commented 2 months ago

Hi @yucheng11122017, after researching into this abit more, it might be quite tough to ping the user directly, reminding them in a comment, since that will cause the issue to no longer be Stale. Commenting a generic comment asking the contributor to do something is fine though. So "Please whoever is assigned this, get to it." is fine but "Please @KevinEyo1, get to it" won't work.

yucheng11122017 commented 2 months ago

Hi @yucheng11122017, after researching into this abit more, it might be quite tough to ping the user directly, reminding them in a comment, since that will cause the issue to no longer be Stale. Commenting a generic comment asking the contributor to do something is fine though. So "Please whoever is assigned this, get to it." is fine but "Please @KevinEyo1, get to it" won't work.

I see... I think it would be easy for a user to miss out on the generic comment without being pinged directly though...

kaixin-hc commented 2 months ago

I feel a reminder that the issue is about to go stale is somewhat unnecessary? How about when you unassign the user, you ping them that they have been unassigned from the issue - then if they are continuing to work on the issue, they can reassign themselves and state that they plan on continuing on the issue.

How does this work with issues that have open PRs, where work and discussion is happening on the PR? I'm worried the contributor will be unassigned from the issue when they are actively working on it in a PR

KevinEyo1 commented 2 months ago

The definition of inactivity for the GitHub action mentioned is any form of history to the issue, be it labeling, comments or references. The action works such that issues and PRs are treated and checked for inactivity separately. This means that any updates done to a PR regarding this issue, will not reset inactivity for the issue.

How unassign and stale actions work:

  1. Stale action adds Stale label to issue or PR based on inactivity (default 60 days)
  2. Unassign action routinely checks for this Stale label, then checks whether it's been a set amount of days after the Stale label has been added with no other activity (default 7 days)
  3. For issues passing the check before, it un-assigns users and removes Stale label

Reference workflow of real-life example: https://github.com/BoundfoxStudios/fairy-tale-defender/blob/develop/.github/workflows/project-management.yml#L105

Solution using unassign and stale actions

Add the Stale label after 6 days and ping a reminder, then have the unassign-contributor-after-days-of-inactivity run 1 day after. It can also only check on issues that are actually assigned to someone, so that theres no redundancy. Limitations:

  1. Any changes in PR regarding issue will not reset inactivity of issue, meaning if discussion and updates are done on the PR instead of the issue, the issue risks being Stale and the user being unassigned despite them actively working on the PR.
  2. It can ping a general reminder (without resetting the inactivity) but it cannot ping the user directly with @username in the reminder due to how the code is written. It is possible to separately ping the user in another comment but that will cause a reset in inactivity. This means slightly lower visibility for the reminder.

Improvements for limitation 1

(building on unassign action, which at some point it might be better off just building our own unassign action for better integration and control) Check corresponding PR (requires more implementation) Add additional check before setting Stale label to check if corresponding PR has history. This can be done through checking the list of open PRs and their descriptions whether it mentions the issue. It can also be done through looking at the issue’s history, for PRs that mention it, then checking the history of those PRs. This should be quite manageable since the number of open PRs at any point of time is still relatively low for Markbind’s scale.

Check corresponding issue (requires more implementation) On any activity in PRs, check description to find issues linked to the PR, so activity on PR can be translated to activity on the issue as well by posting a comment on the corresponding issue or something of that nature. This might require checking for a specific issue that has the user assigned to avoid commenting on relevant but not directly linked issues, if the PR has multiple relevant issues. We can also only call it on commits instead of any activity, so as to avoid over-polluting the issue with comments.

Improvements for limitation 2

Ping after unassign Same as before, add Stale level after 6 days, but don't need to ping the user, wait until unassign 1 day after, then ping the user that they have been unassigned and if they are still working on it, ask them to reassign themselves. This would likely fit better with a longer timeline. This solves the visibility problem as it can directly ping the user as resetting the inactivity after the user has been unassigned wouldn't matter.

Implement our own stale action (requires more implementation) Implement a simplified version of stale action that now allows pinging of user before applying the Stale label