Why did not they make their stance clear? Make it clear you’re not accepting contributions.
Why should they? They’re just sharing their work.
Basic etiquette.
I think, with time, people will start to recognize that stale-botting is just putting a robotic coat of paint on the same boorish disrespect for others that is on full display in places like Twitter/X and YouTube comments.
If you don’t want to follow the implicit norms of the greater community, state so up-front. You don’t need to write a fancy legal document… just have the backbone and common decency to tell people what to expect of you, rather than ghosting them.
All of the perspectives raised carry an undercurrent of “I’m so special that I don’t have to engage in common decency”. Heck, now that I think about it, I think part of the reason stale-botting irks me so much is that, on some level, it feels like the decision to use a stale bot is passive-aggressive behaviour.
I dunno, I believe users who treat open source projects like they’re a product they’re paying money for, and who demand to be treated as paying customers, are the ones who are boorish and disrespectful.
Which is exactly the passive aggressive behavior the thread starter is referring to. I would say if you don’t have the mental energy, maybe let the issues sit open until you do.
Why is it passive aggressive? They have have a project, they are happy to let others use it, but they aren’t (yet) expecting to follow everyone else’s needs. Let them deal with their project how they wish, without having to apologize to everyone for everything in advance.
Because human communication has norms. If I spit in your face. It doesn’t matter if I think it’s not a grave insult. What matters is what the cultural norms we exist in consider it to be.
Yes, that’s my point exactly. Why did the commenter above think that this behavior is passive-aggressive? Because I don’t, and they apparently do.
So yes, human communication has norms, but as far as I know, one of them is “my house, my rules”. Why should users expect that some project runs issues just the way they, the users like it? Why can’t they just abide by the rules of the house? The maintainers could very well be passive-aggressive, but maybe they’re not, maybe they just don’t have a lot of time or interest in chasing bugs.
That’s what I’m referring to - we cannot assume someone has a certain state of mind (passive aggression) based only on the fact that they employ a stalebot. We would need other source of data. Stalebot is most certainly a norm that some projects use - but not all - so why can we say it’s wrong to have them?
Yes, that’s my point exactly. Why did the commenter above think that this behavior is passive-aggressive? Because I don’t, and they apparently do.
I’m the person who said it originally and I said it feels like passive-aggressive behaviour and that’s why it bothers me so much.
So yes, human communication has norms, but as far as I know, one of them is “my house, my rules”. Why should users expect that some project runs issues just the way they, the users like it? Why can’t they just abide by the rules of the house? The maintainers could very well be passive-aggressive, but maybe they’re not, maybe they just don’t have a lot of time or interest in chasing bugs.
Because you’re publishing your project into a public space with defined expectations. Psychologically, it’s closer to renting a space in a shopping mall than a private home, and people are upset at “how rude the staff are to window-shoppers”.
If you don’t want people wandering into your rented commercial space with expectations of your behaviour, then post proper signage. Just because the “mall” has effectively no size limits and offers space for free doesn’t change that.
Again, this is very situation-specific. I personally had had office space rented, when I was freelancing a lot. It was a small space next to a cafe. I didn’t mind people smoking on the caffee’s terrace, but I did mind if they did on mine. (I really didn’t. But it works for the example).
Now, I can expect that people will come in my commercial space because it’s next to that cafe. And I can also expect that some of them will be smoking a cigarette. Which is also fine. But despite all that, if I ask them to put the cigarette out, or if I stale-bot their stale issue, I don’t think I’m aggressive. I just think I have my rules, and in my (rented, commecial-space) back yard, I should not have to feel pressured to explain the reasoning behind those rules.
Once more: the bottom line is that the passive-agressive feeling is very personalized. I may really like some behavior where you might not, and we’ll feel different kinds of pressure when witnessing said behavior. That’s why I think that the passive-agressive comment can’t really stand as it is overly generic.
The comment about it feeling passive-aggressive was secondary anyway. The primary point was that it was an active violation of the etiquette of the public space they set up shop in.
The funny thing about my mall example is that you’re responding to draft #2, where I now think draft #1 addressed your point better. Originally, I couched it in terms of setting up a library in a mall unit and then sending out a “shush bot” to patrol the segment of hallway in front of it rather than setting up proper sound insulation.
It’d just make people want to kick the bot and resent its owner.
Yeah, the passive-agressive stuff is not really relevant. I still disagree your point though. Why is my issue tracker, for my project, public space? Why do passers-by get to dictate my rules?
I don’t think we’ll agree on this. You seem to think that issues should not be automatically cleaned up by stale-bots. I disagree - not in that that I think that they should be automatically cleaned up, but in that that the choice is on maintainers and maintainers alone, not on the users of the project.
Do you mind if I ask a question or two to try to get a sense of your position on that before we part ways?
I’d like to get a sense for what you believe is reasonable to allow the project maintainers to decide. For example, I doubt you’d argue that GitHub should be prohibited from kicking users off their platform for gross abuses (eg. using a bug tracker to coordinate treasonous or genocidal activities), so there has to be a line you draw and the question is where you draw it.
(eg. Which side of the line is it on for you if maintainers choose to set a “norm” where they verbally abuse people who report bugs?)
Oh, but those two aren’t exactly the same, deciding whether to use a stale bot vs. being abusive, it’s pretty much different things we’re talking about.
To be upfront, I believe it’s absolutely reasonable for the platforms to deal with abuse. I also think it should be required, but it’s hard to set the limits of “what is enough”. But that topic is moderation, we’re talking stalebots here.
If you’re asking me if I would use a stale-bot, probably yes. I frequently have some inner-source or closed source projects, so it’s a bit different, but I would still use a stale-bot if I didn’t have someone who’s already triaging the backlog. That is not applicable here, though, since I don’t think I ever had a project with 300 open issues. Or if I did, they would be neatly “organized” into epics and stories and stuff, and out of my “current sprint” or whatever, and I would actually be paid and reserve the time to triage them.
For open source, I probably would like some automatiuon if I didn’t have the manpower.
Do you think, what’s my position in general? After a small consideration, I believe on most of these things I am quite liberal.
Each person gets to decide for themselves, as long as they don’t impinge on other people’s freedoms or break public rules. It may be sucky, and we have to work on that, but as long as it’s “allowed” by the general rules, we can’t and should not force anyone to do anything a particular way.
But even more, I don’t like “having a position” at all, mostly. I like having observations on how things work. You know how it is in software: for most questions, an experienced developer will answer majority of questions with “it depends”.
It is very often a question of a trade-off, not of “should we or should we not”.
In this case (stalebot), I think it is absolutely okay for maintainers to decide to use a stale bot. 100% their choice. Even if it was something that is as widely used as linux kernel - they are the maintainers, and they have to maintain the thing, so they get to pick what they want to do about stale issues.
People picking stalebots are probably not doing so much triage. I’m thinking e.g. Angular, where I frequently found open issues on my topic that are untouched for a long time. Sucks, I have no clue what’s with the issue, why is it still open, is it being worked on or what. (To be honest, I haven’t visited Angular GitHub repo in a while now).
People leaving open tickets probably do a bit more triage, but the already mentioned Angular example shows it’s not always the case.
As an end user in such a project, I am stuck either way. Either the issue is stale-closed, or it’s open but untouched, and I have no clue what to expect. Well, with a stale-closed issue I can probably expect nothing, with the open-but-untouched issue, I probably have nothing to look forward to as well, but there’s some false hope that it may be tackled sometime.
So, for me as a user it is usually irrelevant about what the maintainers decided.
Is it okay for Microsoft/GitHub to say, “no stalebots allowed”? Absolutely. Their company, their rules. We do have a choice (and I mostly do choose to go elsewhere). So now if maintainers want a stale bot, they have to go to GitLab or something.
Again, all perfectly within the bounds.
I don’t think my thoughts on any of that matter, though, they are just observations. Again, this is more a trade-off, then a final position - what is more valuable to me, at this time, vs. maintainer, vs Microsoft.
I don’t know if I answered your somewhat-open-ended question well enough, feel free to ask more.
I think you answered it fairly well and I’m not opposed to stale bots in general. In fact, I think it’s probably a good idea to have bots that tag things as “stale” for easier filtering for or against. It’s just the closing of issues that is the problem.
Likewise, I’m much less opposed to stale-botting with closure if the maintainers post clear notice so people know what they’re getting into before they invest their time, but I’ve said that before, so let’s not start that up again.
A house is a poor framing for open source…it lacks the collaborative element.
Or… maybe it’s apt after all, but only if we think of it like a community barn-raising. You need a barn, so all your neighbors help you raise it. In turn, you’re expected to help them out when their time comes.
And if one of your neighbors barn gets struck by lightning and burns down, you’d have to be a terrible person not to offer to let them store some of their stuff in your barn until a new one is built.
No, I didn’t mean for the house to be the analogy, I meant, it’s their project, not a community project.
I get that a random third-party can get interested and involved and challenge the rules, but it’s still those project’s rules.
Look at the extremes. If someone came, and raised a pull-request on your latest zig hobby project that rewrites everything in Rust, or PHP, or whatever else, you would probably reject it. You made the technology choice for your own reasons. Perhaps to learn zig, perhaps for the fancy comptime. Rejecting that PR is pretty straight-forward, right? They can offer reasons (“it’s better”, “it’s faster”, “it’s slower” or similar). They can open a discussion. But with or without the discussion or reasons, if you simply reject the pull request with just a note “We decided to do this in Zig”, it would not be a problem, right? It was your technological choice.
I see it the same with the stale-bot choice. It was your project-management methodology choice. You could accept discussions, or be willing to change your potentially-inefficient project management ways, but if you don’t it’s your choice, since it is your project.
I know the two decisions are not in the same area (tech choice vs project management methodology choice). But those are the chosen ones for that particular project anyway.
That is what I meant by “my house, my rules”.
Does my reasoning make sense to you? I mean, I get that you still may not agree, but can you at least accept my point of view on why we shouldn’t expect people to stop using stale-bots, even if it’s inferior?
I understand your framing, yes. I just don’t think it’s correct to ignore the community aspects. And a PR about rewriting in another language is a bit of a straw-man; it’s an exaggerated hypothetical scenario that isn’t the real problem that arises.
Consider it from the perspective of copyright instead. My contributions to another project are under my copyright. It’s standard now to force contributors to assign their legal rights away (via CLAs), but the copyright still remains mine. Without CLAs, every project would be forced to treat their contributors as full participants. CLAs distort that.
Regardless, a contribution of code and assignation of legal rights is a gift, and warrants social consideration, if not legal consideration. It can be mostly, but not solely, your project.
Yes, I’m aware that that was an extreme example, I wrote so. I’m just saying that it’s very clear that there is some boundary where it is okay for me to have my rules for my project, and regardless of the quality, size, value of your contribution, I do not have to accept that contribution. Now, if we can agree to that - that some things are under my control, I just think that most people will have different opinions on what things are mine alone.
I think it’s acceptable for maintainers to decide on the stale-bot rule. I may think that in some cases it’s wrong, in some others it’s the correct way, but in no case do I think that I have any say in their decision. I may provide input, or express my wishes or preferences. I may try to persuade them, or pay them or whatever, to take that decision one or another way.
But whatever they decide, I don’t think it should be considered rude, anti-social, not-in-spirit-of-open-source or any of the things this entire comment section is mentioning - it’s just a simple project management decision, in my eyes, and it is theirs to make.
Taking the time to write up and submit a good bug report (potentially including investigation of relevant code, surrounding behaviours etc) is not treating a project the same as a product you’re paying money for. Having such bug reports closed by a bot is pretty annoying. I don’t want to waste my time submitting bug reports if the maintainers aren’t interested in actually fixing bugs, but this has happened on any number of ocassions (not always with stale bots involved, sometimes the bug just sits in the bugtracker forever) with various projects.
Sure, there are lousy users with excessive expectations and demands as well. That doesn’t justify ignoring quality bug reports. If you don’t want bug reports, don’t have a public bug tracker, or at least make it clear exactly what kind of bug reports you do and don’t want and what sort of expectations the submitter should have. As a maintainer you don’t have the right to waste people’s time either.
Let’s say that in this situation, the project doesn’t use a stale bot, but everything else remains the same. Your finely crafted high-quality issue goes unacknowledged and un-actioned indefinitely. The end result is the same: you feel rejected and disrespected.
Not using a stale bot is not going to make a maintainer action your issue faster.
Ah, but having a huge list of unanswered issues is a red flag! You would not contribute time and effort to such a project. And that’s true. So what you need to do now, before submitting an issue, is to check the list of Closed issues, and eyeball if they’re closed by a stale bot or not. This is a tiny bit of extra work but less than submitting a good bug report and then nothing happening.
No, if my bug goes perpetually un-answered, I assume many things (maybe the developer is overworked. Maybe, like me, they have ADHD. etc.) but I don’t feel actively rejected and disrespected.
If they use a stale-bot, it feels actively user-hostile. It says “this person doesn’t even have the decency to leave my report to languish”.
This is pushing the responsibility on to the wrong person. It’s easy enough not to think to check through issues to see if they’re being dealt with appropriately; especially so if there’s a detailed issue template (for example) that makes it look the project takes bug reports seriously and there are no obvious “website is only held together with sticky-tape” signs that hint a project isn’t really maintained. I don’t think to check for auto-closed bugs before opening a bug report (but thanks for the suggestion, it’s something I might try to do in future); the tendency for projects - even large, supposedly maintained projects - to simply ignore bug reports (or auto-close them) isn’t something I expected until bad experience taught me otherwise, with however much time wasted in the meantime.
The result: I tend to put less effort into bug reports now, if there’s any indication at all that there might not be any interest from maintainers. If the maintainer responds at all, I’m always happy to do more legwork, but speaking as a maintainer myself, this still isn’t optimal.
On the other hand it’s trivial for a maintainer to simply shut the issue tracker down, make it private, or at least stick a note in the issue template (or even the project README) that the issue tracker is for maintainer use only (or whatever), without risk of wasting anyone’s time at all and without generally bringing down the open-source experience. I would do this; I’m not asking anyone to do anything I wouldn’t do myself, and I think it’s a better outcome than either abandoning the issue tracker or auto-closing bugs in it. But if it has to be one of those, at least just abandoning the tracker makes the state of the project clear.
It’s later addressed in the post. Sure it’s “basic etiquette” once you know it. But you may not even be aware of it. The use of stale bots is not necessarily evil. These are just some unspoken rules we’ve come to agree on. And I think maintainers should be educated rather than shat on here.
Also lol @ the flags on this post. I searched for it before and didn’t see it already posted. And I have no idea how “no stalebots” could be on-topic but “yes stalebots” off-topic…
Users can flag stories and comments when there’s a serious problem that needs moderator attention; two flags are needed to add the story or comment to the moderation queue. Users must reach 50 karma to flag. To guide usage and head off distracting meta conversations (“Why was this flagged!?”, etc), flagging requires selecting from a preset list of reasons.
For stories, these are: “Off-topic” for stories that are not about computing; “Already Posted” for duplicate submissions and links that elaborate on or responses to a thread that’s less than a week old (see merging);
… if the project uses issues as a bug database. Perhaps the devs are using issues only for their own, internal project planning. Yes, They’re happy to share their work. They’re happy to sometimes pick up a few details, fix a bug, work on things that you report that align with their interest. Other times they will ignore the issue and let it get automatically closed.
I seriously think this is more a problem of people in this discussion assuming that issues are only used for bug reports. And that the developers want to cater to community. In reality, it’s often not the case. The devs will take input in the form of big reports, but not let those things guide their development roadmap.
The solution I have found is to get rid of GitHub issues and only have GitHub discussions instead. With discussions, you can mark things as “support” and get it out of the queue of “open issues” that you are responsible for solving somehow.
Renovate recently did a similar thing where Discussions are opened first and after some triage and possible debugging, the maintainers will then raise an issue if it’s relevant to do so (for ie bugs/feature requests) and keeps the issue tracked quite clean!
It’s a difference that doesn’t matter. What it says to users like me is still “Don’t bother reporting bugs. They don’t care.”
If they can’t even be bothered to opt me out of stale-botting for things that are trivial to confirm the existence of, like “Please add back the details that were on the old UPX website”, then there’s no point in me wasting my precious time.
Having people play “No, you may not brush me under the rug” whac-a-mole with a robot without even triaging stuff is terrible PR (Public Relations). End of story.
…and, as an example, that “Please add back the details that…” refers to how the current website uses “universal: UPX can pack a number of executable formats, including Windows programs and DLLs, macOS apps and Linux executables” to “market” a tool that, after you’ve installed it, will print something like this in its help:
Do they really think that people will intuitively interpret “a number of executable formats, including Windows programs and DLLs, macOS apps and Linux executables” to mean “This is suitable for packing your PlayStation 1 homebrew, your Atari TOS binaries for Motorola 680x0, and your real-mode MS-DOS .com files?”
I’m sorry, I have no idea what this wall of text means. And I don’t have enough time left on this planet to figure out the recesses of people’s mental states on the internet. If you have an argument, make it plainly and concisely.
TL;DR: It’s a difference that doesn’t matter. If they can’t be bothered to even look at the bug and recognize “Yes, this is obviously valid and will remain so until we make a ruling on it” and whitelist it, then a stale bot is actively user-hostile.
What if it’s outdated? Not really relevant any more? What if it was already fixed at some point?
If it’s a valid issue and someone is still facing it, is it too much to expect that person to confirm it once every six months? If it’s valid but closed, can someone not find it and comment ‘hey, I’m still having this issue’?
If it’s a bug, as long as the bug continues to exist. If it’s a feature request, until it either gets implemented or they decide that they won’t accept a PR to implement it.
An issue tracker is a form of documentation for the state of the repository, not just for people with commit access, but for passing potential contributors.
EDIT: And having said that, it now occurs to me that you could see stale botting as a form of “cooking the books”… lying about the state of your project in a public communication channel.
Whose responsibility is it to maintain a complete and up-to-date documentation of the state of the project in public? Is it the maintainer’s? Why should it be? Why should they be doing this extra unpaid work on top of what they are already doing? How is it fair that just by being an OSS maintainer, they have to take on all these additional burdens, otherwise people can call them liars and cheaters with impunity? How does that make sense?
As a maintainer myself, I don’t believe perfection is a responsibility… but I do believe that passive neglect is more honest than robotic “cleanup” via deletion of information without triage.
The information is not deleted. The issue is closed. Most stalebots give plenty of notice of stale status and impending closure, anyone who is interested in the issue will usually be notified about it and have a chance to ask that it be kept open. Also most stalebots close issues with a comment explaining that it was closed due to inactivity, as opposed to the issue being actually resolved.
Personally I don’t find the fact that an issue has open status, is all that meaningful. You can’t just take issues at face value especially in the open source world. You have to periodically re-vet the issue and check if it’s still valid. Whether it’s open or closed doesn’t really matter too much.
“Buried in a landfill of actually fixed or irreproducible bugs” isn’t that different from “deleted” in real-world experience. It’s like saying that stuff that’s in the Wayback machine isn’t deleted when its internal support for searching archive stuff sucks.
‘Buried in a landfill of open issues’ isn’t that different from ‘buried in a landfill of closed issues’. If you see a neatly curated and triaged list of open issues, and your thought process is that ‘well, my issue should be in this open issue list’, then you are missing the point. How did the neatly curated and triaged list of open issues get to be that way, by accident? Or with careful management and application of automation tooling as appropriate?
I used to be very against stale bots until a project I started gained some traction.
At first, I was excited for every issue and PR, but as the number of users grew, so did the issues and PRs. Some of them there was just no way I could handle (for example, they only happen on macOS, and I have no way to afford a Mac). I left them open out of respect, but it definitely demoralized me to see issue numbers pile up.
After a certain amount of time, I just burnt out. I wasn’t checking issues or PRs, because I felt that if I replied to one, I should at least have the decency of looking at the others. I mean, these people took time out of their day to contribute to something I made, and I ignore their issue in favor of some other random one just because that’s the one that happened to be at the top of my GH notifications? So I just stopped looking at them, and they kept piling on and on to the point where it was completely unmanageable.
Thankfully I never had to resort to stale bots. Some dedicated users reached out and I made them maintainers, and they’re the ones taking (good!) care of the project now. I even moved it to the nix-community organization so it was clear it was no longer just “my” thing.
Still, I can definitely empathize with those who use stale bots. If I had that set up, I probably wouldn’t have burnt out so quickly. I know it might feel disrespectful to close the issue after some time, but I feel it’s even more disrespectful to just ignore everything completely due to the number of issues. (Similar thing happened recently with lodash, who closed every issue and PR by declaring issue bankruptcy)
More than anything, this highlights how incredibly underbaked GitHub Issues is as a bug tracking platform. There are any number of reasons that an issue may remain open; e.g., it has not yet been triaged, or it has been triaged and found to be low priority (e.g., if you aren’t actively supporting Mac users, perhaps any issue found on a Mac is low priority), or it’s frankly just not super important when compared to fixing critical defects and security issues. It should be possible to focus your attention on just the high priority, actionable issues, without being overwhelmed by the total open issue count.
It’s not unhealthy for a project to have a backlog of issues that may remain open indefinitely, reflecting the fact that those issues are lower in priority than the things you’re getting around to fixing. Closing issues really ought to be reserved for an active refusal to make a particular change, or if something that’s reported is not actually a bug.
I fully agree, it’s also definitely why I never closed any of those issues - I would love for them to get fixed! The first time I actually closed a contribution, it was a PR that contributed a ton of stuff, but it was just so disorganized (it really should have been split up into 15+ PRs) that it would take me weeks to get over all of it. Still, it took me over a month to own up to the fact that I was never going to be able to merge it in that state, and I felt horrible about it at the time. They took a ton of time to make a bunch of contributions to my project! And I just refused them. Still feel kind of sad I couldn’t find a better way to merge that. Long-term, though, it definitely improved my mental health (which was at an all-time-low at the time).
Thanks for sharing this, and I can understand the urge to close those issues, fix them and keep the number down. But I also learned to just live with it. Maybe some people will have to get into the same position first to understand why a maintainer spreads their attention so selective, but they will eventually. The other option is to just give up and then nothing progresses. I’ve had issues where I don’t have the hardware for or time, and eventually someone came around to work on it.
You did the right thing. The difficulty of reviewing a PR scales with something like O(lines^2) * overall complexity of the diff. And if someone is willing to put that much work into a PR, they should be willing to put in the extra time to make it possible to review. Otherwise I’d suspect they were any of several bad characters:
The CV stuffer.
The security researcher looking to prove their pet theory about code review/open source.
The artiste, who will berate anyone too stupid to understand their clearly superior work.
That still has the problem of “I need to go look through every issue” which can be challenging at times (burn-out, ADHD, simply too many issues…).
I think this might actually be one of the most reasonable uses of a stale bot - just mark it as “stale”, but don’t do anything else. That actually signals to the maintainers that these should probably get looked at!
I mean if the stale bot is closing issues without anyone looking at them, then it could be closing issues that are both important and easy to fix. Then any sense of being on top of things that you get from seeing fewer open issues would be false, and worse you are pissing off people who open issues that are closed for no good reason.
I think this might actually be one of the most reasonable uses of a stale bot - just mark it as “stale”, but don’t do anything else. That actually signals to the maintainers that these should probably get looked at!
I don’t see the point. Couldn’t maintainers just sort open issues in chronological order of the most recent activity?
For your example. Wouldn’t it make sense to mark them as macOS and simply ignore them and only review something with code passing tests there?
I think it’s okay to have stuff you cannot work on and I think it’s wrong to assume that you get everything just because you write about it.
Maybe I am overly focusing on that example, but I don’t think this somehow gets solved by a stale bot and you didn’t use one for a reason.
I think that it makes sense to make clear what a user should expect. You can clarify that you won’t support a certain platform, you can clarify that you cannot support it, but accept patches. And you can certainly make clear if you don’t want to use your issue tracker to give support.
It’s fine, it’s not rude. Of course being on a non-supported platform can be a bummer and as someone who often uses more exotic things I hope that doesn’t happen and I am always happy when someone at least would welcome patches.
I think stale bots are rude for the reason you mention. If you have an open bug tracker and I contribute something sensible having a bot close it down doesn’t feel like the nicest thing. Of course there might be “I want this” and “How to do this” issues, especially on GitHub, and they tend to be closed, but that’s not what the stale bot does. It’s worse even, it kind of strengthens that attitude since people who write “I still want this”, “When is this done”, “This is important”, “Your project sucks without this”, etc. will prevent the issue from going stale.
Stale bots don’t seem to be a good solution here, since it feels like they do the opposite of what you want.
Do people feel accomplished when bots close issues for more often than not no reason at all?
And yes, the GitHub issue tracker is bad. People get creative though with templates. Maybe that’s a better way? Maybe another way would be using an external issue tracker.
I agree with what you’re saying, and the quality of issues/PRs improved significantly once I added some basic templates.
Still, while I don’t particularly like stale bots and wouldn’t put them on my projects, I just meant to say I get why people reach for them. Not that I particularly agree with bots who just close issues independent of triage status.
But yes, I think GitHub’s fairly simplistic issue tractor just makes the whole problem a lot worse. But I also think that a project would need to reach a certain scale before an external issue tracker is justified. I mean, I have no idea how I’d submit a bug report to Firefox. Some random library I found on GitHub though? Sure, just open an issue. There’s a lot of value in that.
Nothing worse than finding a bug in software, checking the issue tracker and finding the exact issue you’ve encountered has already been reported and closed by a stale bot.
This immediately gives me the impression the maintainers aren’t interested/ don’t have the time to solve the issue. I’m not going to spend the time to open a duplicate issue because it’ll likely just be closed again.
Bugs don’t just disappear because a GitHub bot closed the issue.
I get the impression maintainers have anxiety around the number of open issues and this reduces that anxiety by hiring the problem.
Are you sure? Maintainers change. Hopefully the comment will raise awareness that someone new can reproduce, or will support a change. The comment will add signal, and counteract the signal of “stale”.
People have limited hours. Reading a new comment takes less commitment than choosing to close an issue.
Issues are firstly a task list for maintainers and developers. They should be allowed to manage their task list however they like 🤷🏻
If the stale bot message isn’t polite enough (or gives the wrong impression) or if important bugs are never being addressed then those are separate problems that can be dealt with independent of stale bot policy.
I agree this is a valid (if uncommon) way to use issues, but in such a case one should not allow outsiders to make new ones and instead take feedback via some other mechanism.
Strongly agree. I think it would make sense on pull requests however, if the pull request had no activity for X days, and never achieved passing the tests, or was never marked as “ready for review”. Still, as a maintainer I prefer to close such pull requests manually. It’s not that much work after all, and sometimes I can make an exception to help the contributor get their patch landed even though it wasn’t fully ready.
As I read the article it occurred to me that none of the excuses given really let stale-bots off the hook. In every case, leaving issues unread and/or unhandled is IMO less rude than having a bot close them. It’s the difference between saying “I can’t get to this right now” and saying “Your contribution has no value to us now, and never will.”
Sorry if I wasn’t clear. To clarify, leaving a PR unread says “I can’t get to this right now” but doesn’t make any judgement about the PR itself, and leaves open the possibility that the maintainer (or some future maintainer) will look at it. Having a bot close the PR says “this is worthless to us and we will never look at it.”
I assumed we’re talking about issues, not PRs, but I still disagree.
Bot closing the PR did not say “worthless”. It just said, “stale”. The PR (or an issue) going “stale” is almost literaly the function of the person “not having the time to do this right now”.
In certain cases, not responding to someone’s work can be worse. “Great, I opened a PR months ago and they’re ignoring me!” vs “I opened a PR, but since nobody had time for it, it got marked as stale.”.
I think the underlying issue is often people attributing things to events that are not necessarily there. Throughout the whole comment thread here on lobsters, people are expressing differing opinions. But look at the observable facts:
A maintainer has a publicly accessible repository.
A user is using it. They found a bug and reported it.
The bug got marked as stale.
A thousand people will interpret it a thousand different ways. Should I report a bug if I find it? Am I allowed to ignore it? If I do report a bug, am I entitled an answer? Or at least a look? Or 5 minutes of that maintainer’s time? We just assume, since the project is public, that it is also a community project, and there is an obligation on the maintainer to maintain.
Personally I remember the “good” old times of BOFHs and every question you ask on mailing lists being answered with RTFM. I’m happy that it’s not like that any more - for most things that I need, I can probably ask a question, someone’ll answer me. But I’m still keeping that mindset of old ways of open source - if I have a problem, I am in charge of fixing it. And I’ll send the patch back to source, or perhaps a PR or a comment, but I don’t have expectations that anything will be done about it.
But I understand this isn’t how most people expect things to work.
Several times, including as I read this comments section, I have considered writing a bot that automatically keeps issues open for me in the most aggressive projects. It could have rules about this - e.g. maybe it would refuse to work if the stale configuration only kicked in when a label (like “needs info”) had been applied. Stuff like that.
It feels disrespectful to maintainers’ choices, even if I disagree with that choice, which is why I probably won’t do it. But man do stale bots feel disrespectful of my time too, and they also feel frankly like the result of a shoddy engineering mentality.
I think you’re not the target audience. You’ll open an issue, include details, send info, talk to devs.
I’ve seen large open source projects having hundreds of issues, most of which are not issues but requests for help. The answers to which can be found in the docs, often.
The conflict here is that you think the issues serve you. And the developers think it’s for them, to plan their project.
Issues are often used both as “things to work on” as well as “bug reports”.
Separating these somehow would let the devs for the work, and reporters report.
Any project popular enough to have sufficient issues/PRs to overwhelm a solo maintainer, should stop having a solo maintainer. Stale bots are not a good substitute for either (a) learning to involve others and delegate, or (b) handing off the reins.
The maintainer does not understand their responsibilities. They should hand over their hat if they’re not willing to deal with issues properly.
The maintainer is simply sharing their work. There’s no responsibility to keep issues open. This might be an unspoken “rule” of open source, but it’s actually just a strong convention. The maintainer decides what “properly” means for their project. The existence of a stale bot should be clue enough on the maintainer’s stance. The maintainer can keep sharing their work their way while forks exist.
The response to the hypothetical complaint doesn’t really negate the issue raised. If the maintainer wants to run things their way, only write code, and not be bothered by issues/PRs, that’s fine. But they should publicly encourage a fork, redirect people towards it, and go back to their personal repo. This almost never happens. (Possibly because changing all the links/sites/artifacts/etc is hard. Or possibly because they still want to enjoy the cachet of helming a popular project without actually doing the things popular projects do.)
Instead, the open-source community has trended in this weird direction in the last few years, where they’ve stopped seeing open-source as a fundamentally collaborative endeavor. We’ve started adopting this toxic view of OSS as a one-way relationship, where creators have given you this wonderful gift, and users are now parasites instead of symbiotes. I dislike this attitude so much, and I’ve tried to make it a point to publicly thank all contributors to my projects in each release.
If you don’t want to run a popular project, just leave or hand it off. Nobody’s chained you to it.
If you do like running a popular project, well… maybe spare some gratitude for those who made it popular? Your users also contributed their time and energy. In addition to PRs/issues, they recommended it, answered newbie questions, gave talks, wrote documentation, published books, started cons, etc. They gave your project, and by extension you, many gifts of their own. That’s how gifting works in society.
Whatever the maintainer’s answer is, remember they have the final say on how they run their project.
Open source is about us collectively working together. If I contributed to it, at least in small part, it’s our project (even if weighted by contribution).
Just because someone put a project on github and added a license to it does not mean they have entered a social contract with anyone else beyond what they put in the license. They owe no one anything. They have not joined a community automatically nor have they automatically created a community. It’s frankly disrespectful to pretend that they did. It’s just as easy for a user to fork the project as it is for the original author do what you suggest.
It’s entitled and disrespectful to expect them to do so when they didn’t sign up for any community management in the first place. The real problem here is that the users are assuming intent on the part of the author and getting mad that they didn’t tell them the intent wasn’t proper to assume.
Maybe if they don’t go around assuming that intent in the first place they won’t get angry about it.
First, you may not like existing in society, but you’re still expected to adhere to social norms, and this applies to OSS too. (For now.) I view this the same I way view people trying to get out of tipping in the US. Being a good participant means stepping aside if/when the time comes. “Entitled and disrespectful” applies equally to the view that maintainers owe nothing reciprocally to those who have helped them.
Second, “It’s just as easy for a user to fork the project as it is for the original author do what you suggest” is incorrect. Forking a repo may be easy, but moving a whole project and it’s ecosystem is not. Historically, it rarely happens. If it were easy, the maintainer wouldn’t be bombarded, because the fork would displace the original pretty quickly.
The “social norms” in question arise from hosting on GitHub. FLOSS projects preceded that by quite a bit. If you tried being a Karen on an old-style mailing list, you’d get harshly directed to the FAQ, or banned from the project.
In fact, if more maintainers were made aware of that by hosting on GH they’d have to yield to the demands of every user with an account and some free time, more people would decide to host elsewhere.
In fact, if more maintainers were made aware of that by hosting on GH they’d have to yield to the demands of every user with an account and some free time, more people would decide to host elsewhere.
That’s an interesting point. I do use github, but really only for interacting with projects other people have decided to host there. (I’m not antisocial enough to complain about that… If I value a project enough to contribute, I’ll use whatever platform the maintainers choose, within reason.) In part because of the social dynamic github gamifies and encourages, though, for stuff I want to share myself, I default to sr.ht. I’d rather pay a small fee than make people think I’ve signed up for some of the more toxic expectations I’ve observed there.
(It’s not just social. I do like the tooling there a little better too. But funneling interactions to an old style mailing list with all the social norms that entails, plus being easier to set up for a new project than either github or gitlab makes it an easy default for me. If I were concerned about “stars” or some near equivalent, my math might be different.)
I have a ton of projects on github. Most of them have no users, but they’re there if you want them, for whatever reason.
For some weird reason, one of those projects took off, and all of a sudden I went from not really having to care about them other than adding the stuff I felt necessary to spending 1-2 hours every night managing the “community” aspect, fixing issues and checking PRs.
So all of a sudden this fairly large amount of work fell on me when I never really signed up for that. I don’t want to put a “no contributions” banner on my projects - they’re incredibly appreciated, I want contributions! But at the same time, I’m not particularly ready to manage 3 to 4 issues/PRs of varying quality per day. Especially when I leave for a month and come back to a massive backlog. I might’ve taken a break, but the users sure didn’t. There’s no real way to combat that. Not to mention, I have ADHD (unmedicated at the time), which just made the task of going through all of that so much more daunting.
So what do I do? “Hand it off” is easy to say, but I had to find someone to hand it off to. I had the luck of having people reach out wanting to take care of that, and they’ve done a phenomenal job, but not everyone has that luck. That’s why people reach for stale bots. There’s just not enough maintainers to go around, and “issue bankruptcy” is a real problem. Sure it’s rude to close people’s issues without checking them, but it’s even worse to just let the project die due to maintainer burn-out. Stale bots prevent that, at least somewhat.
I also have unmedicated ADHD and the pandemic led to me essentially dropping everything on the floor even worse than usual. However, out of respect for reporters, I would never use a stale bot.
If the reports pile up, they pile up. Recently, I’ve started to pick up the pieces and, for things that a human (me) judges to be stale, I close them with a polite, custom-to-the bug variation on “Sorry I let this languish for so long. I tried to replicate it based on the information you gave me, but couldn’t. Feel free to reopen the bug if it’s still a problem.” (And, as for the feature requests, I’ve been adding more metadata.)
I maintain a couple projects that have 3.5k stars between them, but luckily, they’ve been around a while and are pretty stable, so the issue list isn’t overwhelming.
Part of what works for me is, when someone submits an issue, I usually say “This looks like a good issue. Submit a PR?” Most won’t, but some do, and now I have a couple collaborators with commit access, and more one-time committers I can tap if need be.
I feel like the response post here is arguing something of a different point from the original post. The original says “stale bots are a bad solution to your problems. Here are other solutions that will work better.” The thesis of the response seems to be “don’t be mean to overworked developers who are managing a popular open source project. They don’t owe you anything.” Which, like, okay, sure. But that’s not what the original post was saying.
Looking through these comments, the discussion has shifted to talking about how much project owners owe their users, which isn’t what the post was about. It would indeed be bad to drive someone into taking down their open source project by harassing them for using a stale bot, but what does that have to do with anything? The bottom of nostalebots.xyz lists some projects that have stale bots, like Ruby on Rails, k3s and Flutter. These are not small projects. They’re not run by a single, inexperienced, overworked developer. Stale bots are used by large repositories run by billion dollar companies who could absolutely spare the resources to properly manage issues.
“Don’t bully someone for using this thing when they’re in a tight spot and don’t know any better” or “people who give you free code don’t owe you anything” are fully general counterarguments that distract from the original point. Imagine someone posts “why you should write your project in Zig instead of using punch cards” and a response comes along which spins a tale of some starry eyed repo owner who didn’t know better being berated for using punch cards because all they have access to is an IBM 1401 from 1962. That would indeed be bad, but it’s irrelevant.
Some of these comments (like mine) were for another, semi-related article, whose comments were merged into this one.
I had no idea lobste.rs mods could do that. If it seems confusing, it’s because we were discussing a blog post on the same topic, but saying the exact opposite.
This is very usual within discussion sites like this. People skim an article (or in other places, just read the headline - this never happens here! /s) and cherry-pick what to take from it.
I found the tone of the original submission abrasive and overly generalizing, which the response post picked up on.
One way to keep issues from accumulating without progress is to prevent issues from being created unless they are accompanied by a working patch that fixes the issue.
This is true, but it’s also incredibly hostile to your community. Any good engineer knows the value of a clearly described bug report.
I would say the only way to make this work without being a jerk is to make it clear that the project is for you, not other people, and you just happen to have released the source code. And if that’s not true you probably shouldn’t be using this policy.
Open Source developers voluntarily give away years of the precious few they have on earth in the form of functional software. Most of the time they are building tools for other developers to use. It’s the peak of entitlement, if not outright abuse, to insinuate they are jerks or being hostile for requiring comparatively little effort in return to acquire more of their free time. Not to mention, the point of requiring a patch is to keep the issue tracker and the project as a whole healthy in the long run.
Open Source developers are not faceless corporations, nor do they have any obligation to anyone. Their code is provided WITHOUT ANY WARRANTY.
It’s hostile and passive-aggressive to have an open issue tracker, which implies you’ll triage what people put into it, and not post any notices to the contrary, and then just ignore people until they give up and go away, leaving them to play ping-pong with a robot.
If you have an open source project, an open issue tracker it’s asking for contributions in form of issues. If then someone give away years of the precious few they have on earth in the form of well researched and documented bug reports and you, the person who essentially asks for it has a bot use up the contributors time by playing a weird game asking to spam that issue with more messages then that’s somehow more okay?
The open source developer owes me nothing, but if they ask for input (bug reports, patches, etc.) and don’t even look at it and waste contributors’ time (both the ones reporting and the ones looking for others having the issue) that’s just rude. It’s completely fine to say no you don’t want that, or that you don’t have time, or that you find the idea dumb. It’s your project. But you also wouldn’t have someone travel to your place to give you something for free and then have a sign up saying “try again tomorrow, maybe I’d receive your gift tomorrow, but maybe not”.
Why can the issue not stay open, if it’s still an open issue? If that would be clarified somehow that’s maybe clear, but if there’s just some software saying “stale”, closing the issue I will be disgruntled on wasting my time on someone/some project. If I want to sort out old tickets somehow, wouldn’t I just check the last updated time? If you don’t want issues, why not close it? If you don’t like something, why not clarify it?
So what I am saying is just as it’s not okay to waste a maintainer’s time it’s also not okay to waste a contributor’s time. They are both spending time on open source, potentially also both writing code for a project.
And yes, it depends on the context. A lot actually. But if it’s a project with many commiters, looking like contributions are welcome, if I analyze and document a bug, write a patch, write tests and a bot comes along and closes it with a nothing saying message that’s simply not wasting other people’s time and rude as such.
If you’d prefer no issues reported that’s about as easy to clarify as setting up the stale bot.
Both you and the sibling commenter are responding to an argument I did not make so I cannot meaningfully respond to you. This specific thread nowhere has a defense of stale bots.
Void does use a stale bot. Unless something is assigned to a maintainer, or is actively being worked, it inflates our counts of issues with weird one-offs that nobody including the reporter cares to diagnose. This hides active issues, or issues we consider important. The stale bot also serves as a reminder to maintainers to consider merges that were e.g. stalled waiting for feedback.
Our numbers being bad is demotivating. We don’t want to bulk-close issues, but “stale-ness” is a useful metric for what should dominate maintainer’s free time. Meanwhile it doesn’t delete the work, so it can be revived should it prove important (a quick search will pull up such issues/PRs).
I do not believe we “lock” issues or PRs after they are closed for being stale. We do not wish to silence people, simply to put things about which nobody cares out of mind.
The problem is you have to ignore it every time you review open issues. And every time you spend a bit of time on that. Even if it’s only a second, such issues pile up and the total time lost accumulates.
That shows a lack of communication within the team. You should have a unified vision of what you want your project to look like, which determines whether an issue is relevant.
Yes, you said that. I’m asking why do you think it. Does it show a lack of communication, or lack of time on behalf of the maintainer?
I agree that getting an issue automatically closed off as stale sucks. Like getting a canned reply from a job application - couldn’t they at least tell you why they didn’t hire you?
The alternative discussed here is ignoring the user. Like, the issue stands there forever open. To me, it looks like nobody cares. To me, that is the lack of communication. Like applying to a job and never getting anything back. Neither of these are good to me, because they give me nothing personal. But in one case, I’m ignored, in another, I at least got some closure and know my thing is not important any more to anyone. I can either give up hope, or try to reopen or something.
But I understand that this is my own perspective. That is why I am asking, why do you prefer getting ignored over getting the closure in the sense of “we never got around to your bug report. give up hope or take initiative.”
Of course, ignoring the issue altogether is not ideal, but I’d argue it’s still better than having a bot close it – at least other users who have the same problem can see that it has been reported and may be fixed at some point when the developers have more time. But you could make a tag saying something like “don’t have time to fix right now” and put it on such issues. That would also help the “open issues are cluttering my issues list” problem because you could just filter out this tag. And of course, if you know that you’ll never have time for fixing the issue, just close it (you can also make a tag for that).
Hmm. That’s may partially explain your “lack of communication” point of view to me. You would expect that someone would just never look at all the stale issues if the bot closes them, whereas if the maintainer does it manually, it is assumed they considered it.
I can understand that. But just as you argue that “it’s still better than having a bot close it”, I can also argue that sometimes the people have no time, or desire, or a habbit, to do this. Perhaps they do the triage, perhaps they don’t, some will simply find it better for them to have the bot “stale” the issue if it goes 3 months without activity.
But it’s not a perfect situation in any case. I just don’t think it’s a lack-of-communication problem, but rather lack-of-time or lack-of-resources problem. Or more often, “conscious choice on where to focus ones’ energy”. Not that I think it’s a better or worse way to do things, I just think it’s a valid choice.
To be clear, my comment on communication skills was just a response to you saying that when working in a team, you might not know whether an issue is relevant. It doesn’t apply in other situations.
No,I meant by that that you commented to someone else, that if nobody responds to an issue within 3 months, it gets autoclosed, shows a lack of communication within the team. That’s why I asked you think that using a stale bot means there is a lack of communication.
Personally I don’t think one way or another, I think these two points are not related. Whether or not a team uses a stale bot, and whether or not there’s a lack of communication are separate points, they don’t seem to be co-dependent to me (unless of course there’s a deeper reasoning).
Go look at the organization. We have a stale bot, but how recently was the last “closed for stale” issue? The stale bot is for times when nobody actually wants to do the work and the work might be in scope, if someone anywhere was able to prioritize it.
Sometimes, sure. But if it is your default policy then it takes very little effort to ignore a new issue.
If you’re putting in the effort to properly triage the issue then, sure, it’s not much more effort to tag the issue up or leave a short comment, but triaging is work and leaving public comments is social risk: you may embarrass yourself by saying something wrong and/or may invite rude or tiring comments from people.
Related: I’m done with this thread. You haven’t been rude, but I am no longer interested in talking about it.
To anyone who doesn’t like stale bots–I highly recommend them to keep the issues open on their own issue trackers. That way, the bad old stale bot can’t close their issues!
To be charitable, I think the idea is that if you’re running a stale-bot, you don’t want to receive issues any more. But an open issue can be a good message board for people to share workarounds and hacks that “fixed it for me”, so the community needs some place to post those. Might as well do it in a different issue tracker.
OK, what happens when the maintainer sees it? Do they resolve the issue immediately? Within a month? Six months? A year? Are there any guarantees given? If the issue is not resolved, should it hang around the maintainer’s issue tracker indenfinitely? What if the maintainer wants a clean tracker with issues that they want to focus on only, without the headache of triaging a bunch of other issues they are not interested in? What if an issue that was filed some time ago becomes outdated or inaccurate because of changes in the software, and the person who filed it does not update it? Is the maintainer then responsible for periodically going through the list of issues and looking through each of them with a fine tooth comb for accuracy?
Basically, how much extra unpaid work would you like the maintainer to take on?
But the stale bot works deterministically with the parameters it was given by the maintainer. It’s not randomly snatching issues out of the maintainer’s hands. It’s implementing the maintainer’s decision and policy.
Good idea. Maybe I should add a “Stale-botting wall of shame” to my website where I collect any bugs I reported that failed a “three strikes and you’re out” policy for having to tell the bot “No, It’s still relevant” without any sign a human has ever read the thing.
It wouldn’t be intended for the maintainers. It’d be intended in the same vein as https://gcemetery.co/ …a way to warn potential users before they get burned.
Heck, to make it a bit more objective, maybe I could tie it to some sort of quantitative measurement of how much user effort has been wasted, per project, posting “still a problem” keep-alive posts on bugs that were just ignored until people lost interest.
Raku handles this nicely, I asked if a certain thing should work a certain way, it was near instantly added to the specification, for implementations to align against at a later date.
Separating triage and implementation becomes really clean if you separate specification and implementation.
I dunno, that has problems as well. If the behaviour gets implemented then people will try it out and decide if they actually like it and agree with it (in the betas for the new release.or whatever). Actually having to implement stuff also means the implementer has to think about it more.
I feel like the response post here is arguing something of a different point from the original post. The original says “stale bots are a bad solution to your problems. Here are other solutions that will work better.” The thesis of the response seems to be “don’t be mean to overworked developers who are managing a popular open source project. They don’t owe you anything.” Which, like, okay, sure. But that’s not what the original post was saying.
Looking through these comments, the discussion has shifted to talking about how much project owners owe their users, which isn’t what the post was about. It would indeed be bad to drive someone into taking down their open source project by harassing them for using a stale bot, but what does that have to do with anything? The bottom of nostalebots.xyz lists some projects that have stale bots, like Ruby on Rails, k3s and Flutter. These are not small projects. They’re not run by a single, inexperienced, overworked developer. Stale bots are used by large repositories run by billion dollar companies who could absolutely spare the resources to properly manage issues.
“Don’t bully someone for using this thing when they’re in a tight spot and don’t know any better” or “people who give you free code don’t owe you anything” are fully general counterarguments that distract from the original point. Imagine someone posts “why you should write your project in Zig instead of using punch cards” and a response comes along which spins a tale of some starry eyed repo owner who didn’t know better being berated for using punch cards because all they have access to is an IBM 1401 from 1962. That would indeed be bad, but it’s irrelevant.
Two of the first things I do when reviewing an open source project for any kind of $WORK or production use are to look at recent commit activity, and look at issue tracking.
In terms of issue tracking, I want to see what types of issues are raised, how often, and how maintainers deal with them. Are they polite and helpful? Are issues resolved? Are devs willing to say “sorry, but this request doesn’t fit what we’re trying to do” where appropriate?
Personally, I would never mark a project down for using a stale bot. If it’s closing valid or active issues? Sure.
But if it’s closing down those issues where a maintainer has asked for more details and nobody has replied in two months? It’s saving time on issues that will never get fixed.
Like so many things, stale bots are a tool and used well, I think they’re a force for good.
Basic etiquette.
I think, with time, people will start to recognize that stale-botting is just putting a robotic coat of paint on the same boorish disrespect for others that is on full display in places like Twitter/X and YouTube comments.
If you don’t want to follow the implicit norms of the greater community, state so up-front. You don’t need to write a fancy legal document… just have the backbone and common decency to tell people what to expect of you, rather than ghosting them.
All of the perspectives raised carry an undercurrent of “I’m so special that I don’t have to engage in common decency”. Heck, now that I think about it, I think part of the reason stale-botting irks me so much is that, on some level, it feels like the decision to use a stale bot is passive-aggressive behaviour.
I dunno, I believe users who treat open source projects like they’re a product they’re paying money for, and who demand to be treated as paying customers, are the ones who are boorish and disrespectful.
Better to tell them that than to have a bot close their issue
Not everyone has the mental energy to do that, though.
Which is exactly the passive aggressive behavior the thread starter is referring to. I would say if you don’t have the mental energy, maybe let the issues sit open until you do.
Why is it passive aggressive? They have have a project, they are happy to let others use it, but they aren’t (yet) expecting to follow everyone else’s needs. Let them deal with their project how they wish, without having to apologize to everyone for everything in advance.
Because human communication has norms. If I spit in your face. It doesn’t matter if I think it’s not a grave insult. What matters is what the cultural norms we exist in consider it to be.
Yes, that’s my point exactly. Why did the commenter above think that this behavior is passive-aggressive? Because I don’t, and they apparently do.
So yes, human communication has norms, but as far as I know, one of them is “my house, my rules”. Why should users expect that some project runs issues just the way they, the users like it? Why can’t they just abide by the rules of the house? The maintainers could very well be passive-aggressive, but maybe they’re not, maybe they just don’t have a lot of time or interest in chasing bugs.
That’s what I’m referring to - we cannot assume someone has a certain state of mind (passive aggression) based only on the fact that they employ a stalebot. We would need other source of data. Stalebot is most certainly a norm that some projects use - but not all - so why can we say it’s wrong to have them?
I’m the person who said it originally and I said it feels like passive-aggressive behaviour and that’s why it bothers me so much.
Because you’re publishing your project into a public space with defined expectations. Psychologically, it’s closer to renting a space in a shopping mall than a private home, and people are upset at “how rude the staff are to window-shoppers”.
If you don’t want people wandering into your rented commercial space with expectations of your behaviour, then post proper signage. Just because the “mall” has effectively no size limits and offers space for free doesn’t change that.
Again, this is very situation-specific. I personally had had office space rented, when I was freelancing a lot. It was a small space next to a cafe. I didn’t mind people smoking on the caffee’s terrace, but I did mind if they did on mine. (I really didn’t. But it works for the example).
Now, I can expect that people will come in my commercial space because it’s next to that cafe. And I can also expect that some of them will be smoking a cigarette. Which is also fine. But despite all that, if I ask them to put the cigarette out, or if I stale-bot their stale issue, I don’t think I’m aggressive. I just think I have my rules, and in my (rented, commecial-space) back yard, I should not have to feel pressured to explain the reasoning behind those rules.
Once more: the bottom line is that the passive-agressive feeling is very personalized. I may really like some behavior where you might not, and we’ll feel different kinds of pressure when witnessing said behavior. That’s why I think that the passive-agressive comment can’t really stand as it is overly generic.
The comment about it feeling passive-aggressive was secondary anyway. The primary point was that it was an active violation of the etiquette of the public space they set up shop in.
The funny thing about my mall example is that you’re responding to draft #2, where I now think draft #1 addressed your point better. Originally, I couched it in terms of setting up a library in a mall unit and then sending out a “shush bot” to patrol the segment of hallway in front of it rather than setting up proper sound insulation.
It’d just make people want to kick the bot and resent its owner.
Yeah, the passive-agressive stuff is not really relevant. I still disagree your point though. Why is my issue tracker, for my project, public space? Why do passers-by get to dictate my rules?
I don’t think we’ll agree on this. You seem to think that issues should not be automatically cleaned up by stale-bots. I disagree - not in that that I think that they should be automatically cleaned up, but in that that the choice is on maintainers and maintainers alone, not on the users of the project.
But let’s agree to disagree here and move on.
Do you mind if I ask a question or two to try to get a sense of your position on that before we part ways?
I’d like to get a sense for what you believe is reasonable to allow the project maintainers to decide. For example, I doubt you’d argue that GitHub should be prohibited from kicking users off their platform for gross abuses (eg. using a bug tracker to coordinate treasonous or genocidal activities), so there has to be a line you draw and the question is where you draw it.
(eg. Which side of the line is it on for you if maintainers choose to set a “norm” where they verbally abuse people who report bugs?)
Oh, but those two aren’t exactly the same, deciding whether to use a stale bot vs. being abusive, it’s pretty much different things we’re talking about.
To be upfront, I believe it’s absolutely reasonable for the platforms to deal with abuse. I also think it should be required, but it’s hard to set the limits of “what is enough”. But that topic is moderation, we’re talking stalebots here.
If you’re asking me if I would use a stale-bot, probably yes. I frequently have some inner-source or closed source projects, so it’s a bit different, but I would still use a stale-bot if I didn’t have someone who’s already triaging the backlog. That is not applicable here, though, since I don’t think I ever had a project with 300 open issues. Or if I did, they would be neatly “organized” into epics and stories and stuff, and out of my “current sprint” or whatever, and I would actually be paid and reserve the time to triage them.
For open source, I probably would like some automatiuon if I didn’t have the manpower.
Do you think, what’s my position in general? After a small consideration, I believe on most of these things I am quite liberal.
Each person gets to decide for themselves, as long as they don’t impinge on other people’s freedoms or break public rules. It may be sucky, and we have to work on that, but as long as it’s “allowed” by the general rules, we can’t and should not force anyone to do anything a particular way.
But even more, I don’t like “having a position” at all, mostly. I like having observations on how things work. You know how it is in software: for most questions, an experienced developer will answer majority of questions with “it depends”.
It is very often a question of a trade-off, not of “should we or should we not”.
In this case (stalebot), I think it is absolutely okay for maintainers to decide to use a stale bot. 100% their choice. Even if it was something that is as widely used as linux kernel - they are the maintainers, and they have to maintain the thing, so they get to pick what they want to do about stale issues.
People picking stalebots are probably not doing so much triage. I’m thinking e.g. Angular, where I frequently found open issues on my topic that are untouched for a long time. Sucks, I have no clue what’s with the issue, why is it still open, is it being worked on or what. (To be honest, I haven’t visited Angular GitHub repo in a while now).
People leaving open tickets probably do a bit more triage, but the already mentioned Angular example shows it’s not always the case.
As an end user in such a project, I am stuck either way. Either the issue is stale-closed, or it’s open but untouched, and I have no clue what to expect. Well, with a stale-closed issue I can probably expect nothing, with the open-but-untouched issue, I probably have nothing to look forward to as well, but there’s some false hope that it may be tackled sometime.
So, for me as a user it is usually irrelevant about what the maintainers decided.
Is it okay for Microsoft/GitHub to say, “no stalebots allowed”? Absolutely. Their company, their rules. We do have a choice (and I mostly do choose to go elsewhere). So now if maintainers want a stale bot, they have to go to GitLab or something.
Again, all perfectly within the bounds.
I don’t think my thoughts on any of that matter, though, they are just observations. Again, this is more a trade-off, then a final position - what is more valuable to me, at this time, vs. maintainer, vs Microsoft.
I don’t know if I answered your somewhat-open-ended question well enough, feel free to ask more.
I think you answered it fairly well and I’m not opposed to stale bots in general. In fact, I think it’s probably a good idea to have bots that tag things as “stale” for easier filtering for or against. It’s just the closing of issues that is the problem.
Likewise, I’m much less opposed to stale-botting with closure if the maintainers post clear notice so people know what they’re getting into before they invest their time, but I’ve said that before, so let’s not start that up again.
Thanks for the reply.
“my house, my rules”
A house is a poor framing for open source…it lacks the collaborative element.
Or… maybe it’s apt after all, but only if we think of it like a community barn-raising. You need a barn, so all your neighbors help you raise it. In turn, you’re expected to help them out when their time comes.
And if one of your neighbors barn gets struck by lightning and burns down, you’d have to be a terrible person not to offer to let them store some of their stuff in your barn until a new one is built.
No, I didn’t mean for the house to be the analogy, I meant, it’s their project, not a community project.
I get that a random third-party can get interested and involved and challenge the rules, but it’s still those project’s rules.
Look at the extremes. If someone came, and raised a pull-request on your latest zig hobby project that rewrites everything in Rust, or PHP, or whatever else, you would probably reject it. You made the technology choice for your own reasons. Perhaps to learn zig, perhaps for the fancy comptime. Rejecting that PR is pretty straight-forward, right? They can offer reasons (“it’s better”, “it’s faster”, “it’s slower” or similar). They can open a discussion. But with or without the discussion or reasons, if you simply reject the pull request with just a note “We decided to do this in Zig”, it would not be a problem, right? It was your technological choice.
I see it the same with the stale-bot choice. It was your project-management methodology choice. You could accept discussions, or be willing to change your potentially-inefficient project management ways, but if you don’t it’s your choice, since it is your project.
I know the two decisions are not in the same area (tech choice vs project management methodology choice). But those are the chosen ones for that particular project anyway.
That is what I meant by “my house, my rules”.
Does my reasoning make sense to you? I mean, I get that you still may not agree, but can you at least accept my point of view on why we shouldn’t expect people to stop using stale-bots, even if it’s inferior?
I understand your framing, yes. I just don’t think it’s correct to ignore the community aspects. And a PR about rewriting in another language is a bit of a straw-man; it’s an exaggerated hypothetical scenario that isn’t the real problem that arises.
Consider it from the perspective of copyright instead. My contributions to another project are under my copyright. It’s standard now to force contributors to assign their legal rights away (via CLAs), but the copyright still remains mine. Without CLAs, every project would be forced to treat their contributors as full participants. CLAs distort that.
Regardless, a contribution of code and assignation of legal rights is a gift, and warrants social consideration, if not legal consideration. It can be mostly, but not solely, your project.
Yes, I’m aware that that was an extreme example, I wrote so. I’m just saying that it’s very clear that there is some boundary where it is okay for me to have my rules for my project, and regardless of the quality, size, value of your contribution, I do not have to accept that contribution. Now, if we can agree to that - that some things are under my control, I just think that most people will have different opinions on what things are mine alone.
I think it’s acceptable for maintainers to decide on the stale-bot rule. I may think that in some cases it’s wrong, in some others it’s the correct way, but in no case do I think that I have any say in their decision. I may provide input, or express my wishes or preferences. I may try to persuade them, or pay them or whatever, to take that decision one or another way.
But whatever they decide, I don’t think it should be considered rude, anti-social, not-in-spirit-of-open-source or any of the things this entire comment section is mentioning - it’s just a simple project management decision, in my eyes, and it is theirs to make.
Taking the time to write up and submit a good bug report (potentially including investigation of relevant code, surrounding behaviours etc) is not treating a project the same as a product you’re paying money for. Having such bug reports closed by a bot is pretty annoying. I don’t want to waste my time submitting bug reports if the maintainers aren’t interested in actually fixing bugs, but this has happened on any number of ocassions (not always with stale bots involved, sometimes the bug just sits in the bugtracker forever) with various projects.
Sure, there are lousy users with excessive expectations and demands as well. That doesn’t justify ignoring quality bug reports. If you don’t want bug reports, don’t have a public bug tracker, or at least make it clear exactly what kind of bug reports you do and don’t want and what sort of expectations the submitter should have. As a maintainer you don’t have the right to waste people’s time either.
Let’s say that in this situation, the project doesn’t use a stale bot, but everything else remains the same. Your finely crafted high-quality issue goes unacknowledged and un-actioned indefinitely. The end result is the same: you feel rejected and disrespected.
Not using a stale bot is not going to make a maintainer action your issue faster.
Ah, but having a huge list of unanswered issues is a red flag! You would not contribute time and effort to such a project. And that’s true. So what you need to do now, before submitting an issue, is to check the list of Closed issues, and eyeball if they’re closed by a stale bot or not. This is a tiny bit of extra work but less than submitting a good bug report and then nothing happening.
No, if my bug goes perpetually un-answered, I assume many things (maybe the developer is overworked. Maybe, like me, they have ADHD. etc.) but I don’t feel actively rejected and disrespected.
If they use a stale-bot, it feels actively user-hostile. It says “this person doesn’t even have the decency to leave my report to languish”.
This is pushing the responsibility on to the wrong person. It’s easy enough not to think to check through issues to see if they’re being dealt with appropriately; especially so if there’s a detailed issue template (for example) that makes it look the project takes bug reports seriously and there are no obvious “website is only held together with sticky-tape” signs that hint a project isn’t really maintained. I don’t think to check for auto-closed bugs before opening a bug report (but thanks for the suggestion, it’s something I might try to do in future); the tendency for projects - even large, supposedly maintained projects - to simply ignore bug reports (or auto-close them) isn’t something I expected until bad experience taught me otherwise, with however much time wasted in the meantime.
The result: I tend to put less effort into bug reports now, if there’s any indication at all that there might not be any interest from maintainers. If the maintainer responds at all, I’m always happy to do more legwork, but speaking as a maintainer myself, this still isn’t optimal.
On the other hand it’s trivial for a maintainer to simply shut the issue tracker down, make it private, or at least stick a note in the issue template (or even the project README) that the issue tracker is for maintainer use only (or whatever), without risk of wasting anyone’s time at all and without generally bringing down the open-source experience. I would do this; I’m not asking anyone to do anything I wouldn’t do myself, and I think it’s a better outcome than either abandoning the issue tracker or auto-closing bugs in it. But if it has to be one of those, at least just abandoning the tracker makes the state of the project clear.
It’s later addressed in the post. Sure it’s “basic etiquette” once you know it. But you may not even be aware of it. The use of stale bots is not necessarily evil. These are just some unspoken rules we’ve come to agree on. And I think maintainers should be educated rather than shat on here.
Also lol @ the flags on this post. I searched for it before and didn’t see it already posted. And I have no idea how “no stalebots” could be on-topic but “yes stalebots” off-topic…
https://lobste.rs/about says
I couldn’t agree more! Stale bots are just the ostrich approach of sticking your head in the sand.
… if the project uses issues as a bug database. Perhaps the devs are using issues only for their own, internal project planning. Yes, They’re happy to share their work. They’re happy to sometimes pick up a few details, fix a bug, work on things that you report that align with their interest. Other times they will ignore the issue and let it get automatically closed.
I seriously think this is more a problem of people in this discussion assuming that issues are only used for bug reports. And that the developers want to cater to community. In reality, it’s often not the case. The devs will take input in the form of big reports, but not let those things guide their development roadmap.
The solution I have found is to get rid of GitHub issues and only have GitHub discussions instead. With discussions, you can mark things as “support” and get it out of the queue of “open issues” that you are responsible for solving somehow.
Renovate recently did a similar thing where Discussions are opened first and after some triage and possible debugging, the maintainers will then raise an issue if it’s relevant to do so (for ie bugs/feature requests) and keeps the issue tracked quite clean!
Alpine.js does it too. It’s a good system.
Stale bots are equivalent to being on hold and having to press a digit every minute to not get disconnected in a wait line.
It chases a metric with artificial pressures with people that have a life of their own constantly spammed by so many distractions.
Except that it’s being on hold for a year and having to press a digit once a month. The timelines change the context quite a bit.
It’s a difference that doesn’t matter. What it says to users like me is still “Don’t bother reporting bugs. They don’t care.”
If they can’t even be bothered to opt me out of stale-botting for things that are trivial to confirm the existence of, like “Please add back the details that were on the old UPX website”, then there’s no point in me wasting my precious time.
Having people play “No, you may not brush me under the rug” whac-a-mole with a robot without even triaging stuff is terrible PR (Public Relations). End of story.
…and, as an example, that “Please add back the details that…” refers to how the current website uses “universal: UPX can pack a number of executable formats, including Windows programs and DLLs, macOS apps and Linux executables” to “market” a tool that, after you’ve installed it, will print something like this in its help:
Do they really think that people will intuitively interpret “a number of executable formats, including Windows programs and DLLs, macOS apps and Linux executables” to mean “This is suitable for packing your PlayStation 1 homebrew, your Atari TOS binaries for Motorola 680x0, and your real-mode MS-DOS
.comfiles?”I’m sorry, I have no idea what this wall of text means. And I don’t have enough time left on this planet to figure out the recesses of people’s mental states on the internet. If you have an argument, make it plainly and concisely.
TL;DR: It’s a difference that doesn’t matter. If they can’t be bothered to even look at the bug and recognize “Yes, this is obviously valid and will remain so until we make a ruling on it” and whitelist it, then a stale bot is actively user-hostile.
The rest was just an example.
What if they looked at the bug and didn’t have the time or resources to fix it? How long does it hang around? Indefinitely?
If it’s a valid issue and you want to fix it at some point, why not?
What if it’s outdated? Not really relevant any more? What if it was already fixed at some point?
If it’s a valid issue and someone is still facing it, is it too much to expect that person to confirm it once every six months? If it’s valid but closed, can someone not find it and comment ‘hey, I’m still having this issue’?
If it’s a bug, as long as the bug continues to exist. If it’s a feature request, until it either gets implemented or they decide that they won’t accept a PR to implement it.
An issue tracker is a form of documentation for the state of the repository, not just for people with commit access, but for passing potential contributors.
EDIT: And having said that, it now occurs to me that you could see stale botting as a form of “cooking the books”… lying about the state of your project in a public communication channel.
Whose responsibility is it to maintain a complete and up-to-date documentation of the state of the project in public? Is it the maintainer’s? Why should it be? Why should they be doing this extra unpaid work on top of what they are already doing? How is it fair that just by being an OSS maintainer, they have to take on all these additional burdens, otherwise people can call them liars and cheaters with impunity? How does that make sense?
As a maintainer myself, I don’t believe perfection is a responsibility… but I do believe that passive neglect is more honest than robotic “cleanup” via deletion of information without triage.
The information is not deleted. The issue is closed. Most stalebots give plenty of notice of stale status and impending closure, anyone who is interested in the issue will usually be notified about it and have a chance to ask that it be kept open. Also most stalebots close issues with a comment explaining that it was closed due to inactivity, as opposed to the issue being actually resolved.
Personally I don’t find the fact that an issue has open status, is all that meaningful. You can’t just take issues at face value especially in the open source world. You have to periodically re-vet the issue and check if it’s still valid. Whether it’s open or closed doesn’t really matter too much.
“Buried in a landfill of actually fixed or irreproducible bugs” isn’t that different from “deleted” in real-world experience. It’s like saying that stuff that’s in the Wayback machine isn’t deleted when its internal support for searching archive stuff sucks.
The point isn’t “status” but discoverability.
‘Buried in a landfill of open issues’ isn’t that different from ‘buried in a landfill of closed issues’. If you see a neatly curated and triaged list of open issues, and your thought process is that ‘well, my issue should be in this open issue list’, then you are missing the point. How did the neatly curated and triaged list of open issues get to be that way, by accident? Or with careful management and application of automation tooling as appropriate?
I used to be very against stale bots until a project I started gained some traction.
At first, I was excited for every issue and PR, but as the number of users grew, so did the issues and PRs. Some of them there was just no way I could handle (for example, they only happen on macOS, and I have no way to afford a Mac). I left them open out of respect, but it definitely demoralized me to see issue numbers pile up.
After a certain amount of time, I just burnt out. I wasn’t checking issues or PRs, because I felt that if I replied to one, I should at least have the decency of looking at the others. I mean, these people took time out of their day to contribute to something I made, and I ignore their issue in favor of some other random one just because that’s the one that happened to be at the top of my GH notifications? So I just stopped looking at them, and they kept piling on and on to the point where it was completely unmanageable.
Thankfully I never had to resort to stale bots. Some dedicated users reached out and I made them maintainers, and they’re the ones taking (good!) care of the project now. I even moved it to the nix-community organization so it was clear it was no longer just “my” thing.
Still, I can definitely empathize with those who use stale bots. If I had that set up, I probably wouldn’t have burnt out so quickly. I know it might feel disrespectful to close the issue after some time, but I feel it’s even more disrespectful to just ignore everything completely due to the number of issues. (Similar thing happened recently with lodash, who closed every issue and PR by declaring issue bankruptcy)
More than anything, this highlights how incredibly underbaked GitHub Issues is as a bug tracking platform. There are any number of reasons that an issue may remain open; e.g., it has not yet been triaged, or it has been triaged and found to be low priority (e.g., if you aren’t actively supporting Mac users, perhaps any issue found on a Mac is low priority), or it’s frankly just not super important when compared to fixing critical defects and security issues. It should be possible to focus your attention on just the high priority, actionable issues, without being overwhelmed by the total open issue count.
It’s not unhealthy for a project to have a backlog of issues that may remain open indefinitely, reflecting the fact that those issues are lower in priority than the things you’re getting around to fixing. Closing issues really ought to be reserved for an active refusal to make a particular change, or if something that’s reported is not actually a bug.
I fully agree, it’s also definitely why I never closed any of those issues - I would love for them to get fixed! The first time I actually closed a contribution, it was a PR that contributed a ton of stuff, but it was just so disorganized (it really should have been split up into 15+ PRs) that it would take me weeks to get over all of it. Still, it took me over a month to own up to the fact that I was never going to be able to merge it in that state, and I felt horrible about it at the time. They took a ton of time to make a bunch of contributions to my project! And I just refused them. Still feel kind of sad I couldn’t find a better way to merge that. Long-term, though, it definitely improved my mental health (which was at an all-time-low at the time).
Thanks for sharing this, and I can understand the urge to close those issues, fix them and keep the number down. But I also learned to just live with it. Maybe some people will have to get into the same position first to understand why a maintainer spreads their attention so selective, but they will eventually. The other option is to just give up and then nothing progresses. I’ve had issues where I don’t have the hardware for or time, and eventually someone came around to work on it.
You did the right thing. The difficulty of reviewing a PR scales with something like O(lines^2) * overall complexity of the diff. And if someone is willing to put that much work into a PR, they should be willing to put in the extra time to make it possible to review. Otherwise I’d suspect they were any of several bad characters:
Why not mark the issues as “dormant”, with a short description of why it’s not feasible for the maintainer to address them (“I don’t have a Mac”)?
That still has the problem of “I need to go look through every issue” which can be challenging at times (burn-out, ADHD, simply too many issues…).
I think this might actually be one of the most reasonable uses of a stale bot - just mark it as “stale”, but don’t do anything else. That actually signals to the maintainers that these should probably get looked at!
I mean if the stale bot is closing issues without anyone looking at them, then it could be closing issues that are both important and easy to fix. Then any sense of being on top of things that you get from seeing fewer open issues would be false, and worse you are pissing off people who open issues that are closed for no good reason.
I don’t see the point. Couldn’t maintainers just sort open issues in chronological order of the most recent activity?
For your example. Wouldn’t it make sense to mark them as macOS and simply ignore them and only review something with code passing tests there?
I think it’s okay to have stuff you cannot work on and I think it’s wrong to assume that you get everything just because you write about it.
Maybe I am overly focusing on that example, but I don’t think this somehow gets solved by a stale bot and you didn’t use one for a reason.
I think that it makes sense to make clear what a user should expect. You can clarify that you won’t support a certain platform, you can clarify that you cannot support it, but accept patches. And you can certainly make clear if you don’t want to use your issue tracker to give support.
It’s fine, it’s not rude. Of course being on a non-supported platform can be a bummer and as someone who often uses more exotic things I hope that doesn’t happen and I am always happy when someone at least would welcome patches.
I think stale bots are rude for the reason you mention. If you have an open bug tracker and I contribute something sensible having a bot close it down doesn’t feel like the nicest thing. Of course there might be “I want this” and “How to do this” issues, especially on GitHub, and they tend to be closed, but that’s not what the stale bot does. It’s worse even, it kind of strengthens that attitude since people who write “I still want this”, “When is this done”, “This is important”, “Your project sucks without this”, etc. will prevent the issue from going stale.
Stale bots don’t seem to be a good solution here, since it feels like they do the opposite of what you want.
Do people feel accomplished when bots close issues for more often than not no reason at all?
And yes, the GitHub issue tracker is bad. People get creative though with templates. Maybe that’s a better way? Maybe another way would be using an external issue tracker.
I agree with what you’re saying, and the quality of issues/PRs improved significantly once I added some basic templates.
Still, while I don’t particularly like stale bots and wouldn’t put them on my projects, I just meant to say I get why people reach for them. Not that I particularly agree with bots who just close issues independent of triage status.
But yes, I think GitHub’s fairly simplistic issue tractor just makes the whole problem a lot worse. But I also think that a project would need to reach a certain scale before an external issue tracker is justified. I mean, I have no idea how I’d submit a bug report to Firefox. Some random library I found on GitHub though? Sure, just open an issue. There’s a lot of value in that.
Nothing worse than finding a bug in software, checking the issue tracker and finding the exact issue you’ve encountered has already been reported and closed by a stale bot.
This immediately gives me the impression the maintainers aren’t interested/ don’t have the time to solve the issue. I’m not going to spend the time to open a duplicate issue because it’ll likely just be closed again.
Bugs don’t just disappear because a GitHub bot closed the issue.
I get the impression maintainers have anxiety around the number of open issues and this reduces that anxiety by hiring the problem.
Why not comment on the stale issue?
Because the maintainers still won’t care.
Are you sure? Maintainers change. Hopefully the comment will raise awareness that someone new can reproduce, or will support a change. The comment will add signal, and counteract the signal of “stale”.
People have limited hours. Reading a new comment takes less commitment than choosing to close an issue.
Oftentimes, the stale bots also lock down the issues after a certain time, so people cannot write to the issue even if they wanted.
Issues are firstly a task list for maintainers and developers. They should be allowed to manage their task list however they like 🤷🏻
If the stale bot message isn’t polite enough (or gives the wrong impression) or if important bugs are never being addressed then those are separate problems that can be dealt with independent of stale bot policy.
I agree this is a valid (if uncommon) way to use issues, but in such a case one should not allow outsiders to make new ones and instead take feedback via some other mechanism.
Strongly agree. I think it would make sense on pull requests however, if the pull request had no activity for X days, and never achieved passing the tests, or was never marked as “ready for review”. Still, as a maintainer I prefer to close such pull requests manually. It’s not that much work after all, and sometimes I can make an exception to help the contributor get their patch landed even though it wasn’t fully ready.
I wonder if the situation would be better if Github didn’t show the open issue count by default.
Or had better filtering of issues by various signals such as combinations of labels or other maintainer added metadata.
As I read the article it occurred to me that none of the excuses given really let stale-bots off the hook. In every case, leaving issues unread and/or unhandled is IMO less rude than having a bot close them. It’s the difference between saying “I can’t get to this right now” and saying “Your contribution has no value to us now, and never will.”
“I haven’t had time to look at this” tells you “your contribution has no value”?
Sorry if I wasn’t clear. To clarify, leaving a PR unread says “I can’t get to this right now” but doesn’t make any judgement about the PR itself, and leaves open the possibility that the maintainer (or some future maintainer) will look at it. Having a bot close the PR says “this is worthless to us and we will never look at it.”
I assumed we’re talking about issues, not PRs, but I still disagree.
Bot closing the PR did not say “worthless”. It just said, “stale”. The PR (or an issue) going “stale” is almost literaly the function of the person “not having the time to do this right now”.
In certain cases, not responding to someone’s work can be worse. “Great, I opened a PR months ago and they’re ignoring me!” vs “I opened a PR, but since nobody had time for it, it got marked as stale.”.
I think the underlying issue is often people attributing things to events that are not necessarily there. Throughout the whole comment thread here on lobsters, people are expressing differing opinions. But look at the observable facts:
A thousand people will interpret it a thousand different ways. Should I report a bug if I find it? Am I allowed to ignore it? If I do report a bug, am I entitled an answer? Or at least a look? Or 5 minutes of that maintainer’s time? We just assume, since the project is public, that it is also a community project, and there is an obligation on the maintainer to maintain.
Personally I remember the “good” old times of BOFHs and every question you ask on mailing lists being answered with RTFM. I’m happy that it’s not like that any more - for most things that I need, I can probably ask a question, someone’ll answer me. But I’m still keeping that mindset of old ways of open source - if I have a problem, I am in charge of fixing it. And I’ll send the patch back to source, or perhaps a PR or a comment, but I don’t have expectations that anything will be done about it.
But I understand this isn’t how most people expect things to work.
Several times, including as I read this comments section, I have considered writing a bot that automatically keeps issues open for me in the most aggressive projects. It could have rules about this - e.g. maybe it would refuse to work if the stale configuration only kicked in when a label (like “needs info”) had been applied. Stuff like that.
It feels disrespectful to maintainers’ choices, even if I disagree with that choice, which is why I probably won’t do it. But man do stale bots feel disrespectful of my time too, and they also feel frankly like the result of a shoddy engineering mentality.
I think you’re not the target audience. You’ll open an issue, include details, send info, talk to devs. I’ve seen large open source projects having hundreds of issues, most of which are not issues but requests for help. The answers to which can be found in the docs, often.
The conflict here is that you think the issues serve you. And the developers think it’s for them, to plan their project.
Issues are often used both as “things to work on” as well as “bug reports”.
Separating these somehow would let the devs for the work, and reporters report.
Any project popular enough to have sufficient issues/PRs to overwhelm a solo maintainer, should stop having a solo maintainer. Stale bots are not a good substitute for either (a) learning to involve others and delegate, or (b) handing off the reins.
The response to the hypothetical complaint doesn’t really negate the issue raised. If the maintainer wants to run things their way, only write code, and not be bothered by issues/PRs, that’s fine. But they should publicly encourage a fork, redirect people towards it, and go back to their personal repo. This almost never happens. (Possibly because changing all the links/sites/artifacts/etc is hard. Or possibly because they still want to enjoy the cachet of helming a popular project without actually doing the things popular projects do.)
Instead, the open-source community has trended in this weird direction in the last few years, where they’ve stopped seeing open-source as a fundamentally collaborative endeavor. We’ve started adopting this toxic view of OSS as a one-way relationship, where creators have given you this wonderful gift, and users are now parasites instead of symbiotes. I dislike this attitude so much, and I’ve tried to make it a point to publicly thank all contributors to my projects in each release.
If you don’t want to run a popular project, just leave or hand it off. Nobody’s chained you to it.
If you do like running a popular project, well… maybe spare some gratitude for those who made it popular? Your users also contributed their time and energy. In addition to PRs/issues, they recommended it, answered newbie questions, gave talks, wrote documentation, published books, started cons, etc. They gave your project, and by extension you, many gifts of their own. That’s how gifting works in society.
Open source is about us collectively working together. If I contributed to it, at least in small part, it’s our project (even if weighted by contribution).
Just because someone put a project on github and added a license to it does not mean they have entered a social contract with anyone else beyond what they put in the license. They owe no one anything. They have not joined a community automatically nor have they automatically created a community. It’s frankly disrespectful to pretend that they did. It’s just as easy for a user to fork the project as it is for the original author do what you suggest.
It’s entitled and disrespectful to expect them to do so when they didn’t sign up for any community management in the first place. The real problem here is that the users are assuming intent on the part of the author and getting mad that they didn’t tell them the intent wasn’t proper to assume.
Maybe if they don’t go around assuming that intent in the first place they won’t get angry about it.
We’re not going to see eye to eye on this.
I’ll point out two things though.
First, you may not like existing in society, but you’re still expected to adhere to social norms, and this applies to OSS too. (For now.) I view this the same I way view people trying to get out of tipping in the US. Being a good participant means stepping aside if/when the time comes. “Entitled and disrespectful” applies equally to the view that maintainers owe nothing reciprocally to those who have helped them.
Second, “It’s just as easy for a user to fork the project as it is for the original author do what you suggest” is incorrect. Forking a repo may be easy, but moving a whole project and it’s ecosystem is not. Historically, it rarely happens. If it were easy, the maintainer wouldn’t be bombarded, because the fork would displace the original pretty quickly.
The “social norms” in question arise from hosting on GitHub. FLOSS projects preceded that by quite a bit. If you tried being a Karen on an old-style mailing list, you’d get harshly directed to the FAQ, or banned from the project.
In fact, if more maintainers were made aware of that by hosting on GH they’d have to yield to the demands of every user with an account and some free time, more people would decide to host elsewhere.
That’s an interesting point. I do use github, but really only for interacting with projects other people have decided to host there. (I’m not antisocial enough to complain about that… If I value a project enough to contribute, I’ll use whatever platform the maintainers choose, within reason.) In part because of the social dynamic github gamifies and encourages, though, for stuff I want to share myself, I default to sr.ht. I’d rather pay a small fee than make people think I’ve signed up for some of the more toxic expectations I’ve observed there.
(It’s not just social. I do like the tooling there a little better too. But funneling interactions to an old style mailing list with all the social norms that entails, plus being easier to set up for a new project than either github or gitlab makes it an easy default for me. If I were concerned about “stars” or some near equivalent, my math might be different.)
This isn’t that simple.
I have a ton of projects on github. Most of them have no users, but they’re there if you want them, for whatever reason.
For some weird reason, one of those projects took off, and all of a sudden I went from not really having to care about them other than adding the stuff I felt necessary to spending 1-2 hours every night managing the “community” aspect, fixing issues and checking PRs.
So all of a sudden this fairly large amount of work fell on me when I never really signed up for that. I don’t want to put a “no contributions” banner on my projects - they’re incredibly appreciated, I want contributions! But at the same time, I’m not particularly ready to manage 3 to 4 issues/PRs of varying quality per day. Especially when I leave for a month and come back to a massive backlog. I might’ve taken a break, but the users sure didn’t. There’s no real way to combat that. Not to mention, I have ADHD (unmedicated at the time), which just made the task of going through all of that so much more daunting.
So what do I do? “Hand it off” is easy to say, but I had to find someone to hand it off to. I had the luck of having people reach out wanting to take care of that, and they’ve done a phenomenal job, but not everyone has that luck. That’s why people reach for stale bots. There’s just not enough maintainers to go around, and “issue bankruptcy” is a real problem. Sure it’s rude to close people’s issues without checking them, but it’s even worse to just let the project die due to maintainer burn-out. Stale bots prevent that, at least somewhat.
I also have unmedicated ADHD and the pandemic led to me essentially dropping everything on the floor even worse than usual. However, out of respect for reporters, I would never use a stale bot.
If the reports pile up, they pile up. Recently, I’ve started to pick up the pieces and, for things that a human (me) judges to be stale, I close them with a polite, custom-to-the bug variation on “Sorry I let this languish for so long. I tried to replicate it based on the information you gave me, but couldn’t. Feel free to reopen the bug if it’s still a problem.” (And, as for the feature requests, I’ve been adding more metadata.)
I maintain a couple projects that have 3.5k stars between them, but luckily, they’ve been around a while and are pretty stable, so the issue list isn’t overwhelming.
Part of what works for me is, when someone submits an issue, I usually say “This looks like a good issue. Submit a PR?” Most won’t, but some do, and now I have a couple collaborators with commit access, and more one-time committers I can tap if need be.
I feel like the response post here is arguing something of a different point from the original post. The original says “stale bots are a bad solution to your problems. Here are other solutions that will work better.” The thesis of the response seems to be “don’t be mean to overworked developers who are managing a popular open source project. They don’t owe you anything.” Which, like, okay, sure. But that’s not what the original post was saying.
Looking through these comments, the discussion has shifted to talking about how much project owners owe their users, which isn’t what the post was about. It would indeed be bad to drive someone into taking down their open source project by harassing them for using a stale bot, but what does that have to do with anything? The bottom of nostalebots.xyz lists some projects that have stale bots, like Ruby on Rails, k3s and Flutter. These are not small projects. They’re not run by a single, inexperienced, overworked developer. Stale bots are used by large repositories run by billion dollar companies who could absolutely spare the resources to properly manage issues.
“Don’t bully someone for using this thing when they’re in a tight spot and don’t know any better” or “people who give you free code don’t owe you anything” are fully general counterarguments that distract from the original point. Imagine someone posts “why you should write your project in Zig instead of using punch cards” and a response comes along which spins a tale of some starry eyed repo owner who didn’t know better being berated for using punch cards because all they have access to is an IBM 1401 from 1962. That would indeed be bad, but it’s irrelevant.
Some of these comments (like mine) were for another, semi-related article, whose comments were merged into this one.
I had no idea lobste.rs mods could do that. If it seems confusing, it’s because we were discussing a blog post on the same topic, but saying the exact opposite.
This is very usual within discussion sites like this. People skim an article (or in other places, just read the headline - this never happens here! /s) and cherry-pick what to take from it.
I found the tone of the original submission abrasive and overly generalizing, which the response post picked up on.
One way to keep issues from accumulating without progress is to prevent issues from being created unless they are accompanied by a working patch that fixes the issue.
This is true, but it’s also incredibly hostile to your community. Any good engineer knows the value of a clearly described bug report.
I would say the only way to make this work without being a jerk is to make it clear that the project is for you, not other people, and you just happen to have released the source code. And if that’s not true you probably shouldn’t be using this policy.
Open Source developers voluntarily give away years of the precious few they have on earth in the form of functional software. Most of the time they are building tools for other developers to use. It’s the peak of entitlement, if not outright abuse, to insinuate they are jerks or being hostile for requiring comparatively little effort in return to acquire more of their free time. Not to mention, the point of requiring a patch is to keep the issue tracker and the project as a whole healthy in the long run.
Open Source developers are not faceless corporations, nor do they have any obligation to anyone. Their code is provided WITHOUT ANY WARRANTY.
It’s hostile and passive-aggressive to have an open issue tracker, which implies you’ll triage what people put into it, and not post any notices to the contrary, and then just ignore people until they give up and go away, leaving them to play ping-pong with a robot.
If you have an open source project, an open issue tracker it’s asking for contributions in form of issues. If then someone give away years of the precious few they have on earth in the form of well researched and documented bug reports and you, the person who essentially asks for it has a bot use up the contributors time by playing a weird game asking to spam that issue with more messages then that’s somehow more okay?
The open source developer owes me nothing, but if they ask for input (bug reports, patches, etc.) and don’t even look at it and waste contributors’ time (both the ones reporting and the ones looking for others having the issue) that’s just rude. It’s completely fine to say no you don’t want that, or that you don’t have time, or that you find the idea dumb. It’s your project. But you also wouldn’t have someone travel to your place to give you something for free and then have a sign up saying “try again tomorrow, maybe I’d receive your gift tomorrow, but maybe not”.
Why can the issue not stay open, if it’s still an open issue? If that would be clarified somehow that’s maybe clear, but if there’s just some software saying “stale”, closing the issue I will be disgruntled on wasting my time on someone/some project. If I want to sort out old tickets somehow, wouldn’t I just check the last updated time? If you don’t want issues, why not close it? If you don’t like something, why not clarify it?
So what I am saying is just as it’s not okay to waste a maintainer’s time it’s also not okay to waste a contributor’s time. They are both spending time on open source, potentially also both writing code for a project.
And yes, it depends on the context. A lot actually. But if it’s a project with many commiters, looking like contributions are welcome, if I analyze and document a bug, write a patch, write tests and a bot comes along and closes it with a nothing saying message that’s simply not wasting other people’s time and rude as such.
If you’d prefer no issues reported that’s about as easy to clarify as setting up the stale bot.
Both you and the sibling commenter are responding to an argument I did not make so I cannot meaningfully respond to you. This specific thread nowhere has a defense of stale bots.
[Comment removed by author]
Void does use a stale bot. Unless something is assigned to a maintainer, or is actively being worked, it inflates our counts of issues with weird one-offs that nobody including the reporter cares to diagnose. This hides active issues, or issues we consider important. The stale bot also serves as a reminder to maintainers to consider merges that were e.g. stalled waiting for feedback.
Our numbers being bad is demotivating. We don’t want to bulk-close issues, but “stale-ness” is a useful metric for what should dominate maintainer’s free time. Meanwhile it doesn’t delete the work, so it can be revived should it prove important (a quick search will pull up such issues/PRs).
I do not believe we “lock” issues or PRs after they are closed for being stale. We do not wish to silence people, simply to put things about which nobody cares out of mind.
Why don’t you close these “weird one-offs” manually?
Again, maintainer attention. Free time is limited.
Becae clicking one button takes so much time?
Don’t be obtuse. It’s reading the issues and coming to a (possibly consensus) decision that takes time, attention, and motivation.
Ignoring the issue is also a decision.
The problem is you have to ignore it every time you review open issues. And every time you spend a bit of time on that. Even if it’s only a second, such issues pile up and the total time lost accumulates.
If you want to solve it, then it’s good to be reminded about it. If you don’t want to solve it, then close it.
What if I don’t want to solve it but I’m on a team. Maybe someone else will solve it. Or, if nobody shows any interest in 3 months, it falls off
That shows a lack of communication within the team. You should have a unified vision of what you want your project to look like, which determines whether an issue is relevant.
Why do you think that using a stale bot means there is a lack of communication?
Not knowing whether a bug report is relevant for your project shows a lack of communication.
Yes, you said that. I’m asking why do you think it. Does it show a lack of communication, or lack of time on behalf of the maintainer?
I agree that getting an issue automatically closed off as stale sucks. Like getting a canned reply from a job application - couldn’t they at least tell you why they didn’t hire you?
The alternative discussed here is ignoring the user. Like, the issue stands there forever open. To me, it looks like nobody cares. To me, that is the lack of communication. Like applying to a job and never getting anything back. Neither of these are good to me, because they give me nothing personal. But in one case, I’m ignored, in another, I at least got some closure and know my thing is not important any more to anyone. I can either give up hope, or try to reopen or something.
But I understand that this is my own perspective. That is why I am asking, why do you prefer getting ignored over getting the closure in the sense of “we never got around to your bug report. give up hope or take initiative.”
Of course, ignoring the issue altogether is not ideal, but I’d argue it’s still better than having a bot close it – at least other users who have the same problem can see that it has been reported and may be fixed at some point when the developers have more time. But you could make a tag saying something like “don’t have time to fix right now” and put it on such issues. That would also help the “open issues are cluttering my issues list” problem because you could just filter out this tag. And of course, if you know that you’ll never have time for fixing the issue, just close it (you can also make a tag for that).
Hmm. That’s may partially explain your “lack of communication” point of view to me. You would expect that someone would just never look at all the stale issues if the bot closes them, whereas if the maintainer does it manually, it is assumed they considered it.
I can understand that. But just as you argue that “it’s still better than having a bot close it”, I can also argue that sometimes the people have no time, or desire, or a habbit, to do this. Perhaps they do the triage, perhaps they don’t, some will simply find it better for them to have the bot “stale” the issue if it goes 3 months without activity.
But it’s not a perfect situation in any case. I just don’t think it’s a lack-of-communication problem, but rather lack-of-time or lack-of-resources problem. Or more often, “conscious choice on where to focus ones’ energy”. Not that I think it’s a better or worse way to do things, I just think it’s a valid choice.
To be clear, my comment on communication skills was just a response to you saying that when working in a team, you might not know whether an issue is relevant. It doesn’t apply in other situations.
No,I meant by that that you commented to someone else, that if nobody responds to an issue within 3 months, it gets autoclosed, shows a lack of communication within the team. That’s why I asked you think that using a stale bot means there is a lack of communication.
Personally I don’t think one way or another, I think these two points are not related. Whether or not a team uses a stale bot, and whether or not there’s a lack of communication are separate points, they don’t seem to be co-dependent to me (unless of course there’s a deeper reasoning).
Communication takes work.
Go look at the organization. We have a stale bot, but how recently was the last “closed for stale” issue? The stale bot is for times when nobody actually wants to do the work and the work might be in scope, if someone anywhere was able to prioritize it.
A ports tree/package repository is quite a bit different from general projects.
We have a lot of PRs from a lot of people for thousands of “sub-projects”.
Sometimes, sure. But if it is your default policy then it takes very little effort to ignore a new issue.
If you’re putting in the effort to properly triage the issue then, sure, it’s not much more effort to tag the issue up or leave a short comment, but triaging is work and leaving public comments is social risk: you may embarrass yourself by saying something wrong and/or may invite rude or tiring comments from people.
Related: I’m done with this thread. You haven’t been rude, but I am no longer interested in talking about it.
To anyone who doesn’t like stale bots–I highly recommend them to keep the issues open on their own issue trackers. That way, the bad old stale bot can’t close their issues!
Why would you have an issue tracker for someone else’s project?
Mostly so that you’re in control of it and not subject to the arbitrary policies of others.
If you don’t care enough to care about tracking the issue, why do you expect someone else to?
The point of issues is to inform the project maintainer about bugs. What good is an issue if the maintainer doesn’t see it?
To be charitable, I think the idea is that if you’re running a stale-bot, you don’t want to receive issues any more. But an open issue can be a good message board for people to share workarounds and hacks that “fixed it for me”, so the community needs some place to post those. Might as well do it in a different issue tracker.
That would be a forum, not an issue tracker.
OK, what happens when the maintainer sees it? Do they resolve the issue immediately? Within a month? Six months? A year? Are there any guarantees given? If the issue is not resolved, should it hang around the maintainer’s issue tracker indenfinitely? What if the maintainer wants a clean tracker with issues that they want to focus on only, without the headache of triaging a bunch of other issues they are not interested in? What if an issue that was filed some time ago becomes outdated or inaccurate because of changes in the software, and the person who filed it does not update it? Is the maintainer then responsible for periodically going through the list of issues and looking through each of them with a fine tooth comb for accuracy?
Basically, how much extra unpaid work would you like the maintainer to take on?
If the maintainer wants to fix the issue, they should leave it open. If not, they should close it. Simple as that.
Exactly. That’s exactly what a stale bot does.
No. A stale bot can’t read the maintainer’s mind.
But the stale bot works deterministically with the parameters it was given by the maintainer. It’s not randomly snatching issues out of the maintainer’s hands. It’s implementing the maintainer’s decision and policy.
Good idea. Maybe I should add a “Stale-botting wall of shame” to my website where I collect any bugs I reported that failed a “three strikes and you’re out” policy for having to tell the bot “No, It’s still relevant” without any sign a human has ever read the thing.
I’m sure maintainers of any projects you choose to contribute to will find that list interesting, but maybe not in the way you’re intending.
It wouldn’t be intended for the maintainers. It’d be intended in the same vein as https://gcemetery.co/ …a way to warn potential users before they get burned.
Heck, to make it a bit more objective, maybe I could tie it to some sort of quantitative measurement of how much user effort has been wasted, per project, posting “still a problem” keep-alive posts on bugs that were just ignored until people lost interest.
Raku handles this nicely, I asked if a certain thing should work a certain way, it was near instantly added to the specification, for implementations to align against at a later date.
Separating triage and implementation becomes really clean if you separate specification and implementation.
I dunno, that has problems as well. If the behaviour gets implemented then people will try it out and decide if they actually like it and agree with it (in the betas for the new release.or whatever). Actually having to implement stuff also means the implementer has to think about it more.
In response to the response: If you don’t want issues, why not close the issue tracker?
I feel like the response post here is arguing something of a different point from the original post. The original says “stale bots are a bad solution to your problems. Here are other solutions that will work better.” The thesis of the response seems to be “don’t be mean to overworked developers who are managing a popular open source project. They don’t owe you anything.” Which, like, okay, sure. But that’s not what the original post was saying.
Looking through these comments, the discussion has shifted to talking about how much project owners owe their users, which isn’t what the post was about. It would indeed be bad to drive someone into taking down their open source project by harassing them for using a stale bot, but what does that have to do with anything? The bottom of nostalebots.xyz lists some projects that have stale bots, like Ruby on Rails, k3s and Flutter. These are not small projects. They’re not run by a single, inexperienced, overworked developer. Stale bots are used by large repositories run by billion dollar companies who could absolutely spare the resources to properly manage issues.
“Don’t bully someone for using this thing when they’re in a tight spot and don’t know any better” or “people who give you free code don’t owe you anything” are fully general counterarguments that distract from the original point. Imagine someone posts “why you should write your project in Zig instead of using punch cards” and a response comes along which spins a tale of some starry eyed repo owner who didn’t know better being berated for using punch cards because all they have access to is an IBM 1401 from 1962. That would indeed be bad, but it’s irrelevant.
Two of the first things I do when reviewing an open source project for any kind of $WORK or production use are to look at recent commit activity, and look at issue tracking.
In terms of issue tracking, I want to see what types of issues are raised, how often, and how maintainers deal with them. Are they polite and helpful? Are issues resolved? Are devs willing to say “sorry, but this request doesn’t fit what we’re trying to do” where appropriate?
Personally, I would never mark a project down for using a stale bot. If it’s closing valid or active issues? Sure.
But if it’s closing down those issues where a maintainer has asked for more details and nobody has replied in two months? It’s saving time on issues that will never get fixed.
Like so many things, stale bots are a tool and used well, I think they’re a force for good.