This would stop a lot of important communications. Sure some repo's would benefit but others would merely wither and die. Not everyone that uses open source is a programmer or technically apt enough to put code into and editor and submit a pull request.
I do not like to have discussions in chat because of how unstructured they are. Important details get lost and can never be hard to recover. Furthermore github comments are an excellent place for seeing different aspects and workarounds for an issue that has not been fixed. They also often show inner structures of the program that can be hard to gasp from the code itself (why x has been done this way instead of that way).
While chats can be used for that, they do not make a good job to archive the results a group discussed. For open source projects, this is essential. I often read 1 year+ old issues and they discussions are still accurate and good.
When people chat, they do not have a lot of discipline to document this. Chats are more like a conversation. They are great for two or more people to discuss something but not really good for an outside person who just gets to read the protocol.
SO is not the place to have discussions. You help people for their specific problems. You do not discuss changes there. At best, you leave a link to the issue tracker which deals with that topic.
> They also often show inner structures of the program that can be hard to gasp from the code itself (why x has been done this way instead of that way).
Is this not literally the point of comments in the code?
Even as a developer, an issue from anyone (even non-technical people) helps people find out quickly if someone else is having the same issue you are with something, even if it's not fixed.
Yes. As a maintainer whom actually cares about feedback and usability, I care that features developed apply to the real world and aren't imagined in an utopian vacuum by own possibly insane biases. Social democracy, not authoritarianism. If code isn't usable by other people in the real world, it's just graffiti while waiting for Godot.
As a maintainer who also cares about feedback and usability, but who doesn't maintain any high-traffic projects, I can just about imagine how frustrating and destructive of motivation it gets to see the same no-thought issues raised over and over and over.
But if you close them NOTABUG or WONTFIX, you get a reputation as that guy who just doesn't want to hear about it, what a bastard.
I think there must be a middle way somewhere, for those projects which attract a lot of interest but few or no co-maintainers. But I'm glad I'm not on the hook for finding that middle way, too.
Oops, hit logout on that throwaway account. Bye-bye, religious flame wars. ;)
Support is what it is, and it's a two-way street.
Most engineers usually don't have customer support or sales experience, and so don't have the experience to triage and communicate pro-socially. (I sold software as a high-school job and also had my own consultancy at 17.) It's important to push outside one's comfort-zone when young (or old) to acquire skills that will be vital later on.
Post the policies, requirments and desires in contributing.md promenently. (I think a CoC is redundant and tyrannical SJWing.) Setting expectations and not making promises is important.
Finally, there is a cost to FOSS on both supply and demand sides. I just had some company fork the repo of a project I fixed, make a pointless PR and then offer no contributions in a grsec-theft-style way.
PS: Subversion has a great talk about defending the community.
> Think you found a bug? Fork the repo, add a failing test
It seems like this would also really help with duplicated error reports which can be burdensome to sift through, and hey if someone else comes along and has the time to fix the bug in question they now have a great means to validate their fix by.
> Think you found a bug? Fork the repo, add a failing test
Ugh. No. 999 times out of 1000, the person maintaining the code actually knows what it does and how it works. And if I'm not that person, I don't. I found a problem. The problem affects me. It also probably affects other people.
I'm an intelligent, capable, curious, knowledgeable, and caring professional software developer. I write code for fun, but I write _my_ code for fun. And after that I don't have the energy or the inclination to learn how your shit works deep down where it matters. Because what will take you a minute, will take me a month unless I stop going to work every day.
I will do my best to describe what I was doing when the problem occurred, what I expected to happen, and what happened instead, but screw you if you think I need to understand your codebase or your testing infrastructure in order to report a problem.
You're being sarcastic, right? This is OS. It's fundamental underpinning is that if you want to use it (or at least engage its maintainers), you have to care.
That being said, maybe there could be a "found problem, not sure is a bug" flag that defaults to on. Or a warning dialog that says "without example code or detailed repro, this issue probably won't be looked at."
> You're being sarcastic, right? This is OS. It's fundamental underpinning is that if you want to use it (or at least engage its maintainers), you have to care.
Ugh.
My partner, who doesn't know the first thing about code, understands the value of FOSS. Caring about FOSS doesn't fix bugs.
A month ago (more?) I encountered a bug in LibreOffice Writer, which I use because it's really good, where track changes on a docx file wasn't working properly in a particular situation involving the deletion of tracked comments across saves.
QUICK! Find the line of code that caused it! Find the mechanism for creating a test case! I'll wait here.
Back here in the real world I was able to report the bug and have it fixed by someone who knows what the code does.
Don't stop there: plenty of libraries are more complex than the applications using them. More complex, more general, used by more people. I mean, just libc and curl probably dwarf most applications that consume them.
But if the developer who gave you the fruits of their labour for free proposes a way to report bugs that works best for them, take it or leave it, or recommend a different approach in a civil tone if you must. But 'screw you'? Not classy.
Also, many Github-hosted projects are critical infrastructure for some people. They will make it as easy as possible for the developer to fix their bugs, if they are rational.
To be fair that's exactly the tone I read the gist in as well. It seems a bit overly hostile to users who may have questions or suggestions but either don't or cannot contribute code for whatever reason.
That's very true. But the relationship between developer and user is not symmetrical. I'll give the grumpy developer a pass that grumpy end user didn't earn.
Fielding a few hundred rude and entitled support requests for your free software can make anyone grumpy. Once you have a few thousand users your inbox is a source of frequent misery.
> But the relationship between developer and user is not symmetrical.
I disagree. I see them as identical. Yes you're offering a free product but it's still a product, even if you don't want to call it one. The developers are your users. They are the ones using it. But even a developer may not know how your code works well enough to submit a PR.
> Fielding a few hundred rude and entitled support requests for your free software can make anyone grumpy. Once you have a few thousand users your inbox is a source of frequent misery.
For sure but I don't know how you avoid this without also isolating yourself from likely valuable feedback / information. Similar to fielding customer requests for a product a good 96% of the ideas / things customers want are going to be a terrible idea.
If I've learned anything from running products it's this: make it as stupid easy as possible for your customers to give you feedback / get ahold of you. When you do that you're going to get an absolute ton of noise but the bits of signal hidden in there can be amazing and you'll be able to directly help those along the way. From there it's learning how to manage the flow of information coming to you and trying not to take the bad personally (which is very hard to do when it's your baby / code).
> Fielding a few hundred rude and entitled support requests for your free software can make anyone grumpy.
Work smart, not hard. If you're getting a lot of support requests (entitled or not), add a paid support option. If you have so much traction already that you constantly have to deal with "hundreds of issues", you're well past the point where you should have done that.
"I found a bug and you won't consider it unless I phrase it as example code? Screw you, I won't report it then!"
This seems like a reasonable thing to think and say.
A better alternative to the article's suggestion is to state somewhere that it is very likely your issue won't be considered unless it takes the form of a PR. The maintainers, if they don't want to deal with the bug, will say "could you make a PR with a failing test case? Otherwise I don't have the time to work on this".
That way, those who really want the bug fixed have to put in work, but those who just noticed a problem and are kind enough to let the maintainers know can do so easily. Why discourage bug-reporting?
That doesn't help much, seeing as the predicate is essentially "… if you don't want to do free debugging work for me as well as the free development work you're already doing."
Nobody said you have to actually fix the errors, only allow them to be reported. (Which GitHub makes pretty effortless, as I understand it.) At least then someone might be able to volunteer to fix it for them, especially if it is a serious or common problem.
Perhaps most importantly, having the issue there let's some other interested user see it and put the effort in to repro the bug and do the test case or demonstrative example.
A thousand times this. Issues are generally a favour your user is doing you and your project. Yes, sometimes they're a waste of time; it's fine to close them if they are, it takes exactly one click to do so. Most of the time however, they're valuable even if you don't fix them: Other devs might see them and fix them for you.
In almost all cases, turning issues off is incredibly counter-productive.
My advice is already useful. If someone chooses not to take it because they'd rather tell non-technical users to pound sand, then I hope their project suffers for it.
Issues are fine. You don't need to tackle them, they're not an obligation - you don't have a contract with your users saying you'll fix their issues. If that's something you want, then say so in your README; corps will always be happy to pay for high quality code and support.
Most people freaking out about being burned out by their open source stuff are generally people who don't open source their stuff. Most open source projects, even very good ones, get very little traffic therefore very few issues. If you can't deal with the occasional email once every few months, turn notifications off.
> But 'screw you'? Not classy.
Saying "Write a test" is essentially saying "screw you". Github has been a blessing, in that it greatly lowered the barrier of entry in filing an issue with a project. It's a blessing for users and it's also a blessing for maintainers if you know how to deal with the influx of issues. Increasing the barrier of entry again is not the solution.
When I myself find bugs I'll certainly PR a fix if I'm able to (and have the time); but I often can't. Most of the time, because the development environment is unknown to me and I have no way to even run the tests (if there are any), let alone write one. So asking someone to get involved and up to speed with a project to the point that they're able to do this, before they can even file an issue with a screenshot that says "the padding looks bad on firefox", that's nonsense. It's even more nonsense when this is just a pet project of yours that most people will not care about.
IMHO, "this is stuff we do give away for free" is an excuse that's too often passed around. It is always true that projects you push to Github for free come with no obligation to care about it, its issues or the pings and cries for help from your desperate potential users. However, you lose the ability to say you're a good open source citizen and you're "giving things away".
A real-world parallel I can make is to the people giving their old/smelly/crappy/torn/bad clothes to charity shops and feeling ever so good about themselves. It's cool you have good intentions, but it's not charity if it ends up in the bin anyway.
Disclaimer: 99% of my work is open source and ends up on Github. A bunch of it sucks and when issues come up, I ignore them or write a 10-second close-reply. A bunch of it is good and I actually care about; and if I care about it, I'm not going to turn off issues just to make myself feel better about having an already-perfect project.
This post just seems like it's trying to class-up a screw-you to their users. I'd prefer people just keep it crude like this rather than try to make it sound like it's somehow a nice thing to do.
So you take code you don't understand and don't want to understand, and you use it to power someone else's business? Doesn't sound safe or professional to me. You don't need to understand everything about every dependency, but you should absolutely be willing to dig in a little
> So you take code you don't understand and don't want to understand, and you use it to power someone else's business? Doesn't sound safe or professional to me
That attitude sounds crippling to being productive. At some point you have to trust code based on usage, brand, peer-reviews etc.
Aside from the fact that everyone relies on code that they don't understand, looking at the code probably isn't going to tell you all that much about how it's meant to work, which is rather important when trying to fix a bug.
Just ran into this at work, I have a manger who was maintaining an internal app and he asked me to take over because there was a bug and he was transitioning away from the techinicial aspects of his job. Anyway like, 2 days later he asks if I've fixed it yet. No I haven't fixed your cobbled together app that has no comments and generic variable names.
I really like Issues as a sanity check: if I'm getting an error or something isn't working, it's nice to know if it's a known issue (or an issue with a workaround). Even if there's no official fix.
If you see Issues as a place where anyone can demand new features or bug fixes for free, then I can see it being overwhelming. But I think most people see it as a community-based repository for thoughts, bugs and ideas.
Totally agree. First thing I do when encountering an issue with a repo is check the Issues and see if anyone else is experiencing it as well. Many times the there is already an active discussion going on, and the thread can contain workarounds or an ETA for the fix.
I predict that this will result in smart-ass pull requests that just take the text that would have gone in an issue and puts it in a comment to the main code file of the project.
Because I want to call my daughter once a week, and publish a Python module that someone else might find useful (which does not mean I want to support them).
I agree that "Pull Requests for Everything" is actually a good idea to encourage programmers to be practical and provide value (I have a pretty strong opinion here... fork, work, pull is always better than passively entering in an issue).
However, this approach is not good for non-technical end users. Remember that there is a lot of end-user facing open source out there and those folks aren't programmers!
It's also not good for technical people with limited time.
I get that help vampires are a thing, but so are prickly developers. As a developer it's your prerogative to be an asshole, but consider the effect on your reputation.
EDIT: I re-read your post a few times and understand what you mean (originally thought you were directing name calling to _me_). Yes, it is important to be flexible with these things and not operate in absolutes. It is very important to be kind and human to others in open source.
As someone who wants to contribute to a project for the first time, there would be nothing more frustrating than spending time creating what I think is a good pull request, only to have it be turned down (which it will be).
Issues help new contributors and repo veterans determine whether it's worth the extra effort to create a pull request. The problem with low-quality issues needs to be addressed by automation and filters, which GitHub hasn't done yet.
Fork it, fix it. Pull in upstream changes until the maintainer fixes it. I suppose file a ticket with a snippet of what I did to fix it so a regular contributor can create a request faster.
If this is a random one-off drive by bug, then why go through the hassle of figuring out what particular standards any individual maintainer wants to follow just to have it turned down, or discover that some regular contributor already patched it while I reading the documentation.
(I mean, I'd love to contribute, but the few times that I've stumbled upon a bug, fixed it, figured everything the maintainer wanted in a pull request... it was aleady fixed by the maintainer and I'd just wasted a lot of time)
As always, the best solution is probably in-between the two extremes, i.e. keep issues open because they are useful for discussions and non-technical people bug reports, but don't be afraid to close PR and issues [1] to avoid the problems like burnout.
Issues are important for a large verity of reasons. This just smacks of arrogance and hostility towards other developers you make your work open to.
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.
"That should go in an issue." => Why? Does it apply for everyone? 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?
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.
In my [limited] experience PR have always been orders of magnitude better [for me] than the average issue. Maybe it's because they focus on improving the project and not user's problems. It is true however that some times they were unsolicited and/or unwanted, however they were still a lot easier to process and review for me as a maintainer.
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).
> This just smacks of arrogance and hostility towards other developers you make your work open to.
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:
Well. If the gift has two buttons, say red and blue. And pressing the sequence blue, red, blue, blue makes the server self destruct. Should there be a way to know that?
Put another way, it's not a gift if it somehow eventually fucks over the receiver. Or perhaps you consider STDs a gift? ;)
> 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 stfu
The 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.
I think you're trying to paint this too black and white. It's perfectly reasonable to be interested in supporting only the proactive user base of your project – that way both parties give and gain something.
> It's perfectly reasonable to be interested in supporting only the proactive user base
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.
>If you only care about the bugs that someone else fixes for you, then you don't actually care.
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.
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.
> The person who says that is either an idiot or doesn't care about the product. There's really no third option.
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.
The Jon Stewart\Rush Limbaugh model of thinking has permeated our culture so much that pointing out issues in the most entertaining manner, can get you so much attention and influence that there is no reason to put in the effort to fix things anymore. You can even become President with no history of fixing anything these days.
Well I'm more a user than a developer but I already have helped others users by responding to issues in someone's else repo.
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...
> is it crazy to think people may have a question? That should go in an issue.
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?
No way. The point of an issue tracker is to be a todo list of bugs and features for the project. Its right there in the name - issue tracker. Ideally when a bug is fixed, I can mark the issue as FIXED and move on to the next one.
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.
The way i deal with those is by closing the issue immediately after answering. If the user still has a follow up question, he is free to leave a comment, and I'll get notified he does.
So the maintainer, who is already doing stuff to provide you with some code or library, has to go out of his way to accomodate you?
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.
This may seem hard to understand if you've never been in a maintainer's position, but "issues" carry a completely different meaning than "questions"
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?"
There are a few repositories where I know that I am one of the users with the most experience, so I watch them and as soon as issues arise I'll try to help debug and pinpoint the issue or even solve it.
Since the Issue-tracker is public, we can have those benefits where we can take weight of the maintainer's shoulder.
In another repo I just do releases to a specific distribution platform and my users basically do all the work.
Issues are very important, how you handle them is more important and that includes acknowledging the difference between discussion / decision making and bug or feature implementation.
People don't get burnt out from people discussing / proposing fixes or improvements, they get burnt out from not having the time or support to fix / implement them or from to much concurrent work and context switching.
My preferred compromise would be if GitHub started sorting issues by "number of upvotes" by default. (Upvotes aren't entirely a thing on GitHub issues, but you can add a thumbs-up emoji which is pretty similar.) For some projects, there is just far more desire for free help than there are people available to help for free. In these cases it is still useful to discover issues that enormous numbers of people have, even if you won't have the bandwidth to deal with a large fraction of them.
This article is from the perspective of the maintainer, but what about the potential contributor?
I've gone down the path described above and I've been equally burned by maintainers who are not interested in the feature, not interested in the bug fix, or in general are inactive.
I want to contribute to projects instead of simply forking and doing my own thing, but before touching the codebase I want to poke the maintainers to see if the feature, bug, etc. is worth the effort.
I'm going to submit an issue before I write a single commit. It's not worth my time understanding a codebase, debugging, submitting a PR just to have it rejected or fade away into the abyss.
I think it's kind of ironic that the author focuses on pull requests. I say this because me and 2 other people created pull requests for a repository fairly widely used, one created by the author. The pull requests were opened in early April and haven't been acknowledged or responded to.
I understand open source maintainers get burnt out. I don't think he should focus on a solution that doesn't even seem to be working for him.
I'm going to quote @BugsJustFindMe in a separate comment, because I think it's a terrific counter-argument to "just open a pull request" as a universal rule:
A month ago I encountered a bug in LibreOffice Writer, which I use because it's really good, where track changes on a docx file wasn't working properly in a particular situation involving the deletion of tracked comments across saves.
QUICK! Find the line of code that caused it! Find the mechanism for creating a test case! I'll wait here.
If the open source project in question is one where users can be reasonably expected to be familiar with your code base, then "propose a fix with a unit test" is fine. But when it's a project whose nature means that users have little to no incentive to look at the code, then the reasonableness of this request decreases with the the size and complexity of the project. And, quoting BugsJustFindMe again:
Caring about FOSS doesn't fix bugs.
I'm a competent developer, but if I ran into a bug in the text-processing utility Pandoc, it's very unlikely I'm going to drop what I'm doing, analyze the source, pinpoint the problem, and submit a PR with a unit test, and oh yes, learn enough Haskell to do all this, and I don't think it would be reasonable to expect me to do so.
It's funny because i actually did exactly what you're talking about once when I ran into a bug in the parsing logic of wikitext tables in pandoc. I read the (extremely well organized) source, having never ever done any haskell before. The fix ended up being a 2 character change, it took me an hour to do, and I didn't really have to learn haskell to do it.
Point being, if you find a bug in a software, as a fellow developer, I think it's reasonable for the maintainer to expect you to at least take a quick look around. Regardless of prior knowledge. You get to learn stuff, and the project maintainers have their load lighten up.
That's nice when possible, but of course when something breaks you never know if it will be one hour or 30, and even then, I think there are a lot of cases where "let the developer know there's an issue" is still worth it, especially if the alternative is "drop it and say nothing because it's too much of a hassle."
What about if they did take a quick look around, and determined that trying to fix it themselves or even find the guilty line would take too long? If I spend hours, days, or even weeks like that every time I found a bug in someone else's code, I'd be doing my own users a severe disservice. I owe it to them to spend my time more productively than that. So if the author's answer is "patch or GTFO" then I've found someone I'd never hire and probably wouldn't even want to interact with.
Real open source is about the community as much as the code. It's not about authors and users each trying to set themselves above the other. True collaboration involves mapping tasks to expertise in the way that results in the greatest overall good. If an expert in an area unilaterally shuts off that conversation, then they're not really helping open source. They're just throwing stuff over the wall and pretending it's open.
It's a good point. This post probably applies much more for libraries, where it's pretty easy to open a pull request with a code example causing the bug.
For batch-processing tools like Pandoc, uploading an example input file, output file, and description of what's wrong in the output would still be very useful.
I guess the nearest analogy for a graphical tool that you use as an end user, rather than a developer, would be recording a video of you triggering the bug :)
>This post probably applies much more for libraries, where it's pretty easy to open a pull request with a code example causing the bug.
Yes, a cursory glance at the author's repositories shows he's talking about libraries for other developers and not consumer apps like LibreOffice/GIMP/VLC/etc used by non-programmers.
I'd almost want to do the opposite and disable PRs, at least until discussion has been had. I'll take discussion before code much more than code before discussion. Heck, I'll oftentimes take pure discussion without any code added over code before discussion.
English is easier than code; don't be the person that puts up barriers.
Ah I think that highly depends on the situation. In some instances a code example makes up for a thousand words, in some examples quite the opposite. The problem is that random PR are often hundreds of lines changed instead of a stub to start a conversation.
So the only people able to report bugs should be contributors? Do whatever you want, I guess, but this sounds like a good way to have a very buggy project.
Perhaps make it easier to attach a failing test, running through the CI process and reporting the result inline? And perhaps allow to vote an issue quality, i.e. demote badly written ones?
Perhaps make it easier to attach a failing test, running through the CI process and reporting the result inline? And perhaps allow to vote an issue quality, i.e. demote badly written ones?
For most projects, this is nothing more than an even higher barrier for users.
As a developer I would LOVE to have everyone submit a failing test or a PR rather than reporting issues but that's just not feasible. Most never will, because there's a learning curve they don't have time for - the language, the tooling, the product itself, Git/github/PRs, etc.
As the project maintainer, that's what I signed up for. It really sucks sometimes, but I'd rather sort through the junk and personally fix the issues people report than funnel everyone through hoops they likely won't spend time on and lose that valuable feedback entirely.
I'm not a programmer, and when I tried to learn it I understood the concept but actually programming something is difficult for me. No idea why this is.
But I can describe an issue, I'm trying to find out how to reproduce an issue. I try to write issue reports which could help a developer what I want or what I think is not working correctly.
It is not perfect, sometimes it is a wrong setting or something else which breaks. But I doubt it is 99% on GitHub.
We track issues by monitoring log files so we can quickly get to the root of the problem. Do you want your developers spending time writing issues on github/trello/etc. or actually coding? You should let the DevOps help the developers do what they are best at.
You get what you pay for when you use open source. You are either paying for it in time and or cash.
It's hard to read the title here (or even the content) and not take it as a categorical statement, but I think this is aimed at a very particular subset of all open source: projects that have one or few maintainers, with relatively little time to devote to maintenance, and that are primarily developer-facing libraries.
For example, saying that you shouldn't allow a user to report an issue without an associated test for a project that is a UI tool isn't feasible, because there's no guarantee that the user is going to know how to write a test. The same goes of a developer-oriented tool that isn't strictly a code library.
The reason a library or framework is a bit different is because these generally fit in the culture of a particular language. That means questions like where a test goes, what the directory structure is, etc, should be relatively understood by a contributor. If the contributor is too new to understand them, this does leave them out in the cold, in a sense---but it's also important not to ignore the value of the developer's time.
Some may say, hey, you don't have to address all issues. And in a basic sense this is true. I have no obligation to respond to issues in my repo. But I'm a human being who likes to follow the golden rule. I want to interact with others if they are willing to engage me, but I also need to keep in mind that I have, say, 5 hours a week to devote to this project. Saying “bring some of your time and I will give you some of mine” doesn't seem rude in this context. Indeed, it seems natural.
If you're just doing a side project and you don't have the time to invest, that's fine. Go use another library, and be well. No hard feelings. If you're using this professionally, you're using my code to save you time, which is to say money in this case. I have zero qualms about asking you to invest a modicum of that time to reduce the few cycles I have that must be devoted to reproducing your issue.
Audience matters. And one must remember that choices like this shape the audience of one's project. If I decide to turn off GH issues and only accept pull requests, that means I've probably reduced my audience. But it also means I've set a tone for that audience. If that's the choice someone wants to make, I think they should be encouraged. After all, the more quality code that is out there to see and learn from, the more we all benefit---even if we don't use a given library directly because its interaction style isn't our own.
134 comments
[ 3.2 ms ] story [ 181 ms ] threadWhile chats can be used for that, they do not make a good job to archive the results a group discussed. For open source projects, this is essential. I often read 1 year+ old issues and they discussions are still accurate and good.
When people chat, they do not have a lot of discipline to document this. Chats are more like a conversation. They are great for two or more people to discuss something but not really good for an outside person who just gets to read the protocol.
SO is not the place to have discussions. You help people for their specific problems. You do not discuss changes there. At best, you leave a link to the issue tracker which deals with that topic.
Is this not literally the point of comments in the code?
But if you close them NOTABUG or WONTFIX, you get a reputation as that guy who just doesn't want to hear about it, what a bastard.
I think there must be a middle way somewhere, for those projects which attract a lot of interest but few or no co-maintainers. But I'm glad I'm not on the hook for finding that middle way, too.
Support is what it is, and it's a two-way street.
Most engineers usually don't have customer support or sales experience, and so don't have the experience to triage and communicate pro-socially. (I sold software as a high-school job and also had my own consultancy at 17.) It's important to push outside one's comfort-zone when young (or old) to acquire skills that will be vital later on.
Post the policies, requirments and desires in contributing.md promenently. (I think a CoC is redundant and tyrannical SJWing.) Setting expectations and not making promises is important.
Finally, there is a cost to FOSS on both supply and demand sides. I just had some company fork the repo of a project I fixed, make a pointless PR and then offer no contributions in a grsec-theft-style way.
PS: Subversion has a great talk about defending the community.
It seems like this would also really help with duplicated error reports which can be burdensome to sift through, and hey if someone else comes along and has the time to fix the bug in question they now have a great means to validate their fix by.
Ugh. No. 999 times out of 1000, the person maintaining the code actually knows what it does and how it works. And if I'm not that person, I don't. I found a problem. The problem affects me. It also probably affects other people.
I'm an intelligent, capable, curious, knowledgeable, and caring professional software developer. I write code for fun, but I write _my_ code for fun. And after that I don't have the energy or the inclination to learn how your shit works deep down where it matters. Because what will take you a minute, will take me a month unless I stop going to work every day.
I will do my best to describe what I was doing when the problem occurred, what I expected to happen, and what happened instead, but screw you if you think I need to understand your codebase or your testing infrastructure in order to report a problem.
That being said, maybe there could be a "found problem, not sure is a bug" flag that defaults to on. Or a warning dialog that says "without example code or detailed repro, this issue probably won't be looked at."
Ugh.
My partner, who doesn't know the first thing about code, understands the value of FOSS. Caring about FOSS doesn't fix bugs.
A month ago (more?) I encountered a bug in LibreOffice Writer, which I use because it's really good, where track changes on a docx file wasn't working properly in a particular situation involving the deletion of tracked comments across saves.
QUICK! Find the line of code that caused it! Find the mechanism for creating a test case! I'll wait here.
Back here in the real world I was able to report the bug and have it fixed by someone who knows what the code does.
But if the developer who gave you the fruits of their labour for free proposes a way to report bugs that works best for them, take it or leave it, or recommend a different approach in a civil tone if you must. But 'screw you'? Not classy.
Also, many Github-hosted projects are critical infrastructure for some people. They will make it as easy as possible for the developer to fix their bugs, if they are rational.
To be fair that's exactly the tone I read the gist in as well. It seems a bit overly hostile to users who may have questions or suggestions but either don't or cannot contribute code for whatever reason.
Emotional comments beget emotional comments.
Fielding a few hundred rude and entitled support requests for your free software can make anyone grumpy. Once you have a few thousand users your inbox is a source of frequent misery.
I disagree. I see them as identical. Yes you're offering a free product but it's still a product, even if you don't want to call it one. The developers are your users. They are the ones using it. But even a developer may not know how your code works well enough to submit a PR.
> Fielding a few hundred rude and entitled support requests for your free software can make anyone grumpy. Once you have a few thousand users your inbox is a source of frequent misery.
For sure but I don't know how you avoid this without also isolating yourself from likely valuable feedback / information. Similar to fielding customer requests for a product a good 96% of the ideas / things customers want are going to be a terrible idea.
If I've learned anything from running products it's this: make it as stupid easy as possible for your customers to give you feedback / get ahold of you. When you do that you're going to get an absolute ton of noise but the bits of signal hidden in there can be amazing and you'll be able to directly help those along the way. From there it's learning how to manage the flow of information coming to you and trying not to take the bad personally (which is very hard to do when it's your baby / code).
It's still nasty to be rude to a developer instead of offering politely worded advice.
Work smart, not hard. If you're getting a lot of support requests (entitled or not), add a paid support option. If you have so much traction already that you constantly have to deal with "hundreds of issues", you're well past the point where you should have done that.
This seems like a reasonable thing to think and say.
A better alternative to the article's suggestion is to state somewhere that it is very likely your issue won't be considered unless it takes the form of a PR. The maintainers, if they don't want to deal with the bug, will say "could you make a PR with a failing test case? Otherwise I don't have the time to work on this".
That way, those who really want the bug fixed have to put in work, but those who just noticed a problem and are kind enough to let the maintainers know can do so easily. Why discourage bug-reporting?
It's the 'screw you' that put my back up.
Then, fine, tone police, I'm not classy.
I am, however, a FOSS developer who understands the value of non-technical contributions to a project.
Know which kinds of bugs don't get fixed? The ones your users never tell you about because you decided to make it hard to report them.
In almost all cases, turning issues off is incredibly counter-productive.
Just be nice, and your accurate advice is more likely to be useful. That's all.
https://en.wikipedia.org/wiki/Tone_policing
My advice is already useful. If someone chooses not to take it because they'd rather tell non-technical users to pound sand, then I hope their project suffers for it.
But apparently they're not allowed to decide what works best for their project as far as bug reports.
Most people freaking out about being burned out by their open source stuff are generally people who don't open source their stuff. Most open source projects, even very good ones, get very little traffic therefore very few issues. If you can't deal with the occasional email once every few months, turn notifications off.
> But 'screw you'? Not classy.
Saying "Write a test" is essentially saying "screw you". Github has been a blessing, in that it greatly lowered the barrier of entry in filing an issue with a project. It's a blessing for users and it's also a blessing for maintainers if you know how to deal with the influx of issues. Increasing the barrier of entry again is not the solution.
When I myself find bugs I'll certainly PR a fix if I'm able to (and have the time); but I often can't. Most of the time, because the development environment is unknown to me and I have no way to even run the tests (if there are any), let alone write one. So asking someone to get involved and up to speed with a project to the point that they're able to do this, before they can even file an issue with a screenshot that says "the padding looks bad on firefox", that's nonsense. It's even more nonsense when this is just a pet project of yours that most people will not care about.
IMHO, "this is stuff we do give away for free" is an excuse that's too often passed around. It is always true that projects you push to Github for free come with no obligation to care about it, its issues or the pings and cries for help from your desperate potential users. However, you lose the ability to say you're a good open source citizen and you're "giving things away".
A real-world parallel I can make is to the people giving their old/smelly/crappy/torn/bad clothes to charity shops and feeling ever so good about themselves. It's cool you have good intentions, but it's not charity if it ends up in the bin anyway.
Disclaimer: 99% of my work is open source and ends up on Github. A bunch of it sucks and when issues come up, I ignore them or write a 10-second close-reply. A bunch of it is good and I actually care about; and if I care about it, I'm not going to turn off issues just to make myself feel better about having an already-perfect project.
This is what we call a strawman. Also, I guarantee that you do exactly what you're glibly dismissing every day of your life.
That attitude sounds crippling to being productive. At some point you have to trust code based on usage, brand, peer-reviews etc.
For a command line tool you can write a shell script demonstrating the problem.
If you see Issues as a place where anyone can demand new features or bug fixes for free, then I can see it being overwhelming. But I think most people see it as a community-based repository for thoughts, bugs and ideas.
There are a minority of very capable people whom need to be able to report security issues and want to contribute valuable additions easily.
I for one just found a CVE-worthy DoS in a popular YAML library, and an working to resolve it and improve testing.
Shutting off the phone and answering machine because of telemarketers isn't "the" solution, because then no one can get ahold of you.
Instead, deal with the shit to get the sugar too. Otherwise, why use GitHub or why have a phone?
However, this approach is not good for non-technical end users. Remember that there is a lot of end-user facing open source out there and those folks aren't programmers!
I get that help vampires are a thing, but so are prickly developers. As a developer it's your prerogative to be an asshole, but consider the effect on your reputation.
Also, I learned what "help vampires" are. Neat.
As someone who wants to contribute to a project for the first time, there would be nothing more frustrating than spending time creating what I think is a good pull request, only to have it be turned down (which it will be).
Issues help new contributors and repo veterans determine whether it's worth the extra effort to create a pull request. The problem with low-quality issues needs to be addressed by automation and filters, which GitHub hasn't done yet.
If this is a random one-off drive by bug, then why go through the hassle of figuring out what particular standards any individual maintainer wants to follow just to have it turned down, or discover that some regular contributor already patched it while I reading the documentation.
(I mean, I'd love to contribute, but the few times that I've stumbled upon a bug, fixed it, figured everything the maintainer wanted in a pull request... it was aleady fixed by the maintainer and I'd just wasted a lot of time)
that's not a very scalable thing to do, as it involves unbounded amount of work. what if the maintainer never pull in your fix?
[1] https://www.jeffgeerling.com/blog/2016/why-i-close-prs-oss-p...
(edit: I know the link talks about PR, but for me it applies to issues asking for features or weird bugs as well)
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.
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).
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:
Put another way, it's not a gift if it somehow eventually fucks over the receiver. Or perhaps you consider STDs a gift? ;)
The 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.
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.
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.
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.
At least some search the issues and answer the question themselves, it's even more valid when the maintainer decided to abandon the project.
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?"
For example, this happened recently:
User 1 kept having an issue, but no idea how to get debug infos.
User 2 had the issue once too and knows how to get debug infos, but can't reproduce the error.
By having both post in the same issue, the root cause and a matching solution were found before the maintainer even saw the issue :)
Since the Issue-tracker is public, we can have those benefits where we can take weight of the maintainer's shoulder.
In another repo I just do releases to a specific distribution platform and my users basically do all the work.
People don't get burnt out from people discussing / proposing fixes or improvements, they get burnt out from not having the time or support to fix / implement them or from to much concurrent work and context switching.
I've gone down the path described above and I've been equally burned by maintainers who are not interested in the feature, not interested in the bug fix, or in general are inactive.
I want to contribute to projects instead of simply forking and doing my own thing, but before touching the codebase I want to poke the maintainers to see if the feature, bug, etc. is worth the effort.
I'm going to submit an issue before I write a single commit. It's not worth my time understanding a codebase, debugging, submitting a PR just to have it rejected or fade away into the abyss.
I understand open source maintainers get burnt out. I don't think he should focus on a solution that doesn't even seem to be working for him.
A month ago I encountered a bug in LibreOffice Writer, which I use because it's really good, where track changes on a docx file wasn't working properly in a particular situation involving the deletion of tracked comments across saves.
QUICK! Find the line of code that caused it! Find the mechanism for creating a test case! I'll wait here.
If the open source project in question is one where users can be reasonably expected to be familiar with your code base, then "propose a fix with a unit test" is fine. But when it's a project whose nature means that users have little to no incentive to look at the code, then the reasonableness of this request decreases with the the size and complexity of the project. And, quoting BugsJustFindMe again:
Caring about FOSS doesn't fix bugs.
I'm a competent developer, but if I ran into a bug in the text-processing utility Pandoc, it's very unlikely I'm going to drop what I'm doing, analyze the source, pinpoint the problem, and submit a PR with a unit test, and oh yes, learn enough Haskell to do all this, and I don't think it would be reasonable to expect me to do so.
Point being, if you find a bug in a software, as a fellow developer, I think it's reasonable for the maintainer to expect you to at least take a quick look around. Regardless of prior knowledge. You get to learn stuff, and the project maintainers have their load lighten up.
Real open source is about the community as much as the code. It's not about authors and users each trying to set themselves above the other. True collaboration involves mapping tasks to expertise in the way that results in the greatest overall good. If an expert in an area unilaterally shuts off that conversation, then they're not really helping open source. They're just throwing stuff over the wall and pretending it's open.
For batch-processing tools like Pandoc, uploading an example input file, output file, and description of what's wrong in the output would still be very useful.
I guess the nearest analogy for a graphical tool that you use as an end user, rather than a developer, would be recording a video of you triggering the bug :)
Yes, a cursory glance at the author's repositories shows he's talking about libraries for other developers and not consumer apps like LibreOffice/GIMP/VLC/etc used by non-programmers.
https://github.com/ryanflorence?tab=repositories
English is easier than code; don't be the person that puts up barriers.
As a developer I would LOVE to have everyone submit a failing test or a PR rather than reporting issues but that's just not feasible. Most never will, because there's a learning curve they don't have time for - the language, the tooling, the product itself, Git/github/PRs, etc.
As the project maintainer, that's what I signed up for. It really sucks sometimes, but I'd rather sort through the junk and personally fix the issues people report than funnel everyone through hoops they likely won't spend time on and lose that valuable feedback entirely.
But I can describe an issue, I'm trying to find out how to reproduce an issue. I try to write issue reports which could help a developer what I want or what I think is not working correctly.
It is not perfect, sometimes it is a wrong setting or something else which breaks. But I doubt it is 99% on GitHub.
You get what you pay for when you use open source. You are either paying for it in time and or cash.
For example, saying that you shouldn't allow a user to report an issue without an associated test for a project that is a UI tool isn't feasible, because there's no guarantee that the user is going to know how to write a test. The same goes of a developer-oriented tool that isn't strictly a code library.
The reason a library or framework is a bit different is because these generally fit in the culture of a particular language. That means questions like where a test goes, what the directory structure is, etc, should be relatively understood by a contributor. If the contributor is too new to understand them, this does leave them out in the cold, in a sense---but it's also important not to ignore the value of the developer's time.
Some may say, hey, you don't have to address all issues. And in a basic sense this is true. I have no obligation to respond to issues in my repo. But I'm a human being who likes to follow the golden rule. I want to interact with others if they are willing to engage me, but I also need to keep in mind that I have, say, 5 hours a week to devote to this project. Saying “bring some of your time and I will give you some of mine” doesn't seem rude in this context. Indeed, it seems natural.
If you're just doing a side project and you don't have the time to invest, that's fine. Go use another library, and be well. No hard feelings. If you're using this professionally, you're using my code to save you time, which is to say money in this case. I have zero qualms about asking you to invest a modicum of that time to reduce the few cycles I have that must be devoted to reproducing your issue.
Audience matters. And one must remember that choices like this shape the audience of one's project. If I decide to turn off GH issues and only accept pull requests, that means I've probably reduced my audience. But it also means I've set a tone for that audience. If that's the choice someone wants to make, I think they should be encouraged. After all, the more quality code that is out there to see and learn from, the more we all benefit---even if we don't use a given library directly because its interaction style isn't our own.