Just Say No(jeffgeerling.com)
jeffgeerling.com
Just Say No
https://www.jeffgeerling.com/blog/2022/just-say-no
138 comments
I agree with grug, but grug was (mostly) talking about saying “no” to grug’s boss and business demands, not to users reporting issues.
> I also enabled the GitHub Stale Bot on most of my repos, and let me tell ya—for a lot of people that seems to be a hot-button topic.
and for good reason. Reasons not stated nor addressed in this article, which I find concerning.
> Despite how much some people detest the stale bot, it—along with a more easygoing attitude towards my projects—is the best burnout prevention measure I've personally taken.
That's great: individual mental-health is more important. But disabling issue creation on all of your repos would've had a similar effect on burnout prevention, with all of the same benefits as stalebot & less of the drawbacks (no false sense of contribution created with users, no bridges built to be burnt).
> I enabled the Stale Bot because it was an admission of this fact: Unless I specifically mark an issue as a bug or being 'planned' in my roadmap, it's just not that important to me.
That's great in theory, and Jeff being a prolific & conscientious engineer, may actually work reasonably ok in practice for him. But it doesn't work this way for the vast majority of projects. For most, enabling stalebot is a measure to stave off disorganisation within the project, in which case they're not marking issues in a roadmap in any kind of timely/efficient manner nor really organising their issue queues well at all (as Jeff states here that he already is). Most issues that stalebot closes haven't even been looked at by maintainers.
If you don't have the time to look at issues, ignore them. I do get that psychologically this is tricky as many chase a "Zero Inbox" type of approach to issue queue management, but take a look at any mature well-organised open source project and you'll see unaddressed issues that are years and years old.
Maybe someone could invent a bot that hides ignored issues from maintainers - better maintainer filters. But as a user, I want to find those open issues & read the workarounds. I want to submit PRs to address them without having to keep track of 16 different issues opened on the same persistent problem that keeps getting closed stale.
This tool might work for Jeff but if it does he's in a tiny minority & it's irresponsible to advocate its use for everyone without addressing the well-known criticisms at all.
and for good reason. Reasons not stated nor addressed in this article, which I find concerning.
> Despite how much some people detest the stale bot, it—along with a more easygoing attitude towards my projects—is the best burnout prevention measure I've personally taken.
That's great: individual mental-health is more important. But disabling issue creation on all of your repos would've had a similar effect on burnout prevention, with all of the same benefits as stalebot & less of the drawbacks (no false sense of contribution created with users, no bridges built to be burnt).
> I enabled the Stale Bot because it was an admission of this fact: Unless I specifically mark an issue as a bug or being 'planned' in my roadmap, it's just not that important to me.
That's great in theory, and Jeff being a prolific & conscientious engineer, may actually work reasonably ok in practice for him. But it doesn't work this way for the vast majority of projects. For most, enabling stalebot is a measure to stave off disorganisation within the project, in which case they're not marking issues in a roadmap in any kind of timely/efficient manner nor really organising their issue queues well at all (as Jeff states here that he already is). Most issues that stalebot closes haven't even been looked at by maintainers.
If you don't have the time to look at issues, ignore them. I do get that psychologically this is tricky as many chase a "Zero Inbox" type of approach to issue queue management, but take a look at any mature well-organised open source project and you'll see unaddressed issues that are years and years old.
Maybe someone could invent a bot that hides ignored issues from maintainers - better maintainer filters. But as a user, I want to find those open issues & read the workarounds. I want to submit PRs to address them without having to keep track of 16 different issues opened on the same persistent problem that keeps getting closed stale.
This tool might work for Jeff but if it does he's in a tiny minority & it's irresponsible to advocate its use for everyone without addressing the well-known criticisms at all.
This is exactly my issue with stalebot and I think it is a great disservice to the community. Closing issues without a maintainer looking at the issue is bad. I expect at least some triaging from the maintainer before the stalebot comes in and swipes the issue under the carpet.
Maintainers are great, and working open source projects are good, but not every project has an active maintainer, and it's my opinion that practically no one in Open Source signed up to be a "repo owner", unless they've gone to the trouble of developing some kind of governance structure to signal that they should be counted upon for support. That signal is an affirmative signal though, it's not implied.
If you don't get a reply, and a robot closed your inquiry without comment then my guy, it seems that the signal has been sent clearly and received! If you disagree the fork button is in the upper right hand corner, you are the maintainer now!
I don't mean this to be disrespectful, but there are a lot of open source projects supporting companies and the companies often don't contribute back in any way. So while I appreciate the PR, and I'm going to be as polite as possible before I close it, not everyone has time for that, and nobody owes it.
If you don't get a reply, and a robot closed your inquiry without comment then my guy, it seems that the signal has been sent clearly and received! If you disagree the fork button is in the upper right hand corner, you are the maintainer now!
I don't mean this to be disrespectful, but there are a lot of open source projects supporting companies and the companies often don't contribute back in any way. So while I appreciate the PR, and I'm going to be as polite as possible before I close it, not everyone has time for that, and nobody owes it.
I'm not the commenter, but I think you're misinterpreting the intent of the comment (or at the very least I interpreted it differently).
> I expect at least some triaging from the maintainer before the stalebot comes in
I didn't read this as "maintainers should always triage", I read this as "stalebot shouldn't axe issues unless maintainers are triaging" (see my original comment for why). One could reword the above comment for extra clarity/emphasis as:
> I expect that before stalebot comes in [it should check whether] some triaging from the maintainer has been done]
i.e. I don't think @bouke was shitting on maintainers, just on stale bot as a product.
Of course maintainers should be under no obligation to do anything whatsoever: none of that is particularly relevant here when we're just discussing whether stale bot adds value.
(I see Jeff has replied here too but also completely skipped over addressing criticisms of stale bot & focusing on the strawman of maintainer responsibility - which noone is debating)
> I expect at least some triaging from the maintainer before the stalebot comes in
I didn't read this as "maintainers should always triage", I read this as "stalebot shouldn't axe issues unless maintainers are triaging" (see my original comment for why). One could reword the above comment for extra clarity/emphasis as:
> I expect that before stalebot comes in [it should check whether] some triaging from the maintainer has been done]
i.e. I don't think @bouke was shitting on maintainers, just on stale bot as a product.
Of course maintainers should be under no obligation to do anything whatsoever: none of that is particularly relevant here when we're just discussing whether stale bot adds value.
(I see Jeff has replied here too but also completely skipped over addressing criticisms of stale bot & focusing on the strawman of maintainer responsibility - which noone is debating)
I avoid stalebot for the reason you describe, because I want a maintainer to be reading and triaging issues, and I am in a job description where I can reasonably anticipate to be that person at least 40% of the time, even if I may not be coming through often enough (with a high batting average.) I'm really lucky to work for a company that can prioritize this type of interaction!
But when maintainers are overextended or nobody is able to commit that way, I see the value of stalebot. I spent a year closing 400 issues by hand for a popular legacy tool that we were actively telling folks not to use, nearly already on the day I started working on it. They were all so grateful to have someone reading over their issue and for the community goodwill it created, it was definitely worth it – for me. Different value systems and judgements may not make it so valuable. To be as direct as possible, I have 0 information on whether any of those grateful people were ever converted into paying customers of our company (and I like it that way.)
Was it worth it in engineering dollars, or if you measured the output of the time spent reading each issue in terms of how it influenced directly on LOC output from my brain to my keyboard? Definitely not (at least not yet, short-term.) We kept the lights on, and the exit door illuminated, to demonstrate a commitment to support. In service of governance and long-term stability guarantees!
Would we have gotten people off the boat faster if we had gone ahead and decided to pre-emptively close every issue that was not likely to get attended to, based on engineering effort/$$ calculations with low information about each issue? Very much possible. Some people may have also gotten alarmed and decided to swim from there, rather than trust our lifeboats to take them somewhere safer. See how stalebot provides value in this case, if "abandon ship" is the message you want to send ;)
I may have made your (their) point even better for you, my point is simply different value judgements based on different calculus.
But when maintainers are overextended or nobody is able to commit that way, I see the value of stalebot. I spent a year closing 400 issues by hand for a popular legacy tool that we were actively telling folks not to use, nearly already on the day I started working on it. They were all so grateful to have someone reading over their issue and for the community goodwill it created, it was definitely worth it – for me. Different value systems and judgements may not make it so valuable. To be as direct as possible, I have 0 information on whether any of those grateful people were ever converted into paying customers of our company (and I like it that way.)
Was it worth it in engineering dollars, or if you measured the output of the time spent reading each issue in terms of how it influenced directly on LOC output from my brain to my keyboard? Definitely not (at least not yet, short-term.) We kept the lights on, and the exit door illuminated, to demonstrate a commitment to support. In service of governance and long-term stability guarantees!
Would we have gotten people off the boat faster if we had gone ahead and decided to pre-emptively close every issue that was not likely to get attended to, based on engineering effort/$$ calculations with low information about each issue? Very much possible. Some people may have also gotten alarmed and decided to swim from there, rather than trust our lifeboats to take them somewhere safer. See how stalebot provides value in this case, if "abandon ship" is the message you want to send ;)
I may have made your (their) point even better for you, my point is simply different value judgements based on different calculus.
> See how stalebot provides value in this case, if "abandon ship" is the message you want to send ;)
Yes, that's great. Stalebot provides value for a project you want to kill. That's not what people use it for mostly though. If that's its purpose call it killbot.
The point is not that stalebot is useless - I even said it sounds useful specifically for Jeff's use case. The point is that stale bot is actively harmful for the vast majority of uses in the wild: having a few rare cases of value doesn't change that.
Yes, that's great. Stalebot provides value for a project you want to kill. That's not what people use it for mostly though. If that's its purpose call it killbot.
The point is not that stalebot is useless - I even said it sounds useful specifically for Jeff's use case. The point is that stale bot is actively harmful for the vast majority of uses in the wild: having a few rare cases of value doesn't change that.
"actively harmful for the vast majority of use cases" but you've discounted the effect of burnout on maintainers, who are the vast minority of individuals.
This effect must not be understated, sustainability is a primary concern, as you'll see at the top of this thread, I started with "not every project has an active maintainer" - this is not always a state that arises in a perfect vacuum or even over a well-defined span of time, when an author loses interest in their creation and stops contributing to it. It is a terminal state in a state diagram with many open loops, and perhaps one to be avoided if you're keen on maintainers triaging issues! But also sometimes unavoidable.
If the active maintainers are all chased away by hungry users, clamoring for architectural changes without a full understanding of the project and how it's designed to work, then there is value in a bot chasing away the people who are just window shopping for something completely else than what you sold them, or even what else you had planned in your as-yet unexpressed vision for the future.
Spending the spoons required for an interaction is not without a compounding cost in all cases either. If your response is not simply accepted, or it's actually reiterating just what you already knew the user didn't want to hear, well... you've now entered the "bargaining" or "negotiating" phase of issue triage, and the next step is... well, another step
I negotiate with those users because they usually have valuable insights hidden inside of their pain! Our lead maintainers would spend time doing the same, but the more time they spend on that, the less time they have to spend on writing code and actually developing the software.
See how this model basically hinges on adding more people to the maintainers team as the user base scales up? And to the point, sacrificing some of their labor in service of triage role activities? If you are a single maintainer for many repos, you desperately need to avoid becoming a customer service bot for your non-paying customer-users. Spending time servicing those users can result in negative feedback loops where people expect more attention just because you gave it once. This has not been my experience most of the time, but...
...And that's not to say the issue queue won't be used for something else... but... maybe just your issue didn't make the cut. And that's not an affirmative value judgement – it just means maybe it did not make the cut for that maintainer's roadmap, who owns the queue, even if such person currently exists. Like I said, nobody signs up as "repo owner" when they publish their work, but it is their queue.
Suggesting that someone turn their issue queue off is a bit presumptive about the possible reasons why your issue was ignored, or why a bot is needed to help keep the issue queue clear enough to be able to easily find out "what's new."
It really might not actually be that they ignored your PR/report just because they want to kill the project? Maybe they really genuinely want the issue queue cleared so that important issues can be given faster attention when they are re-raised because they are important to someone subscribed.
If you've gone to all the trouble to track down 16 issues that provided details about the same report when they were all closed then you know it's possible, they aren't inaccessible just because they've been closed; it's just a bit frustrating – maybe also notice an important indicator of the volume over quality of the average issue submissions that 15 people didn't search well enough to find a closed issue that was a dupe of their issue! Did they even search before posting at all?
Anyway, if you're doing all that, then bottom line you should absolutely be a maintainer. Add yourself to the MAINTAINERS file and then go ahead and turn that stalebot off! ;)
This effect must not be understated, sustainability is a primary concern, as you'll see at the top of this thread, I started with "not every project has an active maintainer" - this is not always a state that arises in a perfect vacuum or even over a well-defined span of time, when an author loses interest in their creation and stops contributing to it. It is a terminal state in a state diagram with many open loops, and perhaps one to be avoided if you're keen on maintainers triaging issues! But also sometimes unavoidable.
If the active maintainers are all chased away by hungry users, clamoring for architectural changes without a full understanding of the project and how it's designed to work, then there is value in a bot chasing away the people who are just window shopping for something completely else than what you sold them, or even what else you had planned in your as-yet unexpressed vision for the future.
Spending the spoons required for an interaction is not without a compounding cost in all cases either. If your response is not simply accepted, or it's actually reiterating just what you already knew the user didn't want to hear, well... you've now entered the "bargaining" or "negotiating" phase of issue triage, and the next step is... well, another step
I negotiate with those users because they usually have valuable insights hidden inside of their pain! Our lead maintainers would spend time doing the same, but the more time they spend on that, the less time they have to spend on writing code and actually developing the software.
See how this model basically hinges on adding more people to the maintainers team as the user base scales up? And to the point, sacrificing some of their labor in service of triage role activities? If you are a single maintainer for many repos, you desperately need to avoid becoming a customer service bot for your non-paying customer-users. Spending time servicing those users can result in negative feedback loops where people expect more attention just because you gave it once. This has not been my experience most of the time, but...
...And that's not to say the issue queue won't be used for something else... but... maybe just your issue didn't make the cut. And that's not an affirmative value judgement – it just means maybe it did not make the cut for that maintainer's roadmap, who owns the queue, even if such person currently exists. Like I said, nobody signs up as "repo owner" when they publish their work, but it is their queue.
Suggesting that someone turn their issue queue off is a bit presumptive about the possible reasons why your issue was ignored, or why a bot is needed to help keep the issue queue clear enough to be able to easily find out "what's new."
It really might not actually be that they ignored your PR/report just because they want to kill the project? Maybe they really genuinely want the issue queue cleared so that important issues can be given faster attention when they are re-raised because they are important to someone subscribed.
If you've gone to all the trouble to track down 16 issues that provided details about the same report when they were all closed then you know it's possible, they aren't inaccessible just because they've been closed; it's just a bit frustrating – maybe also notice an important indicator of the volume over quality of the average issue submissions that 15 people didn't search well enough to find a closed issue that was a dupe of their issue! Did they even search before posting at all?
Anyway, if you're doing all that, then bottom line you should absolutely be a maintainer. Add yourself to the MAINTAINERS file and then go ahead and turn that stalebot off! ;)
> "actively harmful for the vast majority of use cases" but you've discounted the effect of burnout on maintainers, who are the vast minority of individuals.
No I haven't. I've stated very clearly: closing issue queues will solve for burnout & has less drawbacks than using stalebot. Ignoring open issues is also another very good approach (granted many maintainers find this difficult).
Also in terms of suggesting alternatives, from my original comment:
> Maybe someone could invent a bot that hides ignored issues from maintainers - better maintainer filters.
I'm not aware of a good tool for this, and it would be great if one existed. But the lack of it isn't a good justification for turning to stale bot imo - the trade-offs aren't worthwhile.
> Suggesting that someone turn their issue queue off is a bit presumptive about the possible reasons why your issue was ignored, or why a bot is needed to help keep the issue queue clear enough to be able to easily find out "what's new."
[...] Maybe they really genuinely want the issue queue cleared so that important issues can be given faster attention when they are re-raised because they are important to someone subscribed.
You're presuming that a maintainer knows that the issues being closed are "not important" & also that new issues are somehow more likely to be more important. Stale bot does not have the ability to ascertain the importance of issues - that's what triaging is for & most maintainers don't have the bandwidth to triage faster than stalebot closes. You are invariably closing important issues to make room for users to re-open already closed issues while completely losing context for everyone. That's dysfunctional and net lossy for your project. If you are, as a maintainer, genuinely trying to triage & respond to issues in this system, you're forcing users to generate a higher volume of issues for you & meanwhile losing out on context of previously opened copies of the same thing. It's a net loss of time & efficiency for a maintainer.
Yes it's unfortunate that the alternative is a binary: don't accept issues, or accept having a bunch of open ignored issues, but the only point I'm making here is that stale bot abjectly fails to solve for that gap. It provides no benefit to either of those binary states - it only makes one of them much worse (increases volume of issues while losing context) & additionally alienates reporters of issues. It's a lose lose lose solution for any maintainer that doesn't have bandwidth to triage everything on time (most people).
No I haven't. I've stated very clearly: closing issue queues will solve for burnout & has less drawbacks than using stalebot. Ignoring open issues is also another very good approach (granted many maintainers find this difficult).
Also in terms of suggesting alternatives, from my original comment:
> Maybe someone could invent a bot that hides ignored issues from maintainers - better maintainer filters.
I'm not aware of a good tool for this, and it would be great if one existed. But the lack of it isn't a good justification for turning to stale bot imo - the trade-offs aren't worthwhile.
> Suggesting that someone turn their issue queue off is a bit presumptive about the possible reasons why your issue was ignored, or why a bot is needed to help keep the issue queue clear enough to be able to easily find out "what's new."
[...] Maybe they really genuinely want the issue queue cleared so that important issues can be given faster attention when they are re-raised because they are important to someone subscribed.
You're presuming that a maintainer knows that the issues being closed are "not important" & also that new issues are somehow more likely to be more important. Stale bot does not have the ability to ascertain the importance of issues - that's what triaging is for & most maintainers don't have the bandwidth to triage faster than stalebot closes. You are invariably closing important issues to make room for users to re-open already closed issues while completely losing context for everyone. That's dysfunctional and net lossy for your project. If you are, as a maintainer, genuinely trying to triage & respond to issues in this system, you're forcing users to generate a higher volume of issues for you & meanwhile losing out on context of previously opened copies of the same thing. It's a net loss of time & efficiency for a maintainer.
Yes it's unfortunate that the alternative is a binary: don't accept issues, or accept having a bunch of open ignored issues, but the only point I'm making here is that stale bot abjectly fails to solve for that gap. It provides no benefit to either of those binary states - it only makes one of them much worse (increases volume of issues while losing context) & additionally alienates reporters of issues. It's a lose lose lose solution for any maintainer that doesn't have bandwidth to triage everything on time (most people).
> Yes it's unfortunate that the alternative is a binary: don't accept issues, or accept having a bunch of open ignored issues,
My whole argument here is the fact that "is there an active maintainer or not" is a continuum, not a binary decision. Any friction we can remove to having an active maintainer remain active, or a new maintainer joining up and becoming active, is a potential boon, drawbacks aside. Stalebot simply removes this friction in the form of "an endless queue of unanswered open issues which you must commit to tackle first." It isn't boundless anymore, only persistent issues will remain open.
If you've ever tackled re-opening a project that has slipped into an unmaintained state for a while you know what I'm talking about. The likelihood that there is anything actionable in an open issue from the distant past actually does decrease as it ages in calendar days and staleness since the last reply. Somebody hanging around waiting for a solution can and likely does take action to ensure their important issue remains open, if it was really important.
Even responding to a stale issue from over a year ago can be a job hazard, as people whose issue was never solved grow more frustrated and irritated about having their problem "bumped" without actually getting solved. It's like poking a bear, maintainers don't want to do it unless they have developed a thick skin of their own, and even then it's not usually a pleasant experience unless you happen to have come with the solution they were asking for in your back pocket.
I would argue that use of stalebot does not increase the volume of issues, even indirectly – the blame goes squarely on users who do not search for their issue before filing a new one. Those users are not irredeemable, but it requires an affirmative commitment to deal with them, and you simply can't decide whether anyone makes that commitment (to spend time dealing with those users) or not. They (the hypothetical maintainer) don't even owe an answer about whether they do.
People begging you to clearly mark your hobby project as unmaintained is another form of social pressure which sometimes pushes people to not publish their work in the future, and that's a shame. You could instead ask if there's a chance that support contracts are going to be sold in the future, but instead you basically "negged" on someone that did something cool for free.
We also wrote a variation on this idea into our governance, because people were asking a lot of questions in Slack that were already addressed by open issues or discussions:
> Bearing in mind that Issues and Discussions are more permanent and searchable than Slack conversations, we can avoid unduly expending finite community resources by searching before asking. If you are not exactly sure how to ask your question or otherwise daunted by the idea of permanence, visitors are always welcome in #project on the (BigCo) Slack.
So...
> Stale bot does not have the ability to ascertain the importance of issues - that's what triaging is for & most maintainers don't have the bandwidth to triage faster than stalebot closes. You are invariably closing important issues to make room for users to re-open already closed issues while completely losing context for everyone. That's dysfunctional and net lossy for your project. If you are, as a maintainer, genuinely trying to triage & respond to issues in this system, you're forcing users to generate a higher volume of issues for you & meanwhile losing out on context of previously opened copies of the same thing. It's a net loss of time & efficiency for a maintainer.
"How many users have filed the same issue" is also a signal you can record and observe, or redirect to the circular file.
It's only a net loss of time and efficiency for that maintainer if they do tangibly exist as a person, and they actually spend that time. This is very much like arguing that technical debt is all wasted time. First, it isn't a waste of time if you haven't spent the time and never do. It's a net gain, "time saved" – until that debt comes back to bite you in the ass. "And that's never a foregone conclusion until it happens, then it was always inevitable that it would."
> most maintainers don't have the bandwidth to triage faster than stalebot closes
This is absolutely true. A problem we can only solve well by having more active maintainers, or less interested users.
https://www.youtube.com/watch?v=LVe0g91yZ84
I think the root of our disagreement centers around whether a large mass of users who believe some issue is important shall dictate whether the issue is actually important or not within any given context.
If users keep opening the same issue after it's been closed before many times, by a bot or not, then there is obviously some disconnect. Users do not get to decide which way the train drives, the person who does the work is the only one who gets to decide (and the person that merges their PR, I guess)
My whole argument here is the fact that "is there an active maintainer or not" is a continuum, not a binary decision. Any friction we can remove to having an active maintainer remain active, or a new maintainer joining up and becoming active, is a potential boon, drawbacks aside. Stalebot simply removes this friction in the form of "an endless queue of unanswered open issues which you must commit to tackle first." It isn't boundless anymore, only persistent issues will remain open.
If you've ever tackled re-opening a project that has slipped into an unmaintained state for a while you know what I'm talking about. The likelihood that there is anything actionable in an open issue from the distant past actually does decrease as it ages in calendar days and staleness since the last reply. Somebody hanging around waiting for a solution can and likely does take action to ensure their important issue remains open, if it was really important.
Even responding to a stale issue from over a year ago can be a job hazard, as people whose issue was never solved grow more frustrated and irritated about having their problem "bumped" without actually getting solved. It's like poking a bear, maintainers don't want to do it unless they have developed a thick skin of their own, and even then it's not usually a pleasant experience unless you happen to have come with the solution they were asking for in your back pocket.
I would argue that use of stalebot does not increase the volume of issues, even indirectly – the blame goes squarely on users who do not search for their issue before filing a new one. Those users are not irredeemable, but it requires an affirmative commitment to deal with them, and you simply can't decide whether anyone makes that commitment (to spend time dealing with those users) or not. They (the hypothetical maintainer) don't even owe an answer about whether they do.
People begging you to clearly mark your hobby project as unmaintained is another form of social pressure which sometimes pushes people to not publish their work in the future, and that's a shame. You could instead ask if there's a chance that support contracts are going to be sold in the future, but instead you basically "negged" on someone that did something cool for free.
We also wrote a variation on this idea into our governance, because people were asking a lot of questions in Slack that were already addressed by open issues or discussions:
> Bearing in mind that Issues and Discussions are more permanent and searchable than Slack conversations, we can avoid unduly expending finite community resources by searching before asking. If you are not exactly sure how to ask your question or otherwise daunted by the idea of permanence, visitors are always welcome in #project on the (BigCo) Slack.
So...
> Stale bot does not have the ability to ascertain the importance of issues - that's what triaging is for & most maintainers don't have the bandwidth to triage faster than stalebot closes. You are invariably closing important issues to make room for users to re-open already closed issues while completely losing context for everyone. That's dysfunctional and net lossy for your project. If you are, as a maintainer, genuinely trying to triage & respond to issues in this system, you're forcing users to generate a higher volume of issues for you & meanwhile losing out on context of previously opened copies of the same thing. It's a net loss of time & efficiency for a maintainer.
"How many users have filed the same issue" is also a signal you can record and observe, or redirect to the circular file.
It's only a net loss of time and efficiency for that maintainer if they do tangibly exist as a person, and they actually spend that time. This is very much like arguing that technical debt is all wasted time. First, it isn't a waste of time if you haven't spent the time and never do. It's a net gain, "time saved" – until that debt comes back to bite you in the ass. "And that's never a foregone conclusion until it happens, then it was always inevitable that it would."
> most maintainers don't have the bandwidth to triage faster than stalebot closes
This is absolutely true. A problem we can only solve well by having more active maintainers, or less interested users.
https://www.youtube.com/watch?v=LVe0g91yZ84
I think the root of our disagreement centers around whether a large mass of users who believe some issue is important shall dictate whether the issue is actually important or not within any given context.
If users keep opening the same issue after it's been closed before many times, by a bot or not, then there is obviously some disconnect. Users do not get to decide which way the train drives, the person who does the work is the only one who gets to decide (and the person that merges their PR, I guess)
This, basically. And for probably 80% of issues, a maintainer might actually read the notification, but to click through, leave some sort of intelligent / honest reply, and either click close or reply and move on takes infinitely more time (when you're dealing with 100+ new issues and PRs a day) than not responding and moving to the next one.
A non-response does signal one thing—the maintainer doesn't seem interested enough to touch the issue. Fork the project or maintain a patch separately if you need to, and move on.
A non-response does signal one thing—the maintainer doesn't seem interested enough to touch the issue. Fork the project or maintain a patch separately if you need to, and move on.
I'm part of an ongoing issue with Signal where it eats up and refuses to ever free 10+ GB of storage space on my iPhones. The Stale bot closing an issue after multiple people immediately responding, "no this is still an issue" is infuriating.
I know it's hard, but if a Signal community dev said, "we hear you, this is bad, but unfortunately we're just not able to look at it right now." I'd be disappointed, but satisfied. Bonus points if they share a bit of "why". But hiding from or ignoring a problem is the worst answer.
I know it's hard, but if a Signal community dev said, "we hear you, this is bad, but unfortunately we're just not able to look at it right now." I'd be disappointed, but satisfied. Bonus points if they share a bit of "why". But hiding from or ignoring a problem is the worst answer.
Learning to say "no" is a super power. It also takes a lot of tact, and that can include redirection. Instead of telling somebody what isn't possible, I like to tell them what is possible and reset their expectations. My "No" sounds a lot like a "yes" that they get to execute themselves.
"Hey, can you do XYZ for me, I really need it."
"Oh, are you trying to solve ABC? There's an article I found that shows how to solve ABC without even having to do XYZ- can I send it to you?"
"Sure!"
Now I'm on the hook to DM/email a link, but not do XYZ. Solved. Does it work for every situation? You guessed it.
No.
"Hey, can you do XYZ for me, I really need it."
"Oh, are you trying to solve ABC? There's an article I found that shows how to solve ABC without even having to do XYZ- can I send it to you?"
"Sure!"
Now I'm on the hook to DM/email a link, but not do XYZ. Solved. Does it work for every situation? You guessed it.
No.
As a teacher, I like to start with "No". Then, in the next paragraph, I explain why, come with alternatives, etc. This way I clearly and unambiguously communicate the answer, but I also try to be helpful.
Over the years I learned that doing this the other way around, thus starting by being helpful and then saying no, resulted in people seeing wiggle room and started to negotiated with me.
Over the years I learned that doing this the other way around, thus starting by being helpful and then saying no, resulted in people seeing wiggle room and started to negotiated with me.
And for anything that's not the work you are contracted for
"My consulting rate is $XXX/hour"
"My consulting rate is $XXX/hour"
In Japan saying a definite no is kind of taboo and rather impolite. They'll say it's difficult, invoking lack of time etc.
https://cotoacademy.com/how-to-say-no-in-japanese/
https://cotoacademy.com/how-to-say-no-in-japanese/
I disagree. One aspect of "tact" is that it's not always necessary.
I agree. Once my former CTO (and now friend) got to know each other, we had a common vision of what needed to be accomplished and sometimes bumped heads about the best way to do it (in hindsight he was right about 60% of the time). I was leading the “cloud native” initiatives.
We had no time for “shit sandwiches”. I would just as often tell him that “you know in your heart that’s a dumb idea” and he would often tell me “I don’t have time for this shit can you just get to the point”. He was very technical. But focused on strategy.
Of course this only happened behind closed doors and we would go to lunch afterwards.
We got a lot done. Because of his mentorship on how to navigate politics and talk to and present to CxOs, I went from not knowing “cloud” in 2018 to working in the loud consulting department two years later.
On his end, the company had sn exit for 10x revenue about six months after I left. It was a small company with only 3 million in revenue.
We had no time for “shit sandwiches”. I would just as often tell him that “you know in your heart that’s a dumb idea” and he would often tell me “I don’t have time for this shit can you just get to the point”. He was very technical. But focused on strategy.
Of course this only happened behind closed doors and we would go to lunch afterwards.
We got a lot done. Because of his mentorship on how to navigate politics and talk to and present to CxOs, I went from not knowing “cloud” in 2018 to working in the loud consulting department two years later.
On his end, the company had sn exit for 10x revenue about six months after I left. It was a small company with only 3 million in revenue.
Two heads are always better than one.
"Does it work for every situation? You guessed it.
No."
I agree that tact is not always appropriate. Sometimes the only way to get the point across is to be point blank with the answer.
"Can you do XYZ"
"Nope, not in a million years."
Does it work for every situation? You guessed it.
No.
No."
I agree that tact is not always appropriate. Sometimes the only way to get the point across is to be point blank with the answer.
"Can you do XYZ"
"Nope, not in a million years."
Does it work for every situation? You guessed it.
No.
Big fan of everything Jeff has put out over the years, having found him back in the day by way of his large catalog of Ansible materials.
One request: please dont advocate for stale bot :( I understand the tension between maintainers sanity and developers sanity, but there has to be a better way. It is absolutely _maddening_ as the consumer to interact with a stale-bot enabled repository. Please, just manually close the issues as 'wontfix' and link to this blog post instead.
One request: please dont advocate for stale bot :( I understand the tension between maintainers sanity and developers sanity, but there has to be a better way. It is absolutely _maddening_ as the consumer to interact with a stale-bot enabled repository. Please, just manually close the issues as 'wontfix' and link to this blog post instead.
Worse, stalebot makes it looks like the project has no issues nor known problems. Issues should be closed either with "wontfix" or let open if they detail a real bug that others may stumble upon. In the end, I agree that it takes time to do that, and who am I to dictate how people spend their time.
Maybe the best solution would be to completly disable issues and PRs on Github. Still better than having to deal with stalebot. At least you know what to expect: external solicitation is not welcomed.
Maybe the best solution would be to completly disable issues and PRs on Github. Still better than having to deal with stalebot. At least you know what to expect: external solicitation is not welcomed.
Eh, as a burnt-out maintainer I have to say I can understand the use of stalebot and don't begrudge people using it at all.
When I started my project, I had the attitude that I'd be better than all these other maintainers. They flaked out but I'm just that much better that I'd never let the project wither.
But over time the backlog of things you're just not going to get to, or don't have enough information but you don't have time or motivation to go through composing a reply, begins to cause a genuine psychic pain. To the point you can't even open the repository because it's a reminder of all the ways you're failing.
So I think it's good advice that maintainers should use stalebot, because the alternative is a dead project.
Sure, it sucks that the issue you put time and effort into gets memory-holed but you're owed nothing for the time, as TFA says, fork it.
Edit: Even manually closing as wontfix is that much more work, you're asking for every issue in the backlog the maintainer does the emotional work of deciding that the issue is unsalvageable from their perspective and takes a manual action that will potentially get people mad at them and now they have to deal with being flamed. Closed issues are still searchable and preserved in the issue backlog, they don't disappear forever.
When I started my project, I had the attitude that I'd be better than all these other maintainers. They flaked out but I'm just that much better that I'd never let the project wither.
But over time the backlog of things you're just not going to get to, or don't have enough information but you don't have time or motivation to go through composing a reply, begins to cause a genuine psychic pain. To the point you can't even open the repository because it's a reminder of all the ways you're failing.
So I think it's good advice that maintainers should use stalebot, because the alternative is a dead project.
Sure, it sucks that the issue you put time and effort into gets memory-holed but you're owed nothing for the time, as TFA says, fork it.
Edit: Even manually closing as wontfix is that much more work, you're asking for every issue in the backlog the maintainer does the emotional work of deciding that the issue is unsalvageable from their perspective and takes a manual action that will potentially get people mad at them and now they have to deal with being flamed. Closed issues are still searchable and preserved in the issue backlog, they don't disappear forever.
> So I think it's good advice that maintainers should use stalebot, because the alternative is a dead project.
This doesn't follow at all for me. What stalebot causes is a project that superficially seems to be in great shape, having only a smaller number of fairly recent bugs open.
Whereas in reality it's a project with tons of known bugs that just get sweeped under the proverbial rug to make the bug list appear deceivingly clean. The passage of time doesn't make a bug go away, it's still a bug in the project.
The conflict arises because a bug database serves multiple purposes. Yes, it's a To-Do list for engineering. In that context, not everything can be done now so it might be understandable to close them. But the same can be achieved by lowering the priority which puts it at the bottom of the To-Do list.
But the other purpose of a bug db, a more important one, is that it is the repository of knowledge of all known problems with the project. It allows consumers of the project to understand what isn't working and to see where the quality trend is going over time. Yes, this could also be achieved with a document on Known Issues explaining the problems and ideally the reason they don't get fixed. But a project that's closing bugs automatically with a bot I bet isn't putting the effort into such documentation either.
I never close any bugs due to time. If they accumulate, so be it. It's a honest representation of the state of the project to would-be users. Eventually I get to it, might be many years later, but the bug was still there. When I close the bug intentionally it's because it's no longer an issue.
This doesn't follow at all for me. What stalebot causes is a project that superficially seems to be in great shape, having only a smaller number of fairly recent bugs open.
Whereas in reality it's a project with tons of known bugs that just get sweeped under the proverbial rug to make the bug list appear deceivingly clean. The passage of time doesn't make a bug go away, it's still a bug in the project.
The conflict arises because a bug database serves multiple purposes. Yes, it's a To-Do list for engineering. In that context, not everything can be done now so it might be understandable to close them. But the same can be achieved by lowering the priority which puts it at the bottom of the To-Do list.
But the other purpose of a bug db, a more important one, is that it is the repository of knowledge of all known problems with the project. It allows consumers of the project to understand what isn't working and to see where the quality trend is going over time. Yes, this could also be achieved with a document on Known Issues explaining the problems and ideally the reason they don't get fixed. But a project that's closing bugs automatically with a bot I bet isn't putting the effort into such documentation either.
I never close any bugs due to time. If they accumulate, so be it. It's a honest representation of the state of the project to would-be users. Eventually I get to it, might be many years later, but the bug was still there. When I close the bug intentionally it's because it's no longer an issue.
Maybe (most likely) this is a problem of GitHub's terminology. For genuine bugs, e.g. here's the repro, the stack trace, the code to replicate it, it happens 100% of the time if you follow these steps, I'd agree that just having it open and in the backlog would be preferable.
The problem is those make up maybe at a generous estimate, 10-15% of issues in a projects backlog. In the interests of full disclosure here's mine (I don't use stalebot) https://github.com/UglyToad/PdfPig/issues?page=1&q=is%3Aissu.... As you can see from the backlog I close almost nothing. This was a deliberate choice to avoid closing things until the fix was confirmed by the reporter.
But equally that's the first time I've opened the repository in a couple of months and the amount of angst and dread I feel just from the size of that list means I'll probably find yet another excuse not to do anything on it this coming month.
Discussions on this topic feel a lot like "technical solutions to social problems"; by which I mean "well in the ideal world a perfectly logical person would do x, y, z so the system should reflect that". And while a stalebot is the archetypal technical solution to a social problem it at least works with how maintainers work. Sometimes in life you want to ignore a problem and have it go away. When you can't do that, e.g. government bureaucracy, work stuff, social obligations, that's where stress comes from. And asking volunteer maintainers to add a whole new source of stress in their life falls apart when people get busy, or their life circumstances change, or they get ill or tired or whatever.
Yes, in a perfect world the issue backlog would be sacrosanct and perfectly groomed/prioritized. But we're just fleshy sacks of chemicals and we're not perfect. Unrealistic expectations from users are the cause of maintainer burnout.
Because GitHub closed issues are still viewable and searchable (I'd guess most people search it through a search engine not the terrible inbuilt search) I'd disagree that they're deceiving users somehow.
The problem is those make up maybe at a generous estimate, 10-15% of issues in a projects backlog. In the interests of full disclosure here's mine (I don't use stalebot) https://github.com/UglyToad/PdfPig/issues?page=1&q=is%3Aissu.... As you can see from the backlog I close almost nothing. This was a deliberate choice to avoid closing things until the fix was confirmed by the reporter.
But equally that's the first time I've opened the repository in a couple of months and the amount of angst and dread I feel just from the size of that list means I'll probably find yet another excuse not to do anything on it this coming month.
Discussions on this topic feel a lot like "technical solutions to social problems"; by which I mean "well in the ideal world a perfectly logical person would do x, y, z so the system should reflect that". And while a stalebot is the archetypal technical solution to a social problem it at least works with how maintainers work. Sometimes in life you want to ignore a problem and have it go away. When you can't do that, e.g. government bureaucracy, work stuff, social obligations, that's where stress comes from. And asking volunteer maintainers to add a whole new source of stress in their life falls apart when people get busy, or their life circumstances change, or they get ill or tired or whatever.
Yes, in a perfect world the issue backlog would be sacrosanct and perfectly groomed/prioritized. But we're just fleshy sacks of chemicals and we're not perfect. Unrealistic expectations from users are the cause of maintainer burnout.
Because GitHub closed issues are still viewable and searchable (I'd guess most people search it through a search engine not the terrible inbuilt search) I'd disagree that they're deceiving users somehow.
> So I think it's good advice that maintainers should use stalebot, because the alternative is a dead project.
Why not just close issue tracker? Or autoclose everything immediately rather than remind people weeks/months later about their bug, just to discover that they got "pranked"?
Or let issues pile up? Or have separate garbage dump issue tracker? Done by https://github.com/gorhill/uBlock
Why not just close issue tracker? Or autoclose everything immediately rather than remind people weeks/months later about their bug, just to discover that they got "pranked"?
Or let issues pile up? Or have separate garbage dump issue tracker? Done by https://github.com/gorhill/uBlock
1. Because some issues are still valuable, a well presented bug report that you can immediately act on and is related to parts of the project you want to enhance improves the project.
2. As above, you want to work on some of the valuable issues of interest to you as a maintainer, but if you glance at one and think "that looks like a lot of work" or "that's an x-y problem" or "I'd need to go back and forth 5 times to get enough information to action that" then you can just ignore it and have the bot close it if you never get the motivation, time or energy to go back to it.
3. As I mentioned in my comment, having an ever growing backlog has a genuine detrimental emotional impact that directly causes maintainer burnout.
4. That would just move the problem.
2. As above, you want to work on some of the valuable issues of interest to you as a maintainer, but if you glance at one and think "that looks like a lot of work" or "that's an x-y problem" or "I'd need to go back and forth 5 times to get enough information to action that" then you can just ignore it and have the bot close it if you never get the motivation, time or energy to go back to it.
3. As I mentioned in my comment, having an ever growing backlog has a genuine detrimental emotional impact that directly causes maintainer burnout.
4. That would just move the problem.
I think ultimately a lot of that maintainer-consternation is a failure to 1) decide if the project is a 'project' which is meant to be built and maintained by people over time or 2) a source-available reference for others which is actually just meant for personal use. They want the PR and cred of having a popular open-source thing, but dont actually do anything other than putting the source online in terms of fostering it.
I understand this, and I too put my stuff online a lot of times just to build up my street cred, but if thats the only purpose then you need to make that clear in your communication and how you manage the project. If you _are_ intending the thing to grow and be used you need to do that intentionally. The two biggest offenders for that tend to be 1) not moving to an organization account and 2) not fostering contributors to lessen the individual load. Again, because the project is actually a personal project not intended to be touched by others (but hey if you would use it and star it that would be great because then its even better PR for me!).
So yes, I understand its a tough spot but in many ways I view it as self-inflicted and think communication (both explicit and implicit) goes a long, _long_ way toward setting expectations.
I understand this, and I too put my stuff online a lot of times just to build up my street cred, but if thats the only purpose then you need to make that clear in your communication and how you manage the project. If you _are_ intending the thing to grow and be used you need to do that intentionally. The two biggest offenders for that tend to be 1) not moving to an organization account and 2) not fostering contributors to lessen the individual load. Again, because the project is actually a personal project not intended to be touched by others (but hey if you would use it and star it that would be great because then its even better PR for me!).
So yes, I understand its a tough spot but in many ways I view it as self-inflicted and think communication (both explicit and implicit) goes a long, _long_ way toward setting expectations.
Stalebot is someone wishing to tell "go away, you are not wanted here" but not having enough honesty to do it openly.
It is fine to disable issue tracker if you do not want people to file issues.
It is fine to reject feature requests.
But stale-bot is the most annoying way of doing this.
It is fine to disable issue tracker if you do not want people to file issues.
It is fine to reject feature requests.
But stale-bot is the most annoying way of doing this.
It think it'd be OK to use the stalebot if you're more up-front about it's use and why it's being used. A maintainer should be able to make it known up-front "I don't have a lot of time, so I probably won't get around to reading this issue. And I use stalebot which will close issues I'll never get around to dealing with."
Maybe you could provide that information in the GitHub issue template.
That said, this would be a more ideal situation. I understand that open source maintainers are not under any responsibility to be helpful to contributors... but the world would be better off if they were.
Maybe you could provide that information in the GitHub issue template.
That said, this would be a more ideal situation. I understand that open source maintainers are not under any responsibility to be helpful to contributors... but the world would be better off if they were.
I would rather a project that does not respond to issues be honest about it and just leave the issues open. Closing them automatically just to make the number on the tab look nice is the digital equivalent of sweeping dust under the rug.
I prefer https://github.com/gorhill/uBlock/issues solution where issue creation is simply blocked
In this case users directed to garbage dump issue tracker but it also can be skipped.
Main problem with stalebot is wasting time on proper issue which is then closed without ever being read by human.
Maybe compare it to place offering users to fill poll or write feedback form? And then dumping them straight into paper shredder?
Maybe simply do not encourage users to fill feedback forms if you will shred all of them anyway?
In this case users directed to garbage dump issue tracker but it also can be skipped.
Main problem with stalebot is wasting time on proper issue which is then closed without ever being read by human.
Maybe compare it to place offering users to fill poll or write feedback form? And then dumping them straight into paper shredder?
Maybe simply do not encourage users to fill feedback forms if you will shred all of them anyway?
> it'd be OK to use the stalebot if you're more up-front about it's use and why it's being used
I would be probably OK if that would be clearly stated in CONTRIBUTING.MD file (and/or in pinned issue or other place seen by issue reporter who bothered to do minimal research).
I would be probably OK if that would be clearly stated in CONTRIBUTING.MD file (and/or in pinned issue or other place seen by issue reporter who bothered to do minimal research).
Yeah, stale bot is just an awful experience. I would rather not be able to create issues at all.
It's even more frustrating as a basic user scouring web search for the error message you just got and coming across nothing but Github issues that have been going in circles for years with the only engagement being stalebot warning the issue is about to close if no one comments and then someone else commenting "keep open" without any indication whether the developers even read the issue, think it's a real bug or user error, ever plan to do anything about it, care at all, are still even working on the project.
The only reasonable stale-bot policy for me is when a maintainer asks for more information and the issue creator stops responding.
Agreed. Specially for small and medium activity repos.
I would rather be ignored for months than have my Issue closed. Also, issues can help and be helped by others facing similar problems.
I would rather be ignored for months than have my Issue closed. Also, issues can help and be helped by others facing similar problems.
When running into problems with a project, you can search closed issues too. It's not the default, but it's easy. Maybe there could be a project option to include open and stalebot closed issues.
Yes, that "not the default" behavior is probably half my problem. I cant count how many days I've lost to trying to track down an issue in a project (trying to be a good citizen!), and then ultimately finding that the issue was already reported but closed by stale bot.
I don't like stale bot either, but it does a useful job --- closing issues the repository owner isn't going to fix with less effort and usually less drama for the owner.
If you take an affirmative action to close a bug, that's an opportunity for the reporter to argue. If stale bot does it, you can argue with stale bot, and stale bot doesn't care. Reopening it because it's still broken and you still care is a signal of some sort.
If you take an affirmative action to close a bug, that's an opportunity for the reporter to argue. If stale bot does it, you can argue with stale bot, and stale bot doesn't care. Reopening it because it's still broken and you still care is a signal of some sort.
You can give people permission to triage and close issues.
This presumes a thoughtful and deliberate approach, where all decisions and other actions related to bug management come from a place of wisdom and care, but that filters out pretty much any project that's using GitHub Issues to track bugs.
The kind of thought that goes into choosing GitHub for projects' bugtrackers is about the same level of thought that went into the decisions of anyone who was using Internet Explorer 10 years ago: they didn't think about it a lot, nor did they particularly care—they just picked it because it was there.
The kind of thought that goes into choosing GitHub for projects' bugtrackers is about the same level of thought that went into the decisions of anyone who was using Internet Explorer 10 years ago: they didn't think about it a lot, nor did they particularly care—they just picked it because it was there.
not always, GitHub issue tracker is actually my favourite one and I used multiple ones
Sure, but that's more work. Managing people is work. Coordinating about the project is more work. At the end, that person is still on the hook to close issues that aren't going to be worked on, but maybe they want to check first, or maybe they get drawn into an argument about the issue.
In such case letting issues pile up or closing issue tracker altogether is fine if owner is not interested in processing issues.
stalebot achieves the same effect, and irritates all people interacting with it
stalebot achieves the same effect, and irritates all people interacting with it
> In such case letting issues pile up or closing issue tracker altogether is fine if owner is not interested in processing issues.
That's so black-and-white. Perhaps the owner is interested in processing issues, but not all of them. That seems to be the more common case. Closing the issue tracker would not be useful. And letting issues pile up can be stressful for a maintainer.
> stalebot achieves the same effect
No it doesn't. It allows a maintainer to avoid having to manage issues that they probably won't get to, while allowing them to manage the issues they are actively working on, or plan to work on.
and irritates all people interacting with it
Tough shit. Random people on the internet are not entitled to any particular level of support, or issue resolution policy from the maintainer.
That's so black-and-white. Perhaps the owner is interested in processing issues, but not all of them. That seems to be the more common case. Closing the issue tracker would not be useful. And letting issues pile up can be stressful for a maintainer.
> stalebot achieves the same effect
No it doesn't. It allows a maintainer to avoid having to manage issues that they probably won't get to, while allowing them to manage the issues they are actively working on, or plan to work on.
and irritates all people interacting with it
Tough shit. Random people on the internet are not entitled to any particular level of support, or issue resolution policy from the maintainer.
> Tough shit. Random people on the internet are not entitled to any particular level of support, or issue resolution policy from the maintainer.
Oh, definitely. I am not a God-Emperor of issue tracking.
And projects adding stale-bot are unlikely to actually need my support/issues/donations/anything else.
Though I hope that projects will find other less hostile solutions.
Oh, definitely. I am not a God-Emperor of issue tracking.
And projects adding stale-bot are unlikely to actually need my support/issues/donations/anything else.
Though I hope that projects will find other less hostile solutions.
Stale issues should be verified against an up-to-date version of the software. If enough time has passed since the issue was first reported and nobody even bothers to check, that's proof enough of the issue being de facto stale and it does no good to engage in denial of this reality.
A lot of people have stale bot set to 1 month or less. Very few open source projects moves fast enough for 1 month to make any difference in replicability.
Minor releases may well be issued monthly, and even a minor release might independently fix a reported issue. Additionally, parent poster was not merely complaining about issues being closed too hastily; she was against stalebot as a matter of principle and clearly said so.
Isn't stalebot just a way of saying no at scale?
Like if nobody resolved the issue in the past x months then they're probably not going to resolve it in the future either so close it to remove noise.
Like if nobody resolved the issue in the past x months then they're probably not going to resolve it in the future either so close it to remove noise.
No, stalebot is a way to saying "I don't give a damn that you have spent an hour preparing a great bug report lured by the availability of 'New issue' button at the repository" at scale.
[deleted]
[deleted]
No.
You are asking for extra manual labor that the bot was meant to handle.
You are asking for extra manual labor that the bot was meant to handle.
I'm usually the first to jump in to fight entitlement in open source, but stale bot is, as used, a terrible experience for even the most conscientious would-be contributor. I can't count the number of times that I've been digging around for a solution to a problem and found a GitHub issue that was closed by stale bot with no reply whatsoever.
Leaving the issue open until someone has a chance to actually look at it isn't extra manual work, its common courtesy from a project that is soliciting feedback. If you're not interested in feedback, don't let people waste their time creating issues in the first place.
If stale bot would by default only close an issue if the last reply was from a maintainer, that would be a different matter.
Leaving the issue open until someone has a chance to actually look at it isn't extra manual work, its common courtesy from a project that is soliciting feedback. If you're not interested in feedback, don't let people waste their time creating issues in the first place.
If stale bot would by default only close an issue if the last reply was from a maintainer, that would be a different matter.
> don't let people waste their time creating issues in the first place
But then you don't get to use issues to track things that you personally care about. It would be nice if there were a way to enable issue creation by the repo owner / maintainers, but disallow it for the public at large. Especially now that "discussions" are a thing, which gives a place for people to comment without implicitly requesting work from the maintainer.
Apparently this is sort of possible[1] by setting `blank_issues_enabled: false`, so that you can only create issues from the Project page.
[1]: https://github.com/dear-github/dear-github/issues/293#issuec...
But then you don't get to use issues to track things that you personally care about. It would be nice if there were a way to enable issue creation by the repo owner / maintainers, but disallow it for the public at large. Especially now that "discussions" are a thing, which gives a place for people to comment without implicitly requesting work from the maintainer.
Apparently this is sort of possible[1] by setting `blank_issues_enabled: false`, so that you can only create issues from the Project page.
[1]: https://github.com/dear-github/dear-github/issues/293#issuec...
Maintainers doing literally nothing and simply ignoring issues entirely is a better experience than using stale bot.
For you.
For them, having all those issues closed helps filtering the clutter. Or whatever reason they have for running it, maybe it's the only way that they can still maintain some desire to work on the project and not abandon it. A small price to pay then I guess.
For them, having all those issues closed helps filtering the clutter. Or whatever reason they have for running it, maybe it's the only way that they can still maintain some desire to work on the project and not abandon it. A small price to pay then I guess.
I need to read through this more thoroughly, but upon a first read, I feel I pretty strongly disagree with the approach and advice but not necessarily the sentiment.
This is mainly coming from a user of open source projects who is both trying to contribute more and start projects where I'd be the maintainer. As a user, I can't think of anything more frustrating to spend hours or even days on an issue on an open source project that "welcomes" issues and contributions and then creating a detailed GitHub Issue only for it to be responded with with author's "No" and immediately closed. Just because the maintainers do not have time to fix the issue does not mean it isn't an issue! Too many times has this happened. It just means that users get a false sense of the tool's maintainability, reliability, etc. by looking at a "clean" issue listing only to find out that tons of issues still exist. How many times have you found an issue only to find several issues have already been reported, not fixed, but closed due to automated bots or maintainers just blindly closing? The issue still exists, but now its history is spread across a half dozen issue reports. This complicates what the issue actually is and contributions for it.
The response to an issue of "contributions are welcome" or "you can fork it" are inappropriate because the filing of an issue is not a request to fix. It is an issue reporting mechanism. But too often, maintainers become chippy about reported issues.
On another note, many maintainers will report how much of an open source developer they are on their resume or talks they give, when in reality their open source projects are just that, open source. They are often just open sourced personal fiefdoms. Which is honestly fine, if they are marketed as such, but they rarely are so.
As I think about possibly open sourcing a personal project or two, I am thinking deeply about this. I think it's much better for expectations that if an open source project is going to be dictated by the maintainer, it should be explicitly stated so as to set expectations. Even then, I would not blindly close actual issues that are reported.
Saying no is fine but please be honest and upfront on a repository's README. If someone says "this is open source but it's mainly a personal project and/or library and I will aggressively close issues", then that does wonders to set expectations. And I think that's the key idea. Setting expectations, upfront, is the key to effective communication.
This is mainly coming from a user of open source projects who is both trying to contribute more and start projects where I'd be the maintainer. As a user, I can't think of anything more frustrating to spend hours or even days on an issue on an open source project that "welcomes" issues and contributions and then creating a detailed GitHub Issue only for it to be responded with with author's "No" and immediately closed. Just because the maintainers do not have time to fix the issue does not mean it isn't an issue! Too many times has this happened. It just means that users get a false sense of the tool's maintainability, reliability, etc. by looking at a "clean" issue listing only to find out that tons of issues still exist. How many times have you found an issue only to find several issues have already been reported, not fixed, but closed due to automated bots or maintainers just blindly closing? The issue still exists, but now its history is spread across a half dozen issue reports. This complicates what the issue actually is and contributions for it.
The response to an issue of "contributions are welcome" or "you can fork it" are inappropriate because the filing of an issue is not a request to fix. It is an issue reporting mechanism. But too often, maintainers become chippy about reported issues.
On another note, many maintainers will report how much of an open source developer they are on their resume or talks they give, when in reality their open source projects are just that, open source. They are often just open sourced personal fiefdoms. Which is honestly fine, if they are marketed as such, but they rarely are so.
As I think about possibly open sourcing a personal project or two, I am thinking deeply about this. I think it's much better for expectations that if an open source project is going to be dictated by the maintainer, it should be explicitly stated so as to set expectations. Even then, I would not blindly close actual issues that are reported.
Saying no is fine but please be honest and upfront on a repository's README. If someone says "this is open source but it's mainly a personal project and/or library and I will aggressively close issues", then that does wonders to set expectations. And I think that's the key idea. Setting expectations, upfront, is the key to effective communication.
I don’t find anything wrong with the authors approach. I just think he should make it clear that he’s not interested in issues or PRs on the project readme or contribution guide. It’s hard to have it both ways - where you say issues and PRs are welcome but say no when someone reports or makes a contribution.
I agree that making it clear is important, and I think I edited my post at the same time as your comment to say the same.
However, I think I still disagree with closing issues, particularly with a bot, even if expectations are set. On GitHub, I think labeling the issue is more appropriate. Labeling it as "maintainer-wont-fix-contributions-welcome" with a detailed "I will only accept a PR if these conditions are met" in the README is much better than just swatting away things by closing and saying "won't fix" or "this is not a bug". If PRs and issues truly will be ignored, then that really needs to be explicitly stated. Because otherwise, why even open source or release it? I have seen quite a few presentations with "I maintain all these projects" instead of the truth of "I open sourced all of these personal projects". There is a difference.
However, I think I still disagree with closing issues, particularly with a bot, even if expectations are set. On GitHub, I think labeling the issue is more appropriate. Labeling it as "maintainer-wont-fix-contributions-welcome" with a detailed "I will only accept a PR if these conditions are met" in the README is much better than just swatting away things by closing and saying "won't fix" or "this is not a bug". If PRs and issues truly will be ignored, then that really needs to be explicitly stated. Because otherwise, why even open source or release it? I have seen quite a few presentations with "I maintain all these projects" instead of the truth of "I open sourced all of these personal projects". There is a difference.
> If PRs and issues truly will be ignored, then that really needs to be explicitly stated.
No it doesnt. No one owes anything to you
> Because otherwise, why even open source or release it?
Because they can.
No it doesnt. No one owes anything to you
> Because otherwise, why even open source or release it?
Because they can.
Society generally disagrees that unclear or unresponsive communication is welcomed. If someone speaks to me, I believe giving and them expecting a respectful response is not entitlement on their part.
> Because they can.
That's not really an answer to basically any question. Yes, a person can do anything, but actions also have consequences. Also, frustration is a legitimate emotion for anyone. It's okay for someone to be frustrated and admit so in a respectful manner. Being frustrated does not make one an evil or entitled person by default.
Lastly, there are different approaches and perspectives, which is also fine. For open source development, there is no one true approach that everyone is going to agree with. But I do think clear communication will reduce a lot of friction no matter the approach.
I once came across a project where the maintainer clearly stated that they will never adjust the license. Is it frustrating? Yes. Do I disagree? Yes. But it's their choice, and they clearly stated it. So I grunt to myself and move on.
> Because they can.
That's not really an answer to basically any question. Yes, a person can do anything, but actions also have consequences. Also, frustration is a legitimate emotion for anyone. It's okay for someone to be frustrated and admit so in a respectful manner. Being frustrated does not make one an evil or entitled person by default.
Lastly, there are different approaches and perspectives, which is also fine. For open source development, there is no one true approach that everyone is going to agree with. But I do think clear communication will reduce a lot of friction no matter the approach.
I once came across a project where the maintainer clearly stated that they will never adjust the license. Is it frustrating? Yes. Do I disagree? Yes. But it's their choice, and they clearly stated it. So I grunt to myself and move on.
> Society generally disagrees that unclear or unresponsive communication is welcomed. If someone speaks to me, I believe giving and them expecting a respectful response is not entitlement on their part.
That only works because meatspace limits the number of people who can impinge on your time.
That's not true for Github. Any maintainer is heavily outnumbered by the number of people who can file issues against their project.
I blame the fact that we centralized bug reporting. Back when everybody had to create an account on a different Bugzilla, there was enough friction that you had to want to file that bug report very badly--especially if there was a 24 hour waiting period to sign up. That kept the ratio under control so the maintainers weren't too outnumbered.
(Side note: I suspect there is also some level of "Filing bug reports on Github is a corporate metric" somewhere also creating extra static.)
That only works because meatspace limits the number of people who can impinge on your time.
That's not true for Github. Any maintainer is heavily outnumbered by the number of people who can file issues against their project.
I blame the fact that we centralized bug reporting. Back when everybody had to create an account on a different Bugzilla, there was enough friction that you had to want to file that bug report very badly--especially if there was a 24 hour waiting period to sign up. That kept the ratio under control so the maintainers weren't too outnumbered.
(Side note: I suspect there is also some level of "Filing bug reports on Github is a corporate metric" somewhere also creating extra static.)
The amount of people who read through a README is probably in the single digit percentage of users who post issues (judging by the fact that so many issues have their resolution in part of the README).
The number of people (especially those who post issues, not PRs necessarily) who read a contribution guide is probably less than 1%.
GitHub issue templates can help in that regard, but it's still pretty minimal the amount of work 80% of people who post issues will put in towards solving it themselves first.
The number of people (especially those who post issues, not PRs necessarily) who read a contribution guide is probably less than 1%.
GitHub issue templates can help in that regard, but it's still pretty minimal the amount of work 80% of people who post issues will put in towards solving it themselves first.
Normally if the README contains the restrictions on contribution and PRs right at the top I think it should catch everyone’s attention (well, hopefully…).
IMHO, the ideal solution is for GitHub to allow restrictions on issues and PRs for public repositories. You could always make the repo private though. I don’t think there is a restriction on private repo’s right now in GitHub.
IMHO, the ideal solution is for GitHub to allow restrictions on issues and PRs for public repositories. You could always make the repo private though. I don’t think there is a restriction on private repo’s right now in GitHub.
> because the filing of an issue is not a request to fix
Great phrase, this summarizes the point very well!
Exactly. A bug report is just that, a report. It increases the knowledge base of what problems exist in the project so that everyone can know.
It doesn't mean it has to be fixed. Not everything can always be done. So if it remains open, it's simply documentation of a problem that still exists. Closing it because some time passed is dishonest, if the problem still exists.
Great phrase, this summarizes the point very well!
Exactly. A bug report is just that, a report. It increases the knowledge base of what problems exist in the project so that everyone can know.
It doesn't mean it has to be fixed. Not everything can always be done. So if it remains open, it's simply documentation of a problem that still exists. Closing it because some time passed is dishonest, if the problem still exists.
> As a user, I can't think of anything more frustrating to spend hours or even days on an issue on an open source project that "welcomes" issues and contributions and then creating a detailed GitHub Issue only for it to be responded with with author's "No" and immediately closed.
Is it a bug report? In that case I agree that it is irritating.
Is it a feature request? Then your mistake is to spend days on crafting feature request. I prefer to make simple feature request and spend more effort if it is provisionally accepted.
> It just means that users get a false sense of the tool's maintainability, reliability, etc. by looking at a "clean" issue listing only to find out that tons of issues still exist.
I look also at recently closed ones - if stalebot is present then I escape immediately.
> The response to an issue of "contributions are welcome" or "you can fork it" are inappropriate
that is entirely appropriate response, maintainers are not obligated to fix bugs (unless they are under some support contract).
> On another note, many maintainers will report how much of an open source developer they are on their resume or talks they give, when in reality their open source projects are just that, open source.
what is the problem here?
Is it a bug report? In that case I agree that it is irritating.
Is it a feature request? Then your mistake is to spend days on crafting feature request. I prefer to make simple feature request and spend more effort if it is provisionally accepted.
> It just means that users get a false sense of the tool's maintainability, reliability, etc. by looking at a "clean" issue listing only to find out that tons of issues still exist.
I look also at recently closed ones - if stalebot is present then I escape immediately.
> The response to an issue of "contributions are welcome" or "you can fork it" are inappropriate
that is entirely appropriate response, maintainers are not obligated to fix bugs (unless they are under some support contract).
> On another note, many maintainers will report how much of an open source developer they are on their resume or talks they give, when in reality their open source projects are just that, open source.
what is the problem here?
> > On another note, many maintainers will report how much of an open source developer they are on their resume or talks they give, when in reality their open source projects are just that, open source.
> what is the problem here?
My personal issue with it is that it is misleading. I feel there is a difference between "I am the maintainer for these open source projects" and "I open sourced these personal projects" if one doesn't really maintain, in a community sense, the projects. It's akin to resume padding.
> what is the problem here?
My personal issue with it is that it is misleading. I feel there is a difference between "I am the maintainer for these open source projects" and "I open sourced these personal projects" if one doesn't really maintain, in a community sense, the projects. It's akin to resume padding.
Whether they are actually maintaining or just "padding" is quickly revealed by visiting the repositories of the developer who claims so, or? I can also claim on my resume that I am a world famous actor, but my mostly blank IMDb page will quickly tell another story.
OK, if someone abandons open source project and claims to be developing it then I see a problem.
(though open sourcing project and not accepting PRs or even issues is fine, if it is actually maintained)
(though open sourcing project and not accepting PRs or even issues is fine, if it is actually maintained)
Agreed. I think this just revolves around clear communication and expectation setting. Just too often it is all too implicit and ad-hoc, where frustration easily brews on both sides.
It's like wet towels and mildew. Lol. Don't wet them if you're not going to dry them or hang them up. (Disclaimer: I didn't heavily think through this analogy.)
It's like wet towels and mildew. Lol. Don't wet them if you're not going to dry them or hang them up. (Disclaimer: I didn't heavily think through this analogy.)
> As a user, I can't think of anything more frustrating to spend hours or even days on an issue on an open source project that "welcomes" issues and contributions and then creating a detailed GitHub Issue only for it to be responded with with author's "No" and immediately closed.
The article also discusses that. Of course there are better ways to do this than just closing it wihtout comment, even though the end result is still saying "no" to it.
I have open-sourced a library that I wrote for an in-production app at work, and it got a little too popular for me to handle like most open source "consumers" (even though they don't pay me) expect.
Every time there's a feature/pull request, I not only have to think about if the code is correct, but also if it would introduce breaking changes in the way it is used in that production app.
It's very mentally draining to visit the issues page of that repository, because it's full of people needing help or wanting to contribute work. But I can't handle them all within an acceptable timespan.
Every few months I take half an hour to clean up there, and then the issues list is already filled with disgruntled users.
> The response to an issue of "contributions are welcome" or "you can fork it" are inappropriate because the filing of an issue is not a request to fix. It is an issue reporting mechanism. But too often, maintainers become chippy about reported issues.
I agree in hindsight that it probably would've been better to just turn off the pull requests feature when creating a repository if you can't commit yourself to the potential workload it creates.
> Saying no is fine but please be honest and upfront on a repository's README. If someone says "this is open source but it's mainly a personal project and/or library and I will aggressively close issues", then that does wonders to set expectations. And I think that's the key idea. Setting expectations, upfront, is the key to effective communication.
Most of the time you don't realize that you really can't handle all that workload when you're still in the "honeymoon" phase of the thing you're open-sourcing. What are you supposed to do when it gets to the point where it's just overwhelming you to even look at the issues list?
The article also discusses that. Of course there are better ways to do this than just closing it wihtout comment, even though the end result is still saying "no" to it.
I have open-sourced a library that I wrote for an in-production app at work, and it got a little too popular for me to handle like most open source "consumers" (even though they don't pay me) expect.
Every time there's a feature/pull request, I not only have to think about if the code is correct, but also if it would introduce breaking changes in the way it is used in that production app.
It's very mentally draining to visit the issues page of that repository, because it's full of people needing help or wanting to contribute work. But I can't handle them all within an acceptable timespan.
Every few months I take half an hour to clean up there, and then the issues list is already filled with disgruntled users.
> The response to an issue of "contributions are welcome" or "you can fork it" are inappropriate because the filing of an issue is not a request to fix. It is an issue reporting mechanism. But too often, maintainers become chippy about reported issues.
I agree in hindsight that it probably would've been better to just turn off the pull requests feature when creating a repository if you can't commit yourself to the potential workload it creates.
> Saying no is fine but please be honest and upfront on a repository's README. If someone says "this is open source but it's mainly a personal project and/or library and I will aggressively close issues", then that does wonders to set expectations. And I think that's the key idea. Setting expectations, upfront, is the key to effective communication.
Most of the time you don't realize that you really can't handle all that workload when you're still in the "honeymoon" phase of the thing you're open-sourcing. What are you supposed to do when it gets to the point where it's just overwhelming you to even look at the issues list?
> > As a user, I can't think of anything more frustrating to spend hours or even days on an issue on an open source project that "welcomes" issues and contributions and then creating a detailed GitHub Issue only for it to be responded with with author's "No" and immediately closed.
> The article also discusses that
They mention that but they don't really discuss it, and I disagree with the conclusion and advice.
GitHub allows disabling issues altogether. Just do that snd save everyone trouble.
> What are you supposed to do when it gets to the point where it's just overwhelming you to even look at the issues list?
My thoughts are my overall opinion and approach: clear communication. Just update the README, appropriately comment on issues that are closed as a result, and maybe even disable issues.
> The article also discusses that
They mention that but they don't really discuss it, and I disagree with the conclusion and advice.
GitHub allows disabling issues altogether. Just do that snd save everyone trouble.
> What are you supposed to do when it gets to the point where it's just overwhelming you to even look at the issues list?
My thoughts are my overall opinion and approach: clear communication. Just update the README, appropriately comment on issues that are closed as a result, and maybe even disable issues.
This is slightly off-topic, but reading your responses on this thread just rub me the wrong way. You're acting like you're entitled for open-source devs to support you and value your contributions for the sole reason that they might put a line on their resume?
As if you had the right to be angry at somebody just because they had the audacity to open source code and struggling with maintaining it.
Of course it is simple to say "communicate this clearly" in hindsight. And I kind of did that. Still there are users who expect more from me than I can give.
As if you had the right to be angry at somebody just because they had the audacity to open source code and struggling with maintaining it.
Of course it is simple to say "communicate this clearly" in hindsight. And I kind of did that. Still there are users who expect more from me than I can give.
Yet again, I have not once indicated anger (what?) or entitlement. Yes, I have been frustrated at unclear communication, and I do not consider the expectation of clear communication to be entitlement.
I am moving towards open sourcing some projects (already have), and I am trying to think about this myself. I have not landed on a solution I am happy with or even followed my own README advice, yet. In my experience, it is very pleasant to work in repositories that set good expectations with clear communication. But it has been frustrating to interact with a "contributions welcome" repository where issues are swatted down like flies, especially when the reporter offers to debug and even help contribute a fix. I just stop going there, and I would have preferred to just have such culture be clear upfront.
I have even started considering offering paid support for important issues to be fixed, and I am trying to take an active approach in contributing to projects I like using, so I really don't think I approach things as you imply.
Edit: Also to be clear, I am not speaking to anyone specifically. These are general sentiments.
I am moving towards open sourcing some projects (already have), and I am trying to think about this myself. I have not landed on a solution I am happy with or even followed my own README advice, yet. In my experience, it is very pleasant to work in repositories that set good expectations with clear communication. But it has been frustrating to interact with a "contributions welcome" repository where issues are swatted down like flies, especially when the reporter offers to debug and even help contribute a fix. I just stop going there, and I would have preferred to just have such culture be clear upfront.
I have even started considering offering paid support for important issues to be fixed, and I am trying to take an active approach in contributing to projects I like using, so I really don't think I approach things as you imply.
Edit: Also to be clear, I am not speaking to anyone specifically. These are general sentiments.
The key thing is that your frustration doesn’t entitle you to anything.
The best thing to do is to contact the maintainer first before you do the work. Saves a lot of frustration. But I feel that people don’t want to hear no and need an excuse to do the work anyway because they like doing it.
The ‘no’ that eventually is / will be communicated shattered the illusion that they are helpful/contributing.
For me the whole “no” topic is all about setting personal boundaries. Maintainers have to deal with the same drama as mostly women face when dealing with unwanted attention.
But to me it’s 100% this ingrain sense of mostly men feeling so entitled to basically anything is so toxic.
“No” is a perfect antidote to that toxicity.
The best thing to do is to contact the maintainer first before you do the work. Saves a lot of frustration. But I feel that people don’t want to hear no and need an excuse to do the work anyway because they like doing it.
The ‘no’ that eventually is / will be communicated shattered the illusion that they are helpful/contributing.
For me the whole “no” topic is all about setting personal boundaries. Maintainers have to deal with the same drama as mostly women face when dealing with unwanted attention.
But to me it’s 100% this ingrain sense of mostly men feeling so entitled to basically anything is so toxic.
“No” is a perfect antidote to that toxicity.
> The key thing is that your frustration doesn’t entitle you to anything.
Well see, I never said that.
However, I do think maintainers, issue reporters, and contributors equally deserve clear and respectful communication and that, further, the burden rests on the maintainers to clearly communicate initial expectations.
> The best thing to do is to contact the maintainer first before you do the work
That's rarely possible without filing an issue, which will apparently be immediately closed anyway, and I think the better solution is for the README to merely state the expectations.
GitHub provides the ability to disable issues altogether. Just do that if all you want to do is release a personal project as open source only.
Well see, I never said that.
However, I do think maintainers, issue reporters, and contributors equally deserve clear and respectful communication and that, further, the burden rests on the maintainers to clearly communicate initial expectations.
> The best thing to do is to contact the maintainer first before you do the work
That's rarely possible without filing an issue, which will apparently be immediately closed anyway, and I think the better solution is for the README to merely state the expectations.
GitHub provides the ability to disable issues altogether. Just do that if all you want to do is release a personal project as open source only.
There is a middle ground where sometimes the maintainer does accept a PR and sometimes they don't for whatever reasons they have.
Maybe it's all clearer to you, but this isn't about you and what you want or need. This is what about maintainers need to keep their sanity and not abandon the project(s) all together.
Be happy with what you get, accept rejection / disagreement, especially if nobody asked for anything. And most of all, just accept the ambiguity. Learn to live with it.
I maintain that just contacting developers first before making a change/feature + PR is the best way possible to at least have some chance that the PR will be merged.
Maybe it's all clearer to you, but this isn't about you and what you want or need. This is what about maintainers need to keep their sanity and not abandon the project(s) all together.
Be happy with what you get, accept rejection / disagreement, especially if nobody asked for anything. And most of all, just accept the ambiguity. Learn to live with it.
I maintain that just contacting developers first before making a change/feature + PR is the best way possible to at least have some chance that the PR will be merged.
> However, I do think maintainers, issue reporters, and contributors equally deserve clear and respectful communication and that, further, the burden rests on the maintainers to clearly communicate initial expectations.
Why? No they don't deserve anything. Unsolicited communication is unsolicited.
>GitHub provides the ability to disable issues altogether. Just do that if all you want to do is release a personal project as open source only.
Why should anyone bother. It doesn't mean anything
Why? No they don't deserve anything. Unsolicited communication is unsolicited.
>GitHub provides the ability to disable issues altogether. Just do that if all you want to do is release a personal project as open source only.
Why should anyone bother. It doesn't mean anything
I was going to argue your comment, but you don’t deserve it.
If I want to contribute to an open source project is it good practice to ask the maintainer before submitting a pull request? I mean something like, "I'd like to contribute X. If I implement it, will you merge the pull request?"
No answer indicates that the maintainer has no time for responses, let allow code review, so it's an implicit "No". An explicit "No" is helpful so I don't waste my time implementing something that will never be merged.
A "Yes" is no guarantee, circumstances can change, but it's much better than the implicit or explicit "No".
Or are there benefits to never asking?
No answer indicates that the maintainer has no time for responses, let allow code review, so it's an implicit "No". An explicit "No" is helpful so I don't waste my time implementing something that will never be merged.
A "Yes" is no guarantee, circumstances can change, but it's much better than the implicit or explicit "No".
Or are there benefits to never asking?
The big question is do you need X personally? A lot of the time when I contribute to a project it's because I'm using the project and need the feature/bug fix for the thing I'm actually interested in. In those cases I'll just do it and then send a pull request. Some times they accept it, some times they don't, but in the mean time the thing I'm actually working on has the bug fixes and features I needed.
You do however have to be prepared that you will eventually get a No, and then you have to decide if you want to maintain your own fork indefinitely or find another solution (like rewriting your feature as a standalone plugin or library that connects to the project)
You do however have to be prepared that you will eventually get a No, and then you have to decide if you want to maintain your own fork indefinitely or find another solution (like rewriting your feature as a standalone plugin or library that connects to the project)
There's three general categories of unsolicited changes one might make:
1. The PR is a bug fix or feature that's critical for you, but you don't actually need upstream to merge it to use the fix yourself.
2. The PR is something quick and easy to do and if it doesn't get merged that's just no big deal.
3. The PR is a large amount of work that's entirely wasted if it doesn't get merged.
For the first two, I see no reason to ask first. The third you generally should.
1. The PR is a bug fix or feature that's critical for you, but you don't actually need upstream to merge it to use the fix yourself.
2. The PR is something quick and easy to do and if it doesn't get merged that's just no big deal.
3. The PR is a large amount of work that's entirely wasted if it doesn't get merged.
For the first two, I see no reason to ask first. The third you generally should.
Great article!
Yes fills time, no makes time.
https://jondouglas.dev/saying-no-will-make-time/
Yes fills time, no makes time.
https://jondouglas.dev/saying-no-will-make-time/
A ship engineer I didn't know was famous for answering every question with: "The answer is no. [beat] And we'll negotiate from there."
He never seemed stressed.
I remember having read a story that said (sorry I haven't bothered to re-find the source) that, among Steve Jobs' leaked emails, a large percentage of emails contained only one word: No.
Interestingly, there was an email sent to him by Kim Jong Un requesting an iPod. Steve generously replied to him with two words: Hell no.
Interestingly, there was an email sent to him by Kim Jong Un requesting an iPod. Steve generously replied to him with two words: Hell no.
"No" is an important word because it's the only way you can say "yes".
Imagine computers with only 1s and no zeros. Unless you can say no, you
cannot wholeheartedly say yes. An offer you cannot refuse, or a
question to which there is only one answer, are neither offers nor
questions. Schopenhauer made the general semantic observation; in a
world where everything is X, ipso facto nothing is X. Yes-men are
really "nothing men".
"No" is so much more polite than what people do today which is just ignoring something forever.
That's super interesting. Can you share a link? (Now that someone is asking, maybe you bother to find it? Also, please don't say no to this...)
found a source but I don't trust it https://scoopertino.com/wikileaks-releases-140000-emails-fro...
edit: it's a fake news site
> By now, you probably have realized that this was just a joke by Scoopertino, a website dedicated to sharing “unreal Apple news”.
edit: it's a fake news site
> By now, you probably have realized that this was just a joke by Scoopertino, a website dedicated to sharing “unreal Apple news”.
In many work environments and cultures, it's not so easy. A single "no", even after a long row of "yes" can put you in an unfavourable position. I was once working in an outsourcing company that was onboarding developers in various short-term projects, for a usual duration between 3 to 6 months. When your project is over, they try to allocate you as a resource to another one, with a different team, different tech stack, different working hours and different work culture. I said "no" to a project that was IMO a bad match for my skills and interests, and that was the downward slope towards no further promotions, my isolation from management and my eventual departure.
[deleted]
Then that work environment & culture is probably a bad fit.
Some related posts:
"Open Source & Saying "No"": https://connortumbleson.com/2022/11/28/open-source-saying-no... , https://news.ycombinator.com/item?id=33771881
"Open Source Is Free As in Baby": https://danielcompton.net/dependencies
"Open Source & Saying "No"": https://connortumbleson.com/2022/11/28/open-source-saying-no... , https://news.ycombinator.com/item?id=33771881
"Open Source Is Free As in Baby": https://danielcompton.net/dependencies
I too had crohns. I too was busy saying yes as much as possible and was certainly in the final stages of burnout. I really needed to learn this lesson but alas here we are. cant say even until today ive really learnt the lesson, I just have a better work situation which doesn't use and abuse me like a tool which can be replaced.
I'm obviously not the same category as Jeff; my open source projects are boring and dead. Luckily never needed surgery. Took me years to get off chemo and discover the cure to crohns.
I'm obviously not the same category as Jeff; my open source projects are boring and dead. Luckily never needed surgery. Took me years to get off chemo and discover the cure to crohns.
Reminds me when working on large scale project, we have maintained strict quality control.
The PR wouldn't be accepted if it had even a tiniest bit of tech debt or a hint of creating one.
Less experienced developers were struggling to put the work in and our reviews have given them a ton of extra work, often the PR would look completely different from what was first raised.
But the resulting code quality was great and the product had no issues whatsoever. The customer service never had to deal with problems with the project itself, just typical billing or "how to do something as I didn't bother to look into manual, please lead me" stuff.
Then we had a new CTO who was unable to get the board to understand why things take long time. We got mandated to let all PRs through as long as there is reasonable amount of tests and they pass.
This is where problems started to pile up. More experienced devs were now spending most of the time dealing with production bugs. Then they were quitting.
Company also found a brilliant idea that it's better to hire 3 junior devs than one experienced.
From there project turned into unworkable mess, nobody wants to touch.
CTO got fired and most of the developers. Company then decided to outsource the whole thing and commissioned a rewrite.
I've been meaning to make a web page that's a "Shrine to No", but not in the context he's speaking. From an informational perspective, "Yes" is meaningless without "No". If "yes" can be communicated, "no" needs to be a possibility (0, 1). No is fundamental to yes.
No. But seriously, saying "no" makes you a jerk. In the real world, the options are never "yes" or "no". Specifically when it comes to prioritizing work in software development, the answer is pretty much always a "when" or a "who". I get asked for far more high priority work than I can accommodate. As a manager, it's easy enough for me to go find someone who has time and redirect it to them. As an IC, you have less authority, but can still ask to pass the buck. If it's a feature request or bug report, the answer is always to put it in the backlog. Just because I can't do it now doesn't mean it should never happen. It will happen when it gets to the top of the priority list.
You only a reserve a "no" for when you really mean "never" or "that's a terrible idea so please don't ask again".
You only a reserve a "no" for when you really mean "never" or "that's a terrible idea so please don't ask again".
I would be interested in the book on Crohn's — or just a discussion about it. Digestive tract issues run in the family and it seems Crohn's is this mystery disease that they have a hard time 100% diagnosing (like there's no tracer-gene or blood test that will identify it).
I'm not a fan of stalebot at all. Just leave the issues open, so it's easier for a user of the project to browse the open issues and determine if they need to file a new bug, or maybe there's some info about a fix, etc. Having to browse closed issues adds a lot of overhead.
If you release something and aren't planning on maintaining it or accepting contributions, and it's a somewhat popular project, at least update the README to inform others and encourage them to file an issue with a link to their active forks. Someone else might be enthusiastically maintaining it elsewhere.
If you release something and aren't planning on maintaining it or accepting contributions, and it's a somewhat popular project, at least update the README to inform others and encourage them to file an issue with a link to their active forks. Someone else might be enthusiastically maintaining it elsewhere.
I rarely say no to customers in consulting and when I was working in the real world to managers or stakeholders.
Instead I gave them a choice. Every project has three facets - time, cost, and budget - and framed their asks in terms of trade offs.
As I’ve gotten more experienced, I can now add security, maintainability (technical people), legal risks, availability, ongoing maintenance costs, affect on future velocity, “bus factor” risks (“we don’t have time for training, documentation and knowledge transfers”), and is does the ask lead to a competitive differentiator (“does it make the beer taste better”)
Instead I gave them a choice. Every project has three facets - time, cost, and budget - and framed their asks in terms of trade offs.
As I’ve gotten more experienced, I can now add security, maintainability (technical people), legal risks, availability, ongoing maintenance costs, affect on future velocity, “bus factor” risks (“we don’t have time for training, documentation and knowledge transfers”), and is does the ask lead to a competitive differentiator (“does it make the beer taste better”)
I generally agree with my interpretation of this article. There's important lessons there on saying no and on avoiding forms of burnout. But be very very careful not to mistake this as a solution to "I don't want to eat my vegetables."
Sometimes we all have to do things we don't _want_ to do, in _some_ circumstances. If you're a contributor or author of FOSS, you are perfectly in your right to say no for any reason or no reason. But sometimes this all happens in a context where you're being paid to do a job.
Sometimes we all have to do things we don't _want_ to do, in _some_ circumstances. If you're a contributor or author of FOSS, you are perfectly in your right to say no for any reason or no reason. But sometimes this all happens in a context where you're being paid to do a job.
Stale bot are not okay. People spend time to write reproducible example of issue and are rewarded with annoying stale bot spam in 30 days. It could make some sense if the staleness was at least 365 days, then maybe the issue would have become irrelevant.
It's also really frustrating to face an issue, search for it on the tracker and find one or more closed reports with no attempt at fixing it. Those should not be close. The project is maybe yours, but record of issues isn't. It's a shared resource.
It's also really frustrating to face an issue, search for it on the tracker and find one or more closed reports with no attempt at fixing it. Those should not be close. The project is maybe yours, but record of issues isn't. It's a shared resource.
Every time I see an actual, reproducible bug report come across one of my repos, I immediately label it with 'bug', and the stale bot will never touch the issue.
I only let it loose on all the thousands of feature requests and incomplete issues where I have no idea what the person is even asking.
I only let it loose on all the thousands of feature requests and incomplete issues where I have no idea what the person is even asking.
I remember a colleague who was critical and pretty much the only person who knew how part of the business worked. He had a great analogy that for every new initiative and fresh recruit they brought into that area, it was like the organisation was hooking in another IV into him to draw more blood out. It's an image that always stuck with me to describe people in the situation Jeff found himself in.
This is one of the reasons I actively avoid acquiring domain and biz knowledge. You become expected to train others.
> Saying no is hard. It's an admission you can't do something.
Saying no is an admission that you won’t do something. You may or may not be able to do the thing: that’s orthogonal. By framing it in terms of ability, you internalize the no by describing it as a personal failing.
Saying no is an admission that you won’t do something. You may or may not be able to do the thing: that’s orthogonal. By framing it in terms of ability, you internalize the no by describing it as a personal failing.
How do you read "ability" into this? Can't can mean many things, like no I can't do it because I don't want to, I don't have time for this etc.
Can't (can not) does not imply won't (will not / don't want to), and vice versa. The words have different implications. Can't implies a lack of ability, and won't implies a lack of motivation. That's why the common statuses are "won't fix" and "can't reprodure", not "can't fix" and "won't reprocedure", even though the two latter would be interesting to see.
While writing this reply I realized that able/unable might be better words to use in this context, especially if you want to specifically remove your own motivation from the equation. E.g., by saying "unable to reproduce" or "unable to prioritize" you are implying "can't" as oppposed "I don't want to".
While writing this reply I realized that able/unable might be better words to use in this context, especially if you want to specifically remove your own motivation from the equation. E.g., by saying "unable to reproduce" or "unable to prioritize" you are implying "can't" as oppposed "I don't want to".
I definitely read "can't" in the passage you quote as expressing something like, "I can't do this because I'm too busy"
Just be honest to yourself and everyone. Follow this rule and you will automatically start saying no.
Curious on the shift to YouTube business. Is the ad revenue really that great these days for new YouTube creators? What's the real business on going YouTube semi-full time?
Not really; I'm earning less than half what I did consulting (and that on a midwestern salary... would've been much higher on the coasts).
If you want to play the ad game and line up a ton of sponsors, you can make quite a bit more, but since I'm very selective with any form of sponsorship (most of my videos don't have a sponsor), that's a lot of revenue I'm leaving on the table.
If you want to play the ad game and line up a ton of sponsors, you can make quite a bit more, but since I'm very selective with any form of sponsorship (most of my videos don't have a sponsor), that's a lot of revenue I'm leaving on the table.
So is your revenue all ad revenue? How long did it take to earn? I'm curious because I'm also thinking of putting a lot of tech-oriented content on YouTube, and to make a bit on it (side hustle money), but I'm not sure what to expect. You have a lot of subscribers!
Each niche in YouTube is a bit different, the RPM is the most important thing. For tech you get maybe $2-4 per thousand views. For finance like $10. For gaming and lifestyle maybe $1-4, depending on what you talk about.
[deleted]
I feel like this is mainly an issue when you want to be the only person doing the work. Maybe ask someone else if they want to do the work, when you are too busy?
I read somewhere that “the more you say ‘no’, the more you can say ‘yes’ to the things that are important to you.” I really like that and try to stick to it.
Comment section looks nice. I noticed that there's no requirement for email id. how's author preventing spam?
I'm using a service called CleanTalk, which integrates with Drupal pretty cleanly.
Say no to Stale issue bot
Thanks for sharing-- couldn't agree more!
[deleted]
Please, please, if you have IBS, Crohn or other immune disease try infrared light or better the sun. Especially if you spend a lot of time indoor (engineer) if you live in the north or if your condition get worse in the winter.
I know someone who save his life that way. To me it clear up my winter eczema.
We need infrared to get rid of inflammation. It’s scientifically proven, free, yet most people are not aware of it. https://youtu.be/5YV_iKnzDRg
I know someone who save his life that way. To me it clear up my winter eczema.
We need infrared to get rid of inflammation. It’s scientifically proven, free, yet most people are not aware of it. https://youtu.be/5YV_iKnzDRg
It's really frustrating to get downvoted for this.
I know it sound new age and all, but it’s tested, there is research papers on it.
It’s also very easy to test: two cages of mices one with infrared, the other without. Take blood sample and measure inflammation markers.
Then you can correlate inflammation markers with various diseases and get an idea of the magnitude of the effect.
I guess it was the same with vitamin-D, people must have think that plants use the sun, humans don’t.
I know it sound new age and all, but it’s tested, there is research papers on it.
It’s also very easy to test: two cages of mices one with infrared, the other without. Take blood sample and measure inflammation markers.
Then you can correlate inflammation markers with various diseases and get an idea of the magnitude of the effect.
I guess it was the same with vitamin-D, people must have think that plants use the sun, humans don’t.
I think you're getting downvoted because your comment appears to be completely off-topic from the post, and people immediately associate it with spam (especially when including a link).
Make sense.
It’s hard to share something like this and be taken seriously. The link is a doctor explaining how this work. People make the judgement in a split second.
It’s hard to share something like this and be taken seriously. The link is a doctor explaining how this work. People make the judgement in a split second.
> is ok: how many shiney rock grug really need anyway?
https://grugbrain.dev/#grug-on-saying-no