You have gotten a sign wrong here in your sensor readings where arrogance and hostility are. Someone gives you a present that comes with a condition. You either take it, or you leave it. But calling the donor "arrogant and hostile" because you don't like a condition just got you uninvited from all future gift exchange parties.
Back then when people still knew what patches were, the whole post of the OP would have been a one liner:
[x] send patches or stfuThe person who says that is either an idiot or doesn't care about the product. There's really no third option.
It's fine if you made something once that you no longer care about and want to abandon. Really! I understand that free software isn't free! Someone has to make it, and that takes time and effort and energy, and maybe you don't want to give that anymore! That's OK!
But don't for a second think that it's reasonable to give a song and dance about pretending to still care while demanding pull requests for every bug. Mark the project abandoned, and go do something else without stringing people along. Otherwise you're being a prick to your users for no reason. Non-technical users discover bugs that you didn't catch all the time. If the developer/maintainer gives half a shit, they'll listen to those users.
If you only care about the bugs that someone else fixes for you, then you don't actually care. They do, and you're just pretending. It's perfectly reasonable to stick your fingers in your ears and go "LALALALALALALA" instead of listening to reports about bugs in your product the moment you stop giving a shit about it having bugs. A competent person who actually gives a shit isn't willing to put their head in the sand like that.
You're mischaracterizing the author's post. Notice that the author specifically wrote:
+ "Fork the repo, add a failing test."
+ "Add an example in the repo that illustrates the bug."
Neither of those requests is "fixing" the bug for the author. Maybe those tasks in your opinion is asking too much of users -- and that's fine to feel that way -- but it's obviously false to say that submitting bug reproductions actually fixes the bug. It certainly doesn't.
Obviously an idiot.
> It's fine if you [...] want to abandon [a project]. Really! I understand that.
The idiot does not understand:
It is NOT ok to reduce interaction with endusers when it becomes too tiresome.
It is NOT ok to demand patches instead of bug reports.
It IS ok to just completely abandon a project though, i.e. not even accept patches?
Bwahahahaha.... (that is a good laugh born out of an idiot's blissful ignorance).
PS: The only "prick" in the discussion is the one who feels entitled to something and who calls people names because they don't deliver for free what her/his majesty wants.
Not everything has to be a "product." Sometimes developers toss their projects up on Github just to get it out there. They don't necessarily want to make it a "product." There are plenty of valid reasons to open source something besides just, "I want a bunch of people to use my product so I can become famous."
Word choice aside, I don't think the author is trying to say, "send patches or stfu." I read it as the author pointing out the shortcomings of standard "issues", and exploring alternatives that might encourage closer collaboration.
Put another way, it's not a gift if it somehow eventually fucks over the receiver. Or perhaps you consider STDs a gift? ;)
Recently I've opened an issue on a project I really appreciate, and I'm so sorry I don't have time right now to help the developers solve it. And so I don't blame them either.
When I'll have more time/skills I will totally stick around, keep giving feedback and maybe propose PR if he hasn't solved the issue by then. But I really don't feel like signaling a serious issue without PR was spamming them.
And who know maybe I'll become a contributor one day if I can. But right now, had I been "forced" to submit a Pull request I would have either submitted a really crappy one or more likely censor myself...
Here is the issue if you feel like having a look : https://github.com/pgRouting/osm2pgrouting/issues/167
NOOOOO. No thank you. There's a mailing list, a gitter.im channel, a Stack Overflow tag, and my email address, all of which can be found in the README file you see first thing. Don't abuse Issues for asking questions.
I don't bother with mailing lists, and when I post an "issue" on the site, the system mails you on your preferred mailing list. Then You reply to the mail with your preffered client and it shows up for me in the issue thread on github?
Questions in an issue tracker are like rocks in my shoes. You have to work around them, and they bug you (the developer), not the person who put the rock there. When can a maintainer close a question-issue? Never - because whether a question has been resolved is up to the person asking, not the person answering. As a maintainer, if half the open issues in an issue tracker are questions, my "open issues list" is suddenly completely useless. And this is really common because lots of people asking questions will disappear and never never close the issue once the question has been answered.
User questions are important, but the github issue tracker isn't the right place for them. If you want to take notes but the only paper you can find is my todo list, its still not ok to take notes in my todo list. Github issues is the same.
If you can't be bothered to send an e-mail or submit to a mailing list, why should he/she be bothered to deal with your preferences? He/she is delivering the value, not you.
An issue feels, on the receiving end, like an accusation. The word says you did something wrong, and you've inconvenienced/harmed/let down someone, who is now waiting for you to make them whole again.
Answering a question gets you a thank you–you've done something altruistically,. You're a good person.
Fixing an issue? "Took long enough. Are you sure you're any good at this?"
At least some search the issues and answer the question themselves, it's even more valid when the maintainer decided to abandon the project.
Yep, even if you are a kindergartener.
https://www.yahoo.com/tech/five-year-old-boy-finds-xbox-secu...
I normally search through Google, which will find the best source for my question, be it Github or SO. Maybe the creator is not on SO because they have no time to go there.
I do agree on everything else except that affirmation though, but I also think you are looking at it from the point of view of a maintainer with lots of time, when that might not be the situation. The maintainer might just not like providing free support for a company, while still caring for improving the project. This just seems like a way of (over)filtering things.
Yes. Even if it's a stupid question in the docs maybe that means the docs are not as good as they could be. Or maybe it's a lazy developer / user. It doesn't really matter; most questions are going to be asked multiple times. Saving it in an issue will help those users who use GitHub or Google search and come across it.
> If a developer is so saturated that they can only look at 1 issue/day, wouldn't it be better for that issue to be of substance than a random, one-off question?
This is a pipe dream. You're never going to get issues of substance. Even if the proposed gist you're going to get a lot of PR garbage that maybe wouldn't have been a PR in the first place.
> I also think you are looking at it from the point of view of a maintainer with lots of time
I don't see why. My position isn't A maintainer has to answer all questions in an expedient fashion. When you add friction you're going to get less of both the good and the bad. If that's a trade off you want to make, fine, but that's not how you make a good product IMO.
It's an important skill to learn to take a lot of incoming noise and filtering it out to find the signal. It may be a good time to work on it if you have a OSS project people are using frequently enough to file issues. Don't forget there are other resources available to you. You may find people in the community to help answer questions, maybe you already answered a question in the past and you can quickly search for it and reply, etc.
Of course if you remove issues and reroute people to PR the quality of them will lower (though not so low as Issues) while you will miss important things, but still seems like the net result is a easier to review _issues_ which might be what saturated maintainers want.
Edit: I totally agree with the last paragraph (and parts of others of course).
Yes, you don't have to answer people but when you put code out there for someone to use is it crazy to think people may have a question? That should go in an issue. People can search and find those answers. Telling someone to read the docs or go to StackOverflow, where the creator of the project may not be, is a terrible idea. Questions give a maintainer an idea of what should be focused on while keeping ownership of those questions for triage. Getting lots of people asking the same thing over and over? There's a good chance your design isn't that intuitive for that use case so maybe adjust? Good luck aggregating that information from multiple third party services.
You can even find issues, even MAJOR issues without understanding the code at all. If someone finds a major issue but has no way of knowing how to tackle it now you're going to either miss out on knowing about it or they're going to submit a PR that is a big waste of their time and your time.
This suggestion loses out on data and more direct interaction with users. Seems like a big loss-loss to me.