Remove the keep-open label

35 views
Skip to first unread message

Thomas Robitaille

unread,
Sep 11, 2026, 9:53:54 AM (10 days ago) Sep 11
to astropy-dev mailing list
Hi everyone,

As you likely know, we periodically search for PRs that have been inactive for a period of time (4 months I believe) and post a warning that they will be closed after 30 days (aka "stalebot"). The reason we do this is to prevent a build-up of stale (as in developing more and more conflicts over time) PRs which end up being unusable anyway. There are three ways to buy more time and reset the clock: rebasing the PR, adding a commit, or adding a keep-open label.

However, we are now in the situation where we have 33 pull requests that have the keep-open label, some of which are very stale, and this kind of negates the point of the stale bot in the first place. I am proposing that we get rid of this workaround to force PRs to be rebased or have a new commit. Rebasing can now easily be done via the GitHub UI, so there is less of an excuse to not do so.

Would anyone have any objections to removing the keep-open workaround? If we do this, existing PRs labelled keep-open will then have a grace period to be rebased or have a new commit before being closed.

Thanks!
Tom

Aldcroft, Tom

unread,
Sep 11, 2026, 10:37:55 AM (10 days ago) Sep 11
to astropy-dev
Good plan! 

Tom

--
You received this message because you are subscribed to the Google Groups "astropy-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to astropy-dev...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/astropy-dev/CAGMHX_2v0_3_k-DUA81TvxsGBdmkEbfUHKYgbQuH_bTBFDh2sw%40mail.gmail.com.

Thomas Robitaille

unread,
Sep 11, 2026, 10:49:06 AM (10 days ago) Sep 11
to astro...@googlegroups.com
I forgot to give a timeline - if anyone objects, please do so by the end of next week, so Friday 18th September.

Thanks!
Tom

Clément Robert

unread,
Sep 13, 2026, 4:05:39 AM (9 days ago) Sep 13
to astropy-dev
As I explained on slack, the stale bot isn't working for me at all, and I'm probably (one of) the biggest user(s) of the "keep open" label.
I think we shouldn't remove the label if we're going to keep the stale bot around (which looks like a broad consensus from where I'm standing).
I also think we ought to discuss of the problem these tools solve: the stale bot as it is used today doesn't solve any actual problem I understand. Yes, having a lot of PRs open is a bit unsettling but closing them automatically doesn't save maintainer time as much as it waste contributors', in my humble opinion.
It was brought up that 
> there has been a bunch of cases where it was unsolicited changes/cleanups/etc that never got a traction and review from the module maintainers

and there I want to ask: is there a consensus around the notion that "no response from a module maintainer" automatically means "no traction" ? I can think of many unrelated reasons for a maintainer not to respond promptly. If the reason a PR doesn't get engagement is that "we/I don't want this", I think it would be far better that someone said it explicitly and *then* close, so why isn't not more common ?

Clément 

Tom Aldcroft

unread,
Sep 15, 2026, 6:43:06 AM (6 days ago) Sep 15
to astro...@googlegroups.com
On Sun, Sep 13, 2026 at 4:05 AM Clément Robert <clement....@gmail.com> wrote:
As I explained on slack, the stale bot isn't working for me at all, and I'm probably (one of) the biggest user(s) of the "keep open" label.
I think we shouldn't remove the label if we're going to keep the stale bot around (which looks like a broad consensus from where I'm standing).
I also think we ought to discuss of the problem these tools solve: the stale bot as it is used today doesn't solve any actual problem I understand.

The stale bot does solve one real problem that the release maintainers often need to re-milestone all the stale PRs with every release. This takes time, perhaps even more if any time is spent looking through the conversation to see what's happening.
 
Yes, having a lot of PRs open is a bit unsettling but closing them automatically doesn't save maintainer time as much as it waste contributors', in my humble opinion.
It was brought up that 
> there has been a bunch of cases where it was unsolicited changes/cleanups/etc that never got a traction and review from the module maintainers

and there I want to ask: is there a consensus around the notion that "no response from a module maintainer" automatically means "no traction" ? I can think of many unrelated reasons for a maintainer not to respond promptly. If the reason a PR doesn't get engagement is that "we/I don't want this", I think it would be far better that someone said it explicitly and *then* close, so why isn't not more common ?

I agree this is a valid point. There are indeed PRs I see that don't align with my own priorities. I'm personally focused on bug fixes and substantive new features. So if a PR comes that doesn't match my priorities then it might not get that slice of time I have for astropy. I'm not saying this is a perfect situation, but it is reality. I am not going to close PRs like that outright because maybe another maintainer is interested and is happy to review. But after six months, these are unlikely to ever get merged. 

Likewise PRs that get some engagement initially but then stall for technical reasons are a problem. https://github.com/astropy/astropy/pull/17524 is a good example where something that seemed like a nice simple idea (support copy.replace() for Time) turned out to be actually tricky and it got stalled. This is where we ask how much effort ($) is it worth to implement this feature.

With this I'm still in favor of removing keep-open. A simple way to keep a PR open is just to rebase and re-request review. That demonstrates continued commitment to the PR but lets genuinely stale/orphaned PRs get off our radar.

- Tom
 

Marten van Kerkwijk

unread,
Sep 15, 2026, 8:51:05 AM (6 days ago) Sep 15
to astro...@googlegroups.com
Hi All,

To me, the stale bot is useful, in part because if I was involved in a
PR, it reminds me to have a last look.

For such a last look, I find it convenient that I can decide to do
nothing so that a PR gets auto-closed. In particular, not having to
explicitly state that I don't have time or do not think a PR is
interesting enough avoids spending time possibly having to argue about
it.

About "keep open", I think the label itself stops being useful if it
does not lead to action, which seems to be the present state, so I am OK
with removing it. It is good to minimize the work done for a release!

That said, if a maintainer like Clément thinks a PR is important, but
just lacks the time currently or that it needs more thought, it would be
good if there was a way that is simpler to keep the PR open than to have
to push to a contributor's branch (at least, that's all I can think of
to do to add a commit or rebase). Might it be possible to warn about
staleness but not auto-close if a PR has been assigned to someone? It
does seem logical that once a PR is assigned, it becomes that
maintainer's responsibility (this does assume we keep our habit of only
assigning PRs to ourselves). Maybe this would be combined with removing
the milestone.

All the best,

Marten




Aldcroft, Tom

unread,
Sep 15, 2026, 10:12:26 AM (6 days ago) Sep 15
to astro...@googlegroups.com
Does closing and re-opening reset the stale-bot clock? If so that seems like a very easy way to manually keep open a worthwhile PR.

- Tom

--
You received this message because you are subscribed to the Google Groups "astropy-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to astropy-dev...@googlegroups.com.

Julian Harbeck

unread,
Sep 16, 2026, 4:33:23 AM (6 days ago) Sep 16
to astropy-dev
Hi everyone,
just a comment from my side, in pandas we have the label "Mothballed" described as "Temporarily-closed PR the author plans to return to". While the PR is closed while having this label it serves as a pool of PRs that the respective author still plans to work on, just not right now. Maybe that would be a way to solve the issue raised by Clément?

Aldcroft, Tom

unread,
Sep 16, 2026, 6:08:59 AM (5 days ago) Sep 16
to astro...@googlegroups.com
On Wed, Sep 16, 2026 at 4:33 AM 'Julian Harbeck' via astropy-dev <astro...@googlegroups.com> wrote:
Hi everyone,
just a comment from my side, in pandas we have the label "Mothballed" described as "Temporarily-closed PR the author plans to return to". While the PR is closed while having this label it serves as a pool of PRs that the respective author still plans to work on, just not right now. Maybe that would be a way to solve the issue raised by Clément?

I like it!
 

Pey Lian Lim

unread,
Sep 16, 2026, 9:59:07 AM (5 days ago) Sep 16
to astropy-dev
I am not sure how valuable yet another new label is. The stale bot already adds a "closed-by-bot" label at closing time (you don't have to go home but you can't stay here). Therefore with a targeted search, you can probably find what you are looking for without a "mothballed" label. I don't want to put anyone on the spot but since Clément has concern, here is a specific example of a search listing his stale PRs closed by the bot:


On the search bar, you can type out the filters as such:

is:pr is:closed label:closed-by-bot author:neutrinoceros

Feel free to customize the search criteria as you see fit. Hope this helps.

Clément Robert

unread,
Sep 16, 2026, 1:01:53 PM (5 days ago) Sep 16
to astro...@googlegroups.com
Indeed search is a practical way to get at these PRs already, but then it begs the question: if we deem the search engine sufficient, why do we care about stale PRs staying open ?
From Marten's reply, I hear that the most important feature is really a side effect: reminding reviewers to get a look at a PR. Sounds to me like we could have a bot to do this that didn't also close PRs.

You received this message because you are subscribed to a topic in the Google Groups "astropy-dev" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/astropy-dev/zo_bZWG4Wzc/unsubscribe.
To unsubscribe from this group and all its topics, send an email to astropy-dev...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/astropy-dev/2649928c-89c1-4cf4-a243-f72ecb50917cn%40googlegroups.com.

Marten van Kerkwijk

unread,
Sep 16, 2026, 1:49:51 PM (5 days ago) Sep 16
to astro...@googlegroups.com
Hi Clément,

> Indeed search is a practical way to get at these PRs already, but then it begs the question: if we deem the search
> engine sufficient, why do we care about stale PRs staying open ?

Because mental load scales with number of open PRs. If it is small,
then it is easy to just set aside some time to try to reduce the number;
if it is big, it just seems hopeless (well, that's my feeling anyway). Also,
the release manager has to go over all of them to remilestone.

> From Marten's reply, I hear that the most important feature is really a side effect: reminding reviewers to get a look at
> a PR. Sounds to me like we could have a bot to do this that didn't also close PRs.

Note that I specifically mentioned how much I *like* that I can let the
bot close the issue without having any further interaction, i.e., I
don't have to explain why I feel something is best just closed.


More positively, what about my suggestion of not auto-closing PRs that
are assigned to someone?


All the best,

Marten

Clément Robert

unread,
Sep 16, 2026, 2:28:12 PM (5 days ago) Sep 16
to astro...@googlegroups.com, astro...@googlegroups.com
Assignments replacing the label as a way to guard against the bot seems like a great idea to me.

Clément

Pey Lian Lim

unread,
Sep 18, 2026, 9:34:57 AM (3 days ago) Sep 18
to astropy-dev
So... today is the day of decision. Looks like we have mainly an agreement to remove the label (which is the original question of this thread), but just a matter of what to do after removing it?

Aldcroft, Tom

unread,
Sep 18, 2026, 9:48:53 AM (3 days ago) Sep 18
to astro...@googlegroups.com
The problem with the not auto-closing PRs that are assigned is that the assigned label is then the new keep-open label. It allows PRs that haven't had any activity to just linger on and on, and we are back to exactly the same place. If a developer wants their PR to eventually be merged to astropy then they NEED to keep it active and champion that PR. If simply rebasing once each 6 months is too much then the PR is apparently not that valuable to the contributor.

- Tom

--
You received this message because you are subscribed to the Google Groups "astropy-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to astropy-dev...@googlegroups.com.

Aldcroft, Tom

unread,
Sep 18, 2026, 9:52:06 AM (3 days ago) Sep 18
to astro...@googlegroups.com
That strategy also violates "explicit is better than implicit" by introducing a new non-obvious and significant implication of assigning a PR. Nobody would guess that assigning => keep-open forever.

- Tom

Thomas Robitaille

unread,
Sep 18, 2026, 11:18:44 AM (3 days ago) Sep 18
to astro...@googlegroups.com
Today was the deadline for objections, clearly there are some objections so I suggest talking about it next week :)

Tom

--

Marten van Kerkwijk

unread,
Sep 18, 2026, 12:28:36 PM (3 days ago) Sep 18
to astro...@googlegroups.com
Hi Tom,

I can see your logic that if rebasing is too much work, it is not worth
keeping open, but I don't think that (self-)assigning is strange: it
just means someone has taken responsibility, so the bot doesn't have to.

Yet another possibility might be to auto-remove keep-open labels at the
moment of feature freeze of the relevant milestone.

Anyway, I fear we're spending much more time on this than is
necessary... I'm OK with just removing the label.

All the best,

Marten
Reply all
Reply to author
Forward
0 new messages