For the past few years, the number of issues and PRs across all my GitHub repositories has gone from a steady stream to an ongoing deluge. There are currently over 1,500 open issues across my 194 GitHub repositories, and there's no way I can keep up with all of them.
Initially, I went through each issue in each project's issue queue on a monthly basis (mind you, this was—and is still—done on nights and weekends in my spare time). That slipped to a quarterly task... and has now slipped to only happening for higher-profile projects once or twice a year.
To keep up with the constant barrage of new issues and PRs, many open source projects have employed a 'stale issue' bot (Probot: stale), which marks issues/PRs with no activity stale, then later closes them. Many issues are opened and never get a follow-up visit from the original author (even if I spend a half hour providing a thorough response). Often this person found a solution elsewhere and never thought to follow-up, or they don't have notifications enabled so they never even know someone responded.
Instead of letting these zombie issues clutter up the issue queue, the stale bot helps prune them.
You may have been directed to this issue from one of the issue closure notices.
Know that I don't close issues out of spite, or anger, or because I think the bug report, feature request, or other contribution has no value. Rather, unless something is breaking stability (e.g. a project I maintain won't install anymore, or breaks completely and CI blows up), or there's a major feature or missing component that I agree would be a no-brainer to have incorporated, I simply lack the bandwidth to be able to review the issue or PR.
One way you can help me get more bandwidth is to sponsor me on GitHub or Patreon.
I can't promise sponsorship will lead me to reviewing your issue or PR more quickly, but one major problem with today's open source development model is the income generated from the tireless effort of open source maintenance is a pittance, and until that changes, I don't have the ability to devote more time to code review and responding to the deluge of open issues.
Also, note that for my Ansible open source projects, the current maintenance status is indicated on this site: Jeff Geerling's Ansible Content.
Aside: People have often mentioned I should cede control of my projects to others if the maintenance burden is to high, but they don't realize that:
- That would mean I don't have control over projects I built for myself and use in projects that contribute to my own income, and
- Giving control over a project in my namespace is something I don't take lightly at all, because I entrust all the project's users to the new maintainer.
I don't take the responsibility of maintainership lightly, as trust is a valuable asset and is easy to lose.
Comments
You're right, it's the only solution. Oh and not only do you have hundreds of repos, but also a lot of them target different Linux distributions, different engines (PHP vs PHP-FPM), ... Anyways thanks again for all the work, if only you could benefit more from it!
Counterpoint: seeing a project has mountains of unaddressed issues is often a great way of telling that a project is, like yours, in maintenance mode or even unmaintained. That then informs decisions about whether to use it or not. Bots make it look like a project is active. They also *don't give up*, unlike your users. Only the most dedicated and frustrated user will keep poking an issue monthly forever, just so other people can know there are bugs in the software.
The bot has different ways of allowing issues to be marked as 'evergreen' (e.g. don't mark it stale, ever), and for certain issues, I use that. Bots may make a project look more active than it is, but using an open issue count as criteria for whether a project is maintained seems like it would not be a great idea—rather, are there CI tests, are they run regularly (weekly or monthly), are there commits and merged PRs recently?
Most projects I maintain, use, or contribute to (including many of the most popular open source projects) have thousands of open issues, many very old, but that doesn't mean the project is not worthy of use.
while cleaning up the Git issues seems to be a good idea I have noticed multiple high-profile projects closing open issues as "stale"... the original user who reported it would have found a workaround but not had time to report back... with open source the financial or technical motivation does not seem to drive any project.
well people can just simply fork it and fix it by themselves, no big deal, thank you for all your contributions so far.
You're welcome! And yes, all of my projects are licensed with the most liberal of all open source licenses (IMO), the MIT license... so feel free to fork and do whatever you need to the code!
There are other ways to get more bandwidth.
In the cloudalchemy project, we've automated a bunch of the routine boilerplate update work.
Another way is to onboard additional maintainers for projects. If there are more reviewers, more work can get done.
Hello Jeff,
first of all. Thank you for your amazing work in open source. For the high quality playbooks and good documentation.
I understand why you put measures in place to fight burnout. It is your personal right to do with your projects how ever you please.
The big concern I've seen in the past with this is not being able to contribute to the projects used. Coming from Drupal community myself it has always been seen as best practice to fix stuff yourself, than to rely on any maintainer to fix your issues. Following this approach I tried to contribute to multiple ansible roles of yours. To either fix issues, or extend a tiny bit of configuration not being covered at the moment. I created PRs for them. I catered the issue queue and linked matching issues to the created PR.
None of these PRs have been commented on, reviewed, or merged in the past. I was ok with this - it's your choice. I could still always pull in the patch, patch the module, roll the patch in case your role made breaking changes. With your stalebot now coming in and closing these issues I feel like these will be send into a void. It's a straight punch in the face for anyone in open source trying to contribute to your work.
Have a look at this playbook: ansible-role-memcached https://github.com/geerlingguy/ansible-role-memcached/pulls?q=is%3Aopen…
8 open PRs all marked stale. I do not think that any of the contributors moved on or left the issue, found a different solution or the problem fixed itself over time which would allow automatically marking them as stale and close them.
If it would help to pay for the time you have to invest to cater for merging PRs please make that an option. But a general please "sponsor me" button and I might feel like merging is not working for me. Usual trade goes money in exchange for goods or service. Charity buttons like that are tough to place in the books for a company and even tougher to argument for in a budget review. If you do not want anyone else to contribute please have the courage to say so, please mark abandoned projects as abandoned and do not hide existing issues by closing them. Abandoning / marking as minimally maintainted / unmaintained a project will make other's fork your work and further work happens some place else, taking things of your plate and ultimatively help you fight being overburdened.
I really appreciate your work and would hate to treat your projects as to be untrusted and unmaintained as a general rule.
Andre Baumeier
Thanks for the comment, and the detailed thoughts! One particular point of interest:
This is the million (billion?) dollar problem in open source. I am currently working freelance, and am always open to someone reimbursing me for the time it takes to do project xyz (especially if it's something I know and use, like most of my roles). However, not once in my life has someone offered a payment that's nearly enough to cover the time I would spend on the task (versus doing any work for any other entity).
And it's not just about the money—when I consider a new feature or expansion of existing features on a role, I have to weigh the entire future maintenance lifecycle for that new feature/task. This is why I'm pretty strict on the 80/20 rule. For my GitLab role, there are thousands of individual settings I could expose as variables. But instead of doing that, I expose the 20-30 that are most used, and offer people the ability to swap out their own settings file so they can tweak the ones they need that aren't covered through the role directly.
However, that doesn't stop people from opening PR after PR asking for more esoteric options to be exposed. I used to try to respond to every one of those PRs, and left many open... but that (IMO) is worse than marking it stale and closing it, because that leads people to believe that someday it might be merged, when in reality, it won't be.
While it might be appropriate to mark open and unresolved issues as stale, why is this also applied to Pull Request? Especially PRs which are "green", that is pass all tests, and can be merged?
I understand that you work on many projects in parallel, but marking contributions as "stale" is not the proper way to encourage anyone to further contribute.
Unfortunately, with the hundreds of open PRs, it is difficult to go back to old PRs (some of which are many months or even years old) and review them, work through the process of readying them for merge (if they meet criteria for being something I'd merge), and finally merge them.
It's a little hard to put it, but even if a PR is green, and in some cases even if it makes sense as a useful improvement, if it makes maintainability of the project harder (some more complex features do this), or if it's something that I don't believe would benefit 80% of more of the project's users (especially if it's something I don't need in my own use, since my projects are developed mainly for my own use in projects I help maintain), then I would not like to merge it. It's often difficult as a maintainer who tries to be kind/encouraging to say 'no', so maybe this stale bot is kind of a way for me to force out a 'no' that I can't put into a comment on my own?
In any case, issues and PRs that are persistent and have 'champions' who will keep pushing them will not succumb to closure by the stale bot. All it takes is one comment on the issue, or me throwing a 'planned' label on it, and the stale bot stays away. Some issues/PRs get enough attention that I go ahead and dive in further to either get it all the way done or give up on it and officially close it out with a 'won't fix' comment.
You have a lot on your plate. But encouraging people to push comments on PRs all the time just to keep them open is not the way to gather contributions. Maybe reduce the 30 days to just a couple minutes, and exclude the champions. The end result might be the same.
Note that I have usually at least glanced at all issues/PRs, and for the most part, if I plan on adding it at some point, I will put a
plannedlabel on it, and that prevents the bot from looking at the issue/PR.In the end, my main point is: if it's something that makes someone less likely to adopt one of my roles or projects, please fork it and make it do what you want—the license (MIT/Expat) is intentionally extremely liberal, so that you should never feel encumbered by that decision.
Have you considered adding maintainers to your repository that help you review changes to make it easier on you?
I personally don't mind forking your repos and making changes for fixes, but other people are not going to see my repo over yours and might not get the fixes.
Yes; please see the final part in my post above—it's a decision that I do not make lightly. There are a few repositories where I've added a very long-term and trusted contributor as a co-maintainer, but that is something that requires a lot of consideration on my part. It's similar in many ways to giving someone else a key to your front door.
I would be interested in helping with the review work of pr's on some of your repo's that I also use myself in my projects. You don't need to give me merge or push access, just access to put labels on pr's, that might lower the burden later on, perhaps find 2-3 completely unrelated individuals per repo that could help review and give 3 approvals etc, so you can merge some little tweaks with a lot more confidence.
I very much appreciate your work and how it helps me in my own projects, that's why I want to contribute back to your projects.
But I totally understand your 'then just fork it' stance.
The issue is then there is no longer a 'central' place for all these intertwining ansible roles.
Perhaps we (me and other people creating pr's for your projects) should create a 'geerlinguyforks' organisation where more people can review and merge pr's.
If you don't mind this, I might go ahead with that (perhaps a slightly different name? So we don't completely put your name on the forked projects?)
Sounds like a reasonable and useful feature to me. If people don't follow up it means that problem was solved or became much less important.
If you cannot keep up with issues just make your repos private or archived. Save some time for other people. This bots marks troublesome issues as stale and closes them, and I believe this is very convenient way to ignore them.
I've spend quite a lot of time to make your playbooks work on very basic setups, and my solution was just to get rid of them and do everything myself.
My favorite is "The requested handler 'restart webserver' was not found in either the main handlers list nor in the listening handlers list". Guess what? Your handler was named "Restart webserver", not "restart webserver". How is these ansible roles even show on google?
If doing it yourself saves you time and effort, do that. If any of my roles save you time and effort, use them. Not a problem for me either way :)