Turning Off GitHub Issues (2016)(gist.github.com)
gist.github.com
Turning Off GitHub Issues (2016)
https://gist.github.com/ryanflorence/8a62abea562ca2896dee
134 comments
Do whatever you want.
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.
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.
> But 'screw you'? Not classy.
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.
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.
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.
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).
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).
You are completely right. No argument.
It's still nasty to be rude to a developer instead of offering politely worded advice.
It's still nasty to be rude to a developer instead of offering politely worded advice.
Fair enough
> 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.
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?
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?
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.
I think I covered that in 'recommend a different approach in a civil tone if you must'.
It's the 'screw you' that put my back up.
It's the 'screw you' that put my back up.
To be fair, that 'screw you' was offered behind a predicate.
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.
> 'screw you'? Not classy.
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.
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.
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.
In almost all cases, turning issues off is incredibly counter-productive.
> the person maintaining the code actually knows what it does and how it works
But apparently they're not allowed to decide what works best for their project as far as bug reports.
But apparently they're not allowed to decide what works best for their project as far as bug reports.
I agree with your argument completely.
Just be nice, and your accurate advice is more likely to be useful. That's all.
Just be nice, and your accurate advice is more likely to be useful. That's all.
> 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.
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.
I'd wager that 75% or more of GitHub projects are things like libraries, not end-user applications. So most people using GitHub are technical users.
There is an obvious meta comment to make here that I leave as an exercise for the reader.
Nah, you're probably mistaken.
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.
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?
This is what we call a strawman. Also, I guarantee that you do exactly what you're glibly dismissing every day of your life.
This is what we call a strawman. Also, I guarantee that you do exactly what you're glibly dismissing every day of your life.
Yeah. I mean, taken to the nth degree, even driving a car is doing that. Surely the parent gets on a bus, drives a car, rides a bicycle, etc.
[deleted]
> 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.
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.
If you can reproduce an issue with your code, you mostly have a failing test already. The open-source product in question seems to be a library.
For a command line tool you can write a shell script demonstrating the problem.
For a command line tool you can write a shell script demonstrating the 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."
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.
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.
You're confusing an application versus an API which is what this thread was about.
joeberon(1)
You can't really compare a huge end-user product to a developer library though. Developers are supposed to be able to write code.
The world isn't all NPM left-pad modules. Code is arbitrarily complex.
There are libraries that are as complex as a large end-user product.
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.
> ... turned off github issues on one of his smaller projects. ...
I don't buy it. Issues are great for users and mantainers in many manyways. I agree that it may be frustrating when you don't want to be a support center for users, but then you should just ignore those.
My favourite approach is to make all issues LABELED, then you can easily focus on those which you need, and let other issues for people who have time to read and help them.
In fact, github issues are indeed for asking for help: "Issues are used to track todos, bugs, feature requests, and more. As issues are created, they’ll appear here in a searchable and filterable list. To get started, you should create an issue." you can also read here some interesting facts https://guides.github.com/features/issues/
My favourite approach is to make all issues LABELED, then you can easily focus on those which you need, and let other issues for people who have time to read and help them.
In fact, github issues are indeed for asking for help: "Issues are used to track todos, bugs, feature requests, and more. As issues are created, they’ll appear here in a searchable and filterable list. To get started, you should create an issue." you can also read here some interesting facts https://guides.github.com/features/issues/
As someone who ends up using other people's code more than fixing other people's code, I try to be sensitive to the issue.
For example, I recently started using someone else's code for a project, largely unchanged. However, I have run into issues. I normally just file these issues under my own github fork, rather than the upstream. If I really can't figure something out, I may choose to file an issue with the upstream, but otherwise I'm trying to only send pull requests instead.
For example, I recently started using someone else's code for a project, largely unchanged. However, I have run into issues. I normally just file these issues under my own github fork, rather than the upstream. If I really can't figure something out, I may choose to file an issue with the upstream, but otherwise I'm trying to only send pull requests instead.
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.
For this, I've seen several large projects push discussions to discourse or stack overflow, which are much better-suited mediums for discussion IMHO.
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.
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.
Who said anything about chat? Parent was talking about https://discourse.org which has effort put into archival / finding old discussions
> 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?
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.
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.
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.
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.
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.
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.
This is arrogant and misguided.
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?
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?
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).
Then put that you don't want to support this in the README and allow others to support themselves if they wish via issues.
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!
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.
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.
Also, I learned what "help vampires" are. Neat.
Also, I learned what "help vampires" are. Neat.
This is from a year ago.
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.
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)
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)
> Pull in upstream changes until the maintainer fixes it
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?
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?
How can we mentor the next gen of code craftsmen/women if we disengage and unplug the phone?
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.
[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)
[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)
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.
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.
> 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:
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 stfu> 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.
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.
> 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.
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.
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. 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.
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.
FWIW `[x] send patches or stfu` is as much black and white.
>doesn't care about the product
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.
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.
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...
Here is the issue if you feel like having a look : https://github.com/pgRouting/osm2pgrouting/issues/167
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
[deleted]
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? ;)
Put another way, it's not a gift if it somehow eventually fucks over the receiver. Or perhaps you consider STDs a gift? ;)
> 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.
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.
How about this,
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?
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.
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.
[deleted]
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.
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?"
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?"
This way hundreds of people can ask the same question over and over?
At least some search the issues and answer the question themselves, it's even more valid when the maintainer decided to abandon the project.
At least some search the issues and answer the question themselves, it's even more valid when the maintainer decided to abandon the project.
Seriously? Every option except emailing me personal is searchable.
>You can even find issues, even MAJOR issues without understanding the code at all.
Yep, even if you are a kindergartener.
https://www.yahoo.com/tech/five-year-old-boy-finds-xbox-secu...
Yep, even if you are a kindergartener.
https://www.yahoo.com/tech/five-year-old-boy-finds-xbox-secu...
"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.
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.
> Why? Does it apply for everyone?
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.
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).
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).
A benefit of Github Issues is that users can also help each other.
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 :)
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 :)
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.
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.
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'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.
If it isn't worth your time to look at the codebase before doing something, why should it be worth the maintainer's time to look at your issue?
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 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.
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.
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.
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.
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.
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."
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 :)
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.
https://github.com/ryanflorence?tab=repositories
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
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.
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?
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.
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.
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.
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.
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.
This seems to be solving a problem that most of us would like to have, so it indeed comes out as arrogant. However look at it from another point of view. Imagine you are working on your job and a manager comes every 30-60 min to your desk to ask you a question about your project, often silly and already answered, breaking all your workflow (guesstimate about the email frequency for popular projects).
Wouldn't you basically device some way to avoid this as much as possible? This seems to be a similar case to popular, single-maintainer OSS. The largest open issues I've had I think was under 10 in 1 day after launching a mid-popular project of mine and luckily it was _after_ launching (so no middle-of-workflow). I cannot even start to imagine the load for a popular dev, and this indeed seems like a good way for a saturated person to offload some of the work to contributors while raising up the entry bar. Cmon, this is even a basic economy rule: supply and demand.
An alternative I've thought is, for purely one-on-one support that only benefits OP, redirect them to some support platform where it can be handled as the developer prefers. In that way it makes it even more viable for the developer to keep working on the project. I just don't love the perverse incentives it generates, but seems better than other alternatives.
Wouldn't you basically device some way to avoid this as much as possible? This seems to be a similar case to popular, single-maintainer OSS. The largest open issues I've had I think was under 10 in 1 day after launching a mid-popular project of mine and luckily it was _after_ launching (so no middle-of-workflow). I cannot even start to imagine the load for a popular dev, and this indeed seems like a good way for a saturated person to offload some of the work to contributors while raising up the entry bar. Cmon, this is even a basic economy rule: supply and demand.
An alternative I've thought is, for purely one-on-one support that only benefits OP, redirect them to some support platform where it can be handled as the developer prefers. In that way it makes it even more viable for the developer to keep working on the project. I just don't love the perverse incentives it generates, but seems better than other alternatives.
For some projects, this makes some sense. For many, it does not.
Issues aren't just off powerless users, their for users who are focussed on the downstream, not your codebase.
Yes, open source means of they want to get into your codebase, they can. It doesn't mean that it should be a prerequisite. Certainly, you'll get less distraction from people opening issues (invalid or otherwise) if you do this, but it's a particularly user-hostile move unless your target user audience has very similar skills to the projects core devs.
Issues aren't just off powerless users, their for users who are focussed on the downstream, not your codebase.
Yes, open source means of they want to get into your codebase, they can. It doesn't mean that it should be a prerequisite. Certainly, you'll get less distraction from people opening issues (invalid or otherwise) if you do this, but it's a particularly user-hostile move unless your target user audience has very similar skills to the projects core devs.
I think the problem is that most people (both users and developers) mistake an issue tracker for a world-writable TODO list. If something goes wrong, it imposes an obligation that someone fix it.
Instead I'm in favor of the fire-and-forget feedback form. This makes it clear that feedback is a pure gift with no obligations on either side. Users: you don't need to look for duplicates or come up with a way to reproduce it. Just talk about what happened to you. Developers: it's just data, do with it what you like. Go wild, run machine learning on it.
Okay, sure, add optional contact info, so the developers can ask for a repro case if they think it's particularly interesting.
(There was a great Paul Ford article about Internet feedback but my searches aren't finding it.)
Instead I'm in favor of the fire-and-forget feedback form. This makes it clear that feedback is a pure gift with no obligations on either side. Users: you don't need to look for duplicates or come up with a way to reproduce it. Just talk about what happened to you. Developers: it's just data, do with it what you like. Go wild, run machine learning on it.
Okay, sure, add optional contact info, so the developers can ask for a repro case if they think it's particularly interesting.
(There was a great Paul Ford article about Internet feedback but my searches aren't finding it.)
This is a very emotionally charged and drastic approach to open source. I am not seeing the benefits of doing this, I can only see downsides:
- Users who are loyal who cannot code are discouraged from voicing issue or asking for help
- Users who can code are dejected because that is the only way they bring up an issue first without coding.
Sometimes the creator is best suited to give advice or to simply do the thing at initial report or query.
- Makes the project look closed off.
- Lack of community and vibrancy, there are no issues, is it finished -- encounter issue -- bad software.
- Why are there no issues, is this developer giving up?The problem with this is that it forces anyone who finds an issue into investing the time to understand the code-base. I'm assuming this developer uses other OSS libraries and I wonder how many of these projects he contributes PRs to if he finds an issue. If you're going to play this way you need to make sure you're not a hypocrite about it (I would have looked but the author didn't actually link to Michael Jackson's project).
It's obviously much more efficient for a few experts to understand each OSS library.
It's obviously much more efficient for a few experts to understand each OSS library.
The author definitely seems to be assuming that every project fits a single profile - small enough to have only a single maintainer, simple enough that a non-specialized programmer can navigate it or create a patch easily, etc. If turning off issues works for people like that, good for them. But this kind of thing really grates.
"If we want to include more people in open source, I can't think of a better way than getting open source code on their machines and into their editors."
Wrong pronoun. The author presumes to speak for "us" in open source, but doesn't really represent anyone but himself. For most of "us" getting more people involved requires quite a bit of work explaining how the code works, how the tests work, and so on. Anybody who's not putting in that kind of effort, even if it's because they don't need to on their personal hobby project, should STFU about what "we" can or should do to get more people involved in open source. Try working on a big, complex, multi-person project in a less-obvious specialty, and see if "just load this up in your editor and get back to me when you have a patch" will work.
"If we want to include more people in open source, I can't think of a better way than getting open source code on their machines and into their editors."
Wrong pronoun. The author presumes to speak for "us" in open source, but doesn't really represent anyone but himself. For most of "us" getting more people involved requires quite a bit of work explaining how the code works, how the tests work, and so on. Anybody who's not putting in that kind of effort, even if it's because they don't need to on their personal hobby project, should STFU about what "we" can or should do to get more people involved in open source. Try working on a big, complex, multi-person project in a less-obvious specialty, and see if "just load this up in your editor and get back to me when you have a patch" will work.
I can see this working if your project's target audience is developers. But for most projects where the target audience is just regular users, most vastly prefer a simple CRUD form to create an issue.
Checkout some of the issue I have in my repo: https://github.com/sergiotapia/magnetissimo
They are valuable insight into the problems people have, and if I asked them to open a PR for every problem I would most likely have 1 or 2 at most issues open. Everybody loses.
Checkout some of the issue I have in my repo: https://github.com/sergiotapia/magnetissimo
They are valuable insight into the problems people have, and if I asked them to open a PR for every problem I would most likely have 1 or 2 at most issues open. Everybody loses.
Many open source libraries that I end up using have terrible documentation, and borderline meaningless commit messages. Issues are one of the only places I can go to find any sort of useful explanation or backstory on how a particular part of a library should work.
I'd love it if I didn't have to use GitHub Issues as an ad hoc FAQ document, but it's better than nothing.
I'd love it if I didn't have to use GitHub Issues as an ad hoc FAQ document, but it's better than nothing.
What a weird opening sentence. Unless he was planning on making a Michael Jackson joke (quick skim ~ none?) or just wanted to call attention to the "fun" point that he has a friend named Michael Jackson, I don't see why it wouldn't be more prudent to just open with "My friend Michael..." rather than appearing to set up a Checkov's gun with no payoff (even if just a quick "(heh)" after the name).
(I'm aware the gh issues discussion is the more valuable one to most, but as I don't worry about gh much I doubt my thoughts on it haven't already been covered by comments here and before)
(I'm aware the gh issues discussion is the more valuable one to most, but as I don't worry about gh much I doubt my thoughts on it haven't already been covered by comments here and before)
His problem can easily be fixed by adding a FAQ and Guide to Contributing and Opening Issues doc.
Then tell users to read both before opening an issue. Set some rules on how you want the issues written, tone of voice, etc.
A project without issue is a project nobody is using.
Then tell users to read both before opening an issue. Set some rules on how you want the issues written, tone of voice, etc.
A project without issue is a project nobody is using.
It's better to simply leave issues enabled, but put in place rules for what constitutes a valid issue, noting that other issues will be closed without further consideration. Well-reported issues are gold, and the others are easy to ignore.
I get the sentiment, but bug reports are distinct from test cases. Better to track the bugs inside the repo, e.g. using something like bugseverywhere or artemis.
Making code public does not imply support. Of any kind. Those are very, very different things.
If you don't want to deal with feedback on your open source project, fine, just state it in the README "We don't care about your issues unless you are a developer who can contribute.", but don't try to veil this indifference with some ill thought out excuses for why it is a best-practice to do so.
The problem - and I use the word "problem" here very loosely - is the ease of access that GitHub provides. Even back in the heyday of mailing lists there was noise to deal with, but nowhere near the amount maintainers on GitHub can find themselves dealing with these days.
Formal bug reports are certainly important, however as the author points out the Issues feature in GitHub too often gets used for simple questions that could have been answered reading the docs, searching past issues, or just googling it.
The templates GitHub added last year have been a godsend in terms of improving things but I'd like to see an option to make filling out the template mandatory.
Formal bug reports are certainly important, however as the author points out the Issues feature in GitHub too often gets used for simple questions that could have been answered reading the docs, searching past issues, or just googling it.
The templates GitHub added last year have been a godsend in terms of improving things but I'd like to see an option to make filling out the template mandatory.
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.