Demoralising auto-closing of PRs - should be a quick admin variable change

[toni-sharpe]

Description

In this repo PRs go stale and get closed very fast. Once closed, even rebase, force-push doesn't open them. 14+3, when the default is 60. "stale" (their default) suggests mold, food a risk to eat. "Quiet" or "Needs attention"? And not grey?

Less relevant details

Seems fairly well agreed this isn't the best

First hand view

I tried with #3817 hours and all I got was more words. (I'm trying again now as #2714 seems the same, and I'll publish the details, folded away first). This is cool, the code-base is hard.

But I thought, a couple of simple things, quick, knock the list down, be nice for morale. So I did that.

Then I tried for hours and failed with #3516 and #3819 on two occasions. While I was failing I was thinking at least those other PRs will merge but instead the notification was just that they hadn't been noticed.

That's hard. Trying to understand how a large, complicated system works, failing to deliver anything of any use; doing it 100% solo pretty much, if it breaks then I have to fix it; then every day or two seeing a notification that something you worked on, related to a raised issue, has been closed, unused, with any evidence of being reviewed.

Others

It's in the repo it comes from - it's even blogged about. Not keen. STOP in fact.

My PRs

Should still go, they're done.

/pull/3716 - an issue I raised that Dany said wasn't bothering the team but I could fix if I wanted
/pull/3788 - gardens away some word press stuff, and I raised a possible error
/pull/3789 - fixes a "min-height" that was forcing scroll

Two more will head that way soon: #3792 #3798.

Expected behaviour

There's a lot of configurables.

• IMO: on for employed people; off for open source contributors.
• If on for OS too, then set at six months or something.
• Bright label.
• Every dev do one per wind-down.
• Replace "stale".
• Applies to issues and PRs - they probably need different processes

==================================================================

Frequency

not needed to discuss/fix stale settings

It was explained I moved too fast to start which I've taken onboard, so I have limited the amount I do. One a week if that, and when I do comment, I'll try to save only the really useful ones (where I might be a bit more liberal in a team) and wrap them up, they should usually diagnose something new. And the size, I knew that already, but as well I am making effort there. If it's big with example pics because it needs to be, I'll wrap it up.

I do fully appreciate it's few people, ten years old (legacy fun-times), probably started by clever academic folk but not pro. software engineers with tech. team XP, etc, then just sent through the roof because for some reason this mass-death was far more newsworthy. Even my PR comments, which I removed when asked not to comment on PRs, focused on maintainability for the core team, speaking to the casual contributor (not code questions, nitpicks and so on).

I still might write a lot, but I'm going to organise it ....

Visible and Matters.

Or is hidden And Matters

like a sequence of annotated screen-shots

Or just hidden

and is not needed to complete the task
I'll try not to do this, it'll still be relevant, alternate ideas, etc.

[danyx23]

Thanks for bringing it up @toni-sharpe. We'll chat about it in our next dev team meeting.

[toni-sharpe]

Edited to focus more on exact problem and fixing it (hid the various complaints, essentially)

[ikesau]

We've added a new label "external-contributor" which will be exempted from stalebot and require proactive handling.

[toni-sharpe]

Thanks for this, I think it will valuable for folks coming down the line and for opening the project up Open Source wise