When it's hard to figure out what is being asked, or the bug report does not follow the issue template and there are no clear steps to reproduce the bug, I'll label the issue as `incomplete`, which asks the author to fill out the issue template properly, and closes the issue.
I've also configured labels with messages for common questions [2] or issues that are outside the control of the project, so I can inform people without repeating the same things over and over.
I agree that we should not be expected to provide support, though I find it acceptable for now to post automated messages, when it can help others.
[1] https://github.com/dessant/label-actions
[2] https://github.com/dessant/buster/blob/master/.github/label-...
Facebook was using my app in the React Native repository, until they have replaced it with their own implementation [3].
It would be nice if they weren't jerks and at least not casually seize the project name, but here we are.
Meanwhile I'm still banned from Facebook for no reason, after I've recently signed up to use Wit.ai, and they illegally hold control of my personal data on Facebook and Wit.ai.
https://news.ycombinator.com/item?id=25033510
https://github.com/wit-ai/wit/issues/1946
[1] https://github.com/hramos/label-actions
[2] https://github.com/marketplace/actions/label-actions
[3] https://github.com/facebook/react-native/commit/f9c2157141b8...
Maybe you've just inspired me to actually do it.
https://github.com/facebook/react-native/issues/30395
Hopefully they will be helpful, and I don't have to take legal action regarding the project name, nor file a GDPR complaint for the loss of control over my personal data.
The reason for this is that it allows others to chime in and add to the issue, and for users to discuss it among themselves and even find solutions and workarounds. I can't say how many times I've had an issue with some open source project and I find related thread in the github issues. And often the solutions or workarounds are suggested by community members, not the maintainers. But I find it soooo frustrating when the issue has been closed by a "stale bot" because it hasn't been active for 30 days.
This is the spirit of open source, IMO. The creator shares their work with the world, with no commitment or obligation, and the world makes of it what they can. Maybe the maintainer volunteers to help people troubleshoot their issues, or maybe the maintainer is too busy. That's ok. Let the issue sit there, and maybe another kind soul will happen across the issue and answer the question. There isn't enough info to reproduce? That's fine, it's quite possible - even likely - that someone else experiencing the same problem will find the issue and be able to add more context.
The stale bot will unhelpfully ask if "this is still an issue" or if something is being waited on for a pull request. You take the time out to reply, so that stale bot keeps the issue open. Repeat this meaningless back and forth, for months as the maintainers ignore the issue or pull request. Eventually lose the will to continue and let the bot close the issue or pull request.
Net outcome: A potential contribution or solution lost.
Stale bot only exists for aesthetic reasons, to keep issue lists clean and to close issues that maintainers don't want to deal with directly by abstracting away the interaction.
More maintainers should understand that it's OK to just ignore an issue but leave it open.
If it's configured with a short timeout and with preventing further comments, I totally agree. That's rally annoying. But maybe there are circumstances where it's actually useful.
If the maintainer is using the issue tracker to prioritize development, they should feel fine about closing issues, especially when those issues are underspecified, ignore the project's contribution guidelines, or are otherwise incomplete.
> That's fine, it's quite possible - even likely - that someone else experiencing the same problem will find the issue and be able to add more context.
That's not my experience with issue trackers. It's far more likely that underspecified and otherwise problematic issues accumulate until the issue tracker becomes borderline useless.
The issue is still there if it is closed, including any contributed but unapplied patches.
Upstream may not care about them, but they can help others with edge cases too.
There are automated actions when people delete the issue/PR template, and when they don't sign off commits for the DCO. This saves me a lot of time personally having to go and comment and explain every time. I'm going to take a closer look at your bot going forward. Thanks for sharing it.
(Yes, looks like your software can do more)
As the author of a few popular open source projects [1] [2], it has been a fun ride, and I have learned a lot.
However, the honeymoon period is over for me. The vast majority of the time it’s a lonely, thankless effort.
The problem is that after several years and thousands of people and businesses using the software every day, very few actually take part in improving the project. Or even saying "thank you" to be honest.
I’m happy to work on my project and fix issues, but please don’t abuse it. Being open source means that you can change the code if you want to, not to get a developer to work for you “out of love”.
That’s why for my most recent project [3], I have decided to no longer start with an “open core” product. Instead it's a SaaS with a generous free tier. Price goes up the more value a customer gets out of it. Yes, people have already given me crap about not being open-source, but I do feel that so far it's a more sustainable model.
I suspect that's not something you have time for (nor do I) but I just brought it up because I have a friend that runs a semi-successful open source project and has managed to find companies willing to pay for support and new features to the point that he's fulltime on his project and has told me he was planning to hire one more person (I didn't follow up to see if he hired someone)
On the converse, I hate the new culture of put up an open source project and ask for money, especially when that project is often very small and/or really just an assembly of 2-4 other open source projects.
This seems especially common in npm/node projects now-a-days. Every repo I look at has a donate button for even the smallest of things.
I'm one of those annoying people with a donate button. Despite my project's size (~10.5k stars on Github), it pulls down only about $60/month. While awesome, and I'm legit thankful for the people who back open source, it's obviously not yet at an amount where I could devote my time to open source entirely or even part time (which would be the dream!).
My recent minor release took about 45 hours to prepare, then another 8 for a quick followup tacking on some additional functionality. Which is to say, open source gets me about $1/hr ^_^
So far I'm quite happy with the SaaS approach as I'm able to prioritize my effort on improving the product for customers who support it via paid plans.
As a one-man team it's important to reduce operational efforts. I like very much the idea of having monthly subscriptions with predictable cash flows. Let's see how it goes.
Note: the two approaches aren't mutually exclusive. You may even find that the folks who prefer to self-host the open-source version are leads to even more lucrative on-prem enterprise plans.
The hard part to think about is segmentation of features between the open-source/free tier and the paid plan/enterprise versions.
Of course, this is all becomes dramatically easier if you decide there is no difference feature-wise, and the differentiation is solely in volume of use and level of support.
For those people I don't want to hide my code. Please consider a "source available" approach (at least for the "core").
The "No" is especially fun to use with people have the wrong impression that if you know how/can to do something you actually have to do it for them whenever they request it.
That being said:
For FOSS stuff: I do want to know if anyone finds any bugs and how to reproduce them. Doesn't mean I'll fix them though. It only means that If I think I'll end up in a scenario where that applies (or I'm bored one day) I will fix it.
Also, your project is better off for having the bug reported, even if it's never fixed. Known bugs are less of a problem than unknown bugs, especially if clearly documented. With legacy systems, it might even be impractical to fix the bug, as other code may rely on the original buggy behaviour.
There is a better approach and it's simply: politely refuse.
People intruding the private email? No problem. Politely refuse, and offer private consultancy at $very_high_price, with alternative, to open a bug in the bug tracker, making explicit that there is no commitment.
Something important to keep in mind is also that by establishing ignoring as a policy, one will never learn to politely refuse.
I'm a maintaner as well, and I speak for personal experience.
Of course it is possible to be "nice" and earn a few bucks on the side by making it a paid request. But i.m.e. it is rarely worthwile, most start an argument after receiving the consulting offer which can only be ended by ignoring them after all. And those people are usually the bad kind of customers, complaining about rates, hours, wanting free side requests, "tax-free" invoices, etc.
I've tried this (for a short while) and will never do it again. Ignoring them is actually the kindest way to do things, to them (you prevent them from wasting their time) and mostly to yourself.
I think parent poster was never in a position where he really has to set priorities and never tried to be polite to 1000 people in a single day.
Funny, I thought this was a software orientated site. /s
Seriously though, copy/paste is fine. Autoresponders are fine, especially if noted as such in the email response. An automated response is better than no response.
Automated response is better if one expects confirmation of delivery and then more specific response.
I would be mad at a person that sets "will get back to you soon" as auto reply and never follows up. On the other hand what would be auto response when you don't want to respond? Something like "Hi, we got your message, don't expect hearing from us. Have a nice day!" that is even more rude.
Conceptually it is always a problem. This is how communication degrades and descends into chaos.
Most of the communication in the internet degrades, because information flow is lacking. If you answer politely, you can, when meeting in person, still convey an air of annoyance. You can signal the other person more than just what is being said. In written communication, this doesn't work. All the polite subtleties will be missed. All the cultural cues, like being overly polite or formal to signal distance, don't work because there are just too many cultures meeting, and you can't calibrate your interpretation to the other side like you do "at home".
This means that in the internet, you need to be more direct. You need to say what you mean. And if you need to dismiss somebody, you need to be explicitly dismissive. If somebody is rude, you need to be rude and tell them about their rudeness. Being polite for the sake of politeness is misleading, inducing the other side to continue their errorneous behaviour up to the point where things really degrade into an unpleasant situation.
From a technical perspective: Ignoring leaves the loop open. I don't know: - if you ignore it on purpose - or if you don't want to solve it or - or if you don't have time or - or if you just missed it ...
That's when I would re-send the message or do something else. A Win-Win would be sending a small "won't-fix" or whatever.
Often that's what you want! Maybe I don't want to reject your bug report outright, maybe I'll get around to it in a few weeks or months or years. Or not, I dunno.
I've had my own issues and bugfix PRs on small projects ignored, that's fine. Nobody should ever have the expectation of a response on that kind of project.
Ignoring: for the maintainer: open loop or maybe hidden closed loop (e.g. afraid of confrontation); for the requester: open loop.
The intention of saying no is a closed loop.
> Nobody should ever have the expectation...
Yes, but that's not a pragmatic solution. People sometimes DO have the expectation.
After a couple of years of politely declining, it gets tiring. It's OK to ignore people. It's not rude at all! I care more about my own free time (that I spend writing open source software) than I care about being polite to people ignoring instructions and expecting us to work for free FOR THEM.
When you are in a semi-public position or vaguely popular, you can have 1000 persons a day asking you for stuff. No you can't politely refuse because not only you don't have time to write the refusal, but you don't have time to even consider the offer. Ask any pretty girl what happens on tinder. It's the literall same in a professional setting if you have a semi-valuable or public position.
Then you will realize being ignored is the default behavior as you get into more "valuable" circles or look for more "valuable" ressources in general, and that it's the burden of the "asker" to make himself interesting to the person he wants an answer from. No one owes you his time because you exist. You will understand that because there will be 100s of candidates looking for the same ressource than (speaking very generally). That's when you will become less sensitive (or you will become frustrated as why the world is soo not nice with you).
Good luck and no offense
I an strongly in camp of "it is OK to ask for features and report bugs", but it is only as long as it does not create dutys on the side of maintener. If it would create such duty, then I would think prior should not send those unless super important.
Pls, it is easy for many people to overwhelm one maibtennar.
Making some software public does not mean that they are entitled to any operational or emotional consideration on your part. Having to 'refuse' costs emotional energy and karma, that bank is not infinite.
If you don't want to take inquiries, put that on the front page and ignore everything.
No feature requests: Author(s) do not wish to "politely refuse" every wild idea you might have.
No Support requests: Author(s) do not wish to "politely refuse" every time you need hand holding with your implementation of hello world.
No Pull Requests: Author(s) will collaborate within a restricted group and do not wish to "politely refuse" your t-shirt contest contributions.
No amount of README pleading, CONTRIBUTING.md or issue templates can stop the class of people which don't read and don't care. If you open an issue on my project, at the top, you'll get a message explaining that, as shocking as it may be, "debugging requires information." Then there's a checklist of 5-6 items which are the bare minimum required for me to start debugging this app which runs on numerous operating systems and platforms.
Despite all of this, about 20% of all issues ever opened in the project have blanket ignored the expectations of the project. The coding part of open source I still love. The administration of the project, and endlessly begging people to follow the guidelines, necessitates occasional sabbaticals to recover my sanity.
That said, I feel that the balance in open source has shifted from fellow developer users to companies leeching off your stuff to power their SaaS.
So these days, I prefer offering a rate limited free API instead of local tools and / or source code. That also conveniently keeps non technical users away.
Same here. To avoid getting overwhelmed by this, I have setup a particular email address tied to my git commits, that gets re-sent to my main email address, where it gets filtered, marked as seen and tagged as "potentially spam". I look at this tag sometimes (maybe once a month), depending on my available time, but in most cases, I just receive automated spam that is not even worth opening.
That is a little bit outside the usual norms of the OSS maintainers that I've seen. If that is the strategy adopted in a repo then it would be polite to document it somewhere obvious when users try to submit bugs. Like a paragraph on support policy or something.
But yeah that is the only strategy that makes sense to me. If they want a guaranteed professional response, they can pay professional rates for it.
I disagree. This is the default assumption in open source. "You want something fixed? Fix it yourself!"
If you're adopting a different strategy than that, feel free to document that, but let's not start defaulting to offering people free support, because that'll make no one happy once maintainers start burning out.
I think something that has perverted the way we see open source is big companies doing open source. Of course the people who get paid by Google to work on Kubernetes has the time for answering support questions, as it's probably a part of the reason they get paid.
But for us who individually do open source, or as part of non-profit work, we've never defaulted to providing free support to people who don't support us back. Let's not change that.
The "Puddy" :)
Developers/maintainers are getting a lot more contact with a larger cross section of society, which is a catch-22.
I'm with you on ignoring parasites, but I also am in favor of offering 100% refunds to dissatisfied users to try drive the point home.
Keep it up and good luck. The most you invest in community, the more you can delegate and find "co-developers" who can help you in ways you couldn't imagine.
Mostly open source are code that interest developer period.
If you want some code that cater to your business or person need then pay for it!
Just be respectful, post your question or request, and don't be upset if you get no answers.
Perhaps I've gone too far with it. Ignoring sounds like a powerful tool.
I'm also starting to offer alternatives to get "paid attention" and support https://www.openfaas.com/support/
But that doesn't mean you have to respond. It is nice if you do, but we should not add the expectation that you'll get help from maintainers.
I think all these conversations are about the expectation to get helped, not that it's nice if we do help.
Ignoring others. You don't like the question? Ignore them. You don't feel you have the time to support them right now? Ignore them. It feels like they are entitled? Ignore them.
I don't think people asking others to work for free is anything new. The recent outrage about others asking you to work for free is relatively new though.
You're publishing open source code because you feel like it. This also means you can run the project however you want. Tell people to fuck off if you don't like them. Or don't tell them anything if you don't feel like it.
You'll feel much better as a maintainer once you act exactly like how you feel like it, no more and no less. Don't pay too much attention to what others say. Time is much too limited to be outraged at everything. Calm down, and ignore people you don't like.