Just Say No

https://www.jeffgeerling.com/blog/2022/just-say-no

by Tomte • 4 years ago

253 130 4 years ago

jeffgeerling.com

thenerdhead• 4 years ago

Great article!

Yes fills time, no makes time.

https://jondouglas.dev/saying-no-will-make-time/

geocrasher2• 4 years ago

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.

ilyt3• 4 years ago

And for anything that's not the work you are contracted for

"My consulting rate is $XXX/hour"

karussell2• 4 years ago

I do open source for money and still you have to say No very often.

sublinear• 4 years ago

I disagree. One aspect of "tact" is that it's not always necessary.

scarface742• 4 years ago

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.

geocrasher2• 4 years ago

"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.

ht_th• 4 years ago

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.

petre• 4 years ago

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/

JamesSwift3• 4 years ago

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.

hu3• 4 years ago

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.

toast03• 4 years ago

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.

deaddabe• 4 years ago

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.

ushakov• 4 years ago

you can't disable PRs on GitHub, can you?

Raed667• 4 years ago

The only reasonable stale-bot policy for me is when a maintainer asks for more information and the issue creator stops responding.

jeltz• 4 years ago

Yeah, stale bot is just an awful experience. I would rather not be able to create issues at all.

louwrentius4• 4 years ago

No.

You are asking for extra manual labor that the bot was meant to handle.

lolinder2• 4 years ago

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.

plorkyeran2• 4 years ago

Maintainers doing literally nothing and simply ignoring issues entirely is a better experience than using stale bot.

matkoniecz10• 4 years ago

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.

justin_oaks2• 4 years ago

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.

lesuorac• 4 years ago

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.

dottedmag• 4 years ago

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.

toast03• 4 years ago

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.

matkoniecz10• 4 years ago

You can give people permission to triage and close issues.

nonameiguess• 4 years ago

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.

UglyToad3• 4 years ago

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.

matkoniecz10• 4 years ago

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

jjav2• 4 years ago

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.

JamesSwift3• 4 years ago

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.

zozbot2342• 4 years ago

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.

lolinder2• 4 years ago

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.

DishyDev• 4 years ago

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.

throwawaysleep• 4 years ago

This is one of the reasons I actively avoid acquiring domain and biz knowledge. You become expected to train others.

recursivedoubts• 4 years ago

but grug must to grug be true, and "no" is magic grug word. Hard say at first, especially if you nice grug and don't like disappoint people (many such grugs!) but easier over time even though shiney rock pile not as high as might otherwise be
is ok: how many shiney rock grug really need anyway?

https://grugbrain.dev/#grug-on-saying-no

teddyh2• 4 years ago

I agree with grug, but grug was (mostly) talking about saying “no” to grug’s boss and business demands, not to users reporting issues.

dncornholio• 4 years ago

Just be honest to yourself and everyone. Follow this rule and you will automatically start saying no.

incomingpain• 4 years ago

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.

ilyt3• 4 years ago

Say no to Stale issue bot

JKCalhoun• 4 years ago

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).

bmitc8• 4 years ago

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.

gautamdivgi2• 4 years ago

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.

bmitc8• 4 years ago

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.

geerlingguy6• 4 years ago

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.

louwrentius4• 4 years ago

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.

bmitc8• 4 years ago

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.

narrowtux2• 4 years ago

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?

bmitc8• 4 years ago

> 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.

matkoniecz10• 4 years ago

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?

bmitc8• 4 years ago

> 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.

jjav2• 4 years ago

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.

tianqi• 4 years ago

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.

baxtr2• 4 years ago

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...)

shawabawa3• 4 years ago

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”.

kyleyeats• 4 years ago

"No" is so much more polite than what people do today which is just ignoring something forever.

nonrandomstring• 4 years ago

"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".

marcus0x62• 4 years ago

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.

baxtr2• 4 years ago

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.

hxugufjfjf2• 4 years ago

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".

giaour• 4 years ago

I definitely read "can't" in the passage you quote as expressing something like, "I can't do this because I'm too busy"

bluetomcat• 4 years ago

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.

renewedrebecca• 4 years ago

Then that work environment & culture is probably a bad fit.

axus• 4 years ago

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?

varispeed• 4 years ago

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.

lucideer4• 4 years ago

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.

bouke• 4 years ago

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.

yebyen4• 4 years ago

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.

scarface742• 4 years ago

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”)

alfor3• 4 years ago

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

alfor3• 4 years ago

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.

orthecreedence• 4 years ago

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).

jerrygoyal• 4 years ago

Comment section looks nice. I noticed that there's no requirement for email id. how's author preventing spam?

geerlingguy6• 4 years ago

I'm using a service called CleanTalk, which integrates with Drupal pretty cleanly.

rexreed2• 4 years ago

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?

geerlingguy6• 4 years ago

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.

rexreed2• 4 years ago

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!

Zamicol• 4 years ago

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.

Waterluvian2• 4 years ago

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.

tootie• 4 years ago

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".

justin_oaks2• 4 years ago

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?

dagw• 4 years ago

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)

plorkyeran2• 4 years ago

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.

Waterluvian2• 4 years ago

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.

rem7• 4 years ago

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.

nayuki• 4 years ago

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

linuxftw• 4 years ago

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.

j-bos• 4 years ago

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.

aleyva• 4 years ago

Thanks for sharing-- couldn't agree more!

jpambrun• 4 years ago

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.

geerlingguy6• 4 years ago

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.

Just Say No

Related Stories