Replies: 4 comments 11 replies
-
|
Definitely a good idea, and I think the basic settings are enough. The only thing I see is possibly the times. Is 500 days too long and 28 days too short? Do we want the same length for both issues and pull requests? I can see issues usually being relevant for longer while old PRs more often it might be better to start from scratch - especially for Tool diagnostics and recipes to use newly introduced core features. |
Beta Was this translation helpful? Give feedback.
-
Good point! How about 100 days for PRs and 365 days for issues? And 30 days between flagging and closing? Since anyone can comment on them and they can be reopened with one click, I think that's fine. |
Beta Was this translation helpful? Give feedback.
-
|
sounds good to me. The 100 days for PRs would also poke truly open PRs to update to new main and ask for reviewers again. |
Beta Was this translation helpful? Give feedback.
-
|
Maybe that could even be in the message for PRs? Something like "If the inactivity is due to a lack of reviews, please tag the x team and add the labels "looking for scientific/technical reviewer" - without the @ in the message directly. |
Beta Was this translation helpful? Give feedback.
-
|
You can put an invisible element between the @ and the name to prevent it functioning. Then you can have a command people can copy-paste. For example |
Beta Was this translation helpful? Give feedback.
-
|
Sounds good! 28 days feels a bit short in case people are on vacation or something. On the other hand everyone can comment to unstale it. Reopening them if needed is also not a big deal. Would this also be applied to existing old issues retrospectively? |
Beta Was this translation helpful? Give feedback.
-
Yes, exactly, they can be reopened with a single click. And we are not deleting anything (e.g. branches), so there's no risk we lose any work.
Yes, this will be applied to all issues and pull requests in our repository. Since we have so many open issues/PRs, it might take a couple of days until all are processed though (depending on the |
Beta Was this translation helpful? Give feedback.
-
|
While really I like the idea of cleaning up, I am worried that we will scare off contributors who are less familiar with GitHub if we use overly zealous timings. For example, people may be disappointed that their perfectly reasonable issue got closed just because we did not have the development capacity, and may not feel enough ownership of the repository to reopen it. Typically, Iris contributors are more technically minded than our contributors, so it would make sense for us to use timings that are more relaxed. How about we start with:
and using a 2-month notice period? We can always make the timings shorter later, if we find that this does not sufficiently clean up the repository. We would also need to make sure that issues and pull requests can easily be reopened by people who are not members of our GitHub organization and that we communicate clearly how to do this. |
Beta Was this translation helpful? Give feedback.
-
|
Technically the 500 days used by Iris are much longer than a year, so at least for the PRs Iris is much more relaxed 😉 But I am happy with the timings.
Do we really want to give everyone the permissions to open/close our PRs/issues? During the stale period, anyone can remove the stale label by commenting on it. Once an issue/PR is closed, people would need to ping us. I think if we clearly communicate this, this should be fine. |
Beta Was this translation helpful? Give feedback.
-
|
Not just anyone, but I do think people should be able to re-open issues/pull requests they opened themselves after they've been closed by the stale bot. |
Beta Was this translation helpful? Give feedback.
-
|
If that's possible somehow, I am happy to implement that. Would you know how to do that? A quick search didn't reveal anything (I haven't looked in detail, though). |
Beta Was this translation helpful? Give feedback.
-
|
Well they will get email alerts when the bot closed the issue/PR so they can just go reopen them - or am I missing sonething here? |
Beta Was this translation helpful? Give feedback.
-
|
Once an issue is closed, you need to have special permissions (I think at least the |
Beta Was this translation helpful? Give feedback.
-
Only repo or project admins have that privilege, Manu ie Core teams. And we should keep it that way for security purposes. I also believe that there is an option in the GH script Iris folks have, that warns an Issue/PR is stale, sometime before closing them, I think we should get that is ourselves. |
Beta Was this translation helpful? Give feedback.
Uh oh!
There was an error while loading. Please reload this page.
-
During our spring workshop, we discussed if stale issues and pull requests in our repositories should be closed automatically after a certain amount of time. The main reason for this is that we have a growing backlog of open issues/pull requests that will probably never be closed otherwise since nobody will work on those (currently ESMValTool: 292 open issues, 97 open PRs; ESMValCore: 257 open issues, 41 open PRs). It was generally agreed that this was a good idea.
A very simple way of implementing this is by the
staleaction. Here is an example workflow file from the Iris repo.I would propose the following basic settings (taken from the Iris repo; I think this is a good compromise):
stalelabelThere is a ton of further options available, e.g., if issues/pull requests with a milestones should not be marked as stale, but I think the basic settings should suffice for the beginning.
@ESMValGroup/esmvaltool-developmentteam How do people feel about this? Any specific preferences regarding the settings? Any other comments?
Beta Was this translation helpful? Give feedback.
All reactions