Adopt the Stale Issue and Pull-Request GitHub Action

[bjlittle]

Our Scitools/iris Issues are hovering around 300-ish open issues, and are only trending continually northwards ↗️ 😢

Although we've started the Peloton 🚴‍♂️🚴‍♀️ as a proactive initiative with the intent to get on top of all of our open pull-request/issues, which is totally fantastic, I honestly don't think this is enough to get over this hump... particularly regarding the volume of currently open issues and given our collective limited OSS resource availability.

We really do need a catalyst for change here. Otherwise, we're never honestly going to regain control of our open issues again, ever.

My suggestion is that we adopt a brute force approach and bootstrap a new beginning though the Close Stale Issues and PRs GitHub action.

It offers the level of control that we want for both PRs and issues, namely:

• adding a custom message to stale PRs and issues
• adding a custom message to PRs and issues that are closed
• tagging such PRs and issues with a GitHub label
• a growing fine grain level of control to exempt PRs and issues (also based on other metadata such as milestones etc)
• controlling the days-before a PR or Issue is marked as stale, or closed

To me this seems like an obvious step to take. I'm really attracted to an automated, controllable approach, particularly one that we can scale over time to slowly reel in the days before duration e.g., how lovely it would be to only have relevant, live, yet <90 day old issues to contend with 🍻

Let's discuss openly what you think to such a proposal. If you buy into it, then the only open question for me is,

"What is the initial days-before, as a ball-park value?"

I'll start the conversation with a suggestion of a duration of 2-3 years, and over time seriously commit to slowly reducing that duration as we all actively hustle to close and properly maintain our open issues backlog.

My working assumption here is that if an issue is closed automatically by the stale GitHub action then either:

• no one cares about that issue any more,
• the original author will be notified, still cares about it, and re-opens/keeps the issue alive,
• we naturally re-discover the closed issue, because it is an active issue that we or the community are still currently affected by or experiencing

What think ye @SciTools/iris-devs ? 🤔

[bjlittle]

If you want an example of this action "in action", so to speak, then take a peek at iris-esmf-regrid.

I activated this for this new repository as a means to avoid the ever deepening hole that we now find ourselves in with iris, see [here].(https://github.com/SciTools-incubator/iris-esmf-regrid/blob/main/.github/workflows/stale.yml)

I also added a badge to the iris-esmf-regrd README.md.

[rcomer]

I was thinking just this lunchtime that we should have an automatic closing action with some sort of "please re-open if still required" message.

One question that spring to mind: if the bot closes an issue can a non-member reopen it? I'm pretty sure that non-members can't re-open issues closed by members.

[bouweandela]

the email the author get's may trigger them to engage again.

My point is that it engaging again should be a welcoming experience. If you're not allowed to re-open an issue (or even worse, not even allowed to comment as in some repositories), that is not welcoming and people are unlikely to engage again. Especially if their issue didn't get fixed in all those years after reporting it..

[rcomer]

If I have understood, there can be two steps to the process, each with a comment:

1. Mark the issue as "stale"
2. Close the issue

So we could have an invitation to re-engage when the issue becomes "stale", and only close it if a further n days have passed without updates.

[bjlittle]

@bouweandela I completely understand your point of view.

I'm certainly not aiming to offend collaborators or users by closing their issues (or worse PRs) but at the same time we really do need to be pragmatic... certainly initially, in order to get back control of our runaway issues in the backlog - then we just need to commit to staying on top of things and be better maintainers of iris (indeed see Welcome Peloton Riders, which attempts take a step in that direction)

That said, let's not speculate here.

Instead, I'm going to spin up a separate dummy repo, owned by me, and invite people to add dummy issues and dummy PRs. Then I'll enable the stale GH action, so that we can all get a better understanding of what exactly happens and what the experience is like for the spectrum of use cases here e.g., those with read, triage, write, maintain, and admin access rights on the repo.

Does that sound like a reasonable plan? And if so, who wants to take part? I need people who are not me to create issues and PRs, and I can give them different access rights to the dummy repo.

This might help give us what we need to make an informed decision here.

[trexfeathers]

who wants to take part?

✋

[bjlittle]

@SciTools/developers I've created the test repository https://github.com/bjlittle/stale

Please create some dummy issues and pull-requests on it so that we can test the behaviour of the GH stale action.

I'll give a couple of you contributor rights on the repo so that you can close issues and merge pull-requests el al, and other not - this should cover the SciTools/iris use case.

Then I'll enable the GH stale action on the repo week beginning Monday 14th June (or there about) and we can all see the actual behaviour and user/dev experience.

After that, make an informed decision.

Go for it 👍

[rcomer]

Could be worse though. matplotlib has ~1400 open issues!

[bjlittle]

This is a general OSS problem for popular Python packages in the scientific ecosystem. In terms of open issues, a possible future that's welcoming us with open arms is highlighted by,

• dask 657 open issues (wowzers!)
• scipy >1.3k open issues
• scikit-learn >1.6k open issues
• conda >1.9k open issues
• numpy >2k open issues

[tkknight]

Completely in favour of this. Suggest we start at 3 years, then monitor it and then aim to reduce it over time, perhaps to 2y or even 18 months.

[rcomer]

3 years would currently give us 225 issues. Probably more than there ought to be because someone has been going through sticking labels on old issues....

[bjlittle]

$ gh issue list --search "updated:>2020"
Showing 30 of 58 issues in SciTools/iris that match your search
<snip>

$ gh issue list --search "updated:>2019"
Showing 30 of 165 issues in SciTools/iris that match your search
<snip>

$ gh issue list --search "updated:>2018"
Showing 30 of 214 issues in SciTools/iris that match your search
<snip>

[bjlittle]

Okay, so I'm going to wait a couple of days to give others in the community the opportunity to contribute to this conversation.

Otherwise, I'll assume there is a quorum of agreement here, and I'll push a follow-on PR to enable this GitHub action 👍

[bjlittle]

See #4268 for the introduction of the stale GHA