Cleaning the Github Gladys repository 🧹

Development
1

Hello everyone @contributors!

I took some time to close quite a few PRs on the Gladys GitHub repo :slight_smile:

A large part of these PRs had been completely inactive for more than 6 months, with « WIP Â» in the title, and most of the time the tests were broken.

On my side, it was becoming more and more complicated to find my way around on GitHub, I never find the PRs where I am mentioned, and it wastes a lot of time for everyone.

In addition to that, I think it must discourage new developers who come to the project and see that there are a hundred unmerged PRs, most of which are completely broken, it gives the impression that the project is abandoned, which is not at all the case :slight_smile:

If by mistake, I closed a PR that should not have been closed, do not hesitate to reopen it!

2

For information, on my side, the old PRs on which I haven’t finished working, I simply recreated them on my personal fork to avoid losing them.

3

It works! Indeed, it’s probably easier to keep them out of the main repository as long as they are no longer in active development.

4

Can we set up a bot to close PRs that haven’t moved in 30/60 days?

5

If we can do it in 2 moves.
After 30 days, 1st message « warning we will close it automatically Â»
After 60 days, closure

?

6

Yes we can with the stale-bot

7

@VonOx Yes I agree, I will look into it!

8

Sure, here is the translation:

Well, I added the stale-bot with the following configuration:

Screenshot 2021-10-18 at 12.19.51
Screenshot 2021-10-18 at 12.19.511346Ă—854 92.6 KB

I added the bot to the two repos: Gladys and v4-website :slight_smile:

We’ll see how it goes, we can modify the configuration if it seems too aggressive/not aggressive enough.

In any case, this will greatly help us close inactive issues/PRs that:

  • Give the impression to a potential contributor that the project is abandoned, which is not the case (most PRs are just unanswered/outdated…)
  • Allow maintainers to better identify really active PRs, and thus not get lost in an infinite list of PRs/issues as it is currently.

However, we don’t want to:

  • Lose bug fixes that we couldn’t fix in 2 months (2 months is very short to fix an issue, and in any case personally I rarely have time to tackle an issue in 2 months unless it’s critical/a very small dev that can be squeezed in as a priority).
  • Lose pushed developments that were just on standby.

Don’t hesitate if it closes important PRs/Issues to give me feedback, the configuration can be modified if needed.

9

The thing is you have to ignore the issues, I tried this action

https://github.com/VonOx/gladys-ci/blob/master/.github/workflows/close-stale-pr.yml

I didn’t put a filter on the labels but it gives an idea

10

I don’t agree, why would you want to ignore the issues? We have the same pollution problem with the issues, if not more.

11

I agree with @VonOx on this. If a new issue is created and no one responds, it will be closed. As a result, we will never address the problem.

12

Exactly, if there are no more responses for 2 months, it makes sense to me to be alerted by the bot « pay attention it might be closed Â» (which notifies the concerned people):

  • If it should not be closed, we can either respond, or even use a specific tag to specify that the bug is still present and that we will address it.
  • If it should be closed, we do nothing and the bot will close the issue

In any case, the goal here is not to lose bug reports (we clearly want to avoid that), it’s to have a little reminder from the bot to say « hey guys, 2 months and no one has responded here, is this still relevant? Â»

Because clearly there are quite a few zombie issues in the project, and I think we lack some automatic cleaning hygiene :slight_smile:

13

The first wave of bot messages has gone through!

Screenshot 2021-10-18 at 15.32.14
Screenshot 2021-10-18 at 15.32.141920Ă—1435 151 KB

Due to GitHub’s rate limiting, it only responds to 30 issues per pass at most, so it will go through the entire repo in a few passes.

I will check each issue for this first round to verify that there were no errors :slight_smile:

14

My Gmail account is on :fire: :sweat_smile:

15

That’s really great, stale-bot, I agree 100% with everything you come up with.

I handle each notification one by one, and either:

  • It’s something that should be on the forum, so I create the post on the forum and close the GitHub issue
  • It’s old, so I close it
  • It wasn’t me who created the issue, in which case the participant has 7 days to respond.

In any case, it gets things moving and it’s positive.

16

lol it’s violent!
github notifications spam + emails
but it seems to be paying off already.