7 ms·

An Open Source Author's Lament

127 points by jnwng 14y ago

lowboy 14y ago
Github needs an option for repo owners to replace the "Please review the guidelines for contributing to this repository" text on the issue submission page. Or maybe even an obnoxious interstitial page where you have to confirm that you've read the repo-specific notice before being taken to the page with the issue submission form.
- mmahemoff 14y ago
  Chrome bug tracker (crbug.com) recently added a wizard for new issues, where you have to check a box that you've searched through existing issues as well as provide some background info.
jashkenas 14y ago
Whoa there mods -- please put the title of this back to the original "An Open Source Author's Lament". It's linking to a specific comment, not to the ticket in general. Edit: Thanks!
drivebyacct2 14y ago
>dfkaye https://github.com/jashkenas/coffee-script/issues/2864#issuecomment-15160136 https://github.com/jashkenas/coffee-script/issues/2864#issue... Is that guy serious?
lrem 14y ago
Isn't this just a failure in the art of delegation? Having every maintainer read every ticket clearly doesn't scale...
- jashkenas 14y ago
  I wish it were. Unfortunately, not all projects are blessed with such lovely and helpful maintainers like Sam, Brad, Tim (for Backbone), and Nami-Doc, Michael, and Demian (for CoffeeScript), just to mention a few. In practice, you'll rarely find a jQuery ticket (for example) that doesn't have to be read in the end by Dave, and you'll rarely find a Bootstrap ticket that doesn't have to be read by Mark: https://github.com/twitter/bootstrap/issues/7334 https://github.com/twitter/bootstrap/issues/7334 https://github.com/twitter/bootstrap/issues/7333 https://github.com/twitter/bootstrap/issues/7333 https://github.com/twitter/bootstrap/issues/7325 https://github.com/twitter/bootstrap/issues/7325 https://github.com/twitter/bootstrap/issues/7320 https://github.com/twitter/bootstrap/issues/7320 https://github.com/twitter/bootstrap/issues/7324 https://github.com/twitter/bootstrap/issues/7324 https://github.com/twitter/bootstrap/issues/7312 https://github.com/twitter/bootstrap/issues/7312 https://github.com/twitter/bootstrap/issues/7302 https://github.com/twitter/bootstrap/issues/7302 https://github.com/twitter/bootstrap/issues/7296 https://github.com/twitter/bootstrap/issues/7296 https://github.com/twitter/bootstrap/issues/7290 https://github.com/twitter/bootstrap/issues/7290 https://github.com/twitter/bootstrap/issues/7282 https://github.com/twitter/bootstrap/issues/7282 https://github.com/twitter/bootstrap/issues/7279 https://github.com/twitter/bootstrap/issues/7279 https://github.com/twitter/bootstrap/issues/7265 https://github.com/twitter/bootstrap/issues/7265 ... and those are just a random smattering from the past week!
  - shurane 14y ago
    But for simple issues, is it necessary for Mark or Dave to go through the tickets themselves? The examples you gave didn't have to be personally closed by Mark. If people are willing to contribute, wouldn't they also be willing to help you out with all the gruntwork? Is it just a matter of setting it up with Github, which may or may not support that level of granularity? Man, that really sucks.
  - knite 14y ago
    I upvoted the original submission because I think this is an interesting and important problem for maintainers of large OSS projects. It would be nice for Github to provide some administrative tools or interface changes to make maintainers' lives easier. However, I am tentatively in agreement with the posters who suggest that this is largely a management problem. I've read the examples you linked, Jeremy, but I don't see why those issues (and the majority of issues on large-scale projects) require review by the head maintainer/BDFL. Most of these issues are chaff - either they're not reproducible, poorly explained, or requesting features which have already been discussed and dismissed. It shouldn't need Mark's or your time to say "nope, works for us" or "already decided we're not doing that". At Coffeescript/Backbone/Bootstrap/etc levels of activity, you have a huge, vibrant community. Out of all those thousands of developers, surely there are a couple of active contributors who can't commit to the project at the "core dev" level but who have to skill and time to take on the role of "issue maintainer"?
    - jashkenas 14y ago
      That's entirely right. This is more of a problem with the current workflow of the current implementation of GitHub Issues, for large projects -- it's absolutely something that can be solved.
      - gregmolnar 14y ago
        Maybe a kinda "Flag for close" button on the github interface would help with this. Than the community would be able to flag issues and the core devs could de-prioritize the flagged ones or if there are flags from enough members they can just close it without reading it assuming that many member is probably right?
stevensanderson 14y ago
I can so easily relate to this. Although I deal with only a fraction of the GitHub traffic that Jeremy does, it's still demoralising at times, and dominates the effort I spend on OSS. It's the equivalent of every widget owner having the CEO's home number, and it being culturally normal to call to discuss any problem or even idea for minor tweak. One possibility I've wondered about is making the GitHub issues list read-only, except for project maintainers. Then bug reports and feature requests would go initially only to the project's forum or IRC channel, which has much less maintenance cost, because threads or conversations don't need to be "closed". If they attract enough attention (because they describe a painful bug, or a really good idea), then a project maintainer is likely to notice and choose to file an issue.
guywithabike 14y ago
In one message, @humanchimp says: Ok thanks for closing my issue. @humanchimp's very next comment: The sarcasm is not appreciated, [...]
- Jare 14y ago
  It's the 'my' that rang the alarm bells in my head. Feelings of ownership are often followed by entitlement, and that's never a good mentality.
  - caipre 14y ago
    I guess you don't like Perl much then. ducks
rogerbinns 14y ago
A big problem with the Github issue tracker is that there are no priorities. Ideally what you want is someone to do the triage of new reports, prioritise them and then have the main team see them. Sorting by priority then gives an idea of outstanding work (or probably sorting by milestone and then by priority). Bug tracking in general in volunteer communities is terrible. There will be languishing items, duplicates, missed items, really terrible reports, average ones, and a few very good ones. It is hard to be happy with the state no matter side of the reports you are on. (It hasn't been too different in some companies I've worked either.) Hopefully someone can figure out how to solve the problem. I'd imagine some combination of stackoverflow (voting, commenting, karma), trello (visibility and sorting), mailing lists (most communication) and reporting tools all combined would work.
- qznc 14y ago
  What choice to you have besides getting somebody else to do the triage? I think the problem is that users do not consider this a fun activity to help their open source project.
  - Cthulhu_ 14y ago
    > What choice to you have besides getting somebody else to do the triage? I was going to say; if Jeremy has trouble wading through hundreds of issues, he should level up as an OS developer and start asking for help, him becoming the project leader, the underlings distributing the workload of going through issues, escalating the actually important ones to the boss. This isn't exclusive to OS development either, it's what happens and should happen in real life with management and whatnot. Of course, overdoing it causes five levels of management between Joe Developer and The Boss in the corporate world. tl;dr: delegate
    - saurik 14y ago
      This isn't an "issue": it is a "discussion"; people are using his issue tracking system as a discussion forum for ideas. This is the kind of thing that for most projects would happen exactly as he describes: on a mailing list or on IRC, not inside of the issue tracker. I feel like claiming he needs to "level up" is kind of harsh: I'd argue what he's doing right here actually is "leveling up"... as a moderator, directing people to the right place to have different kinds of interactions.
benatkin 14y ago
Here's the author of this issue being touchy in another thread: https://github.com/jashkenas/coffee-script/issues/2836#issuecomment-14944179 https://github.com/jashkenas/coffee-script/issues/2836#issue... > Before blaming me further This reminds me of DHH's "Rails is Omakase" post. http://david.heinemeierhansson.com/2012/rails-is-omakase.html http://david.heinemeierhansson.com/2012/rails-is-omakase.htm... "But there's a fine line between a friendly suggestion and a belligerent diner." That's exactly how humanchimp is acting – belligerent. It's one type of annoying behavior that's easy to recognize but hard to defend against.
lifeisstillgood 14y ago
We seem to be forgetting the explicit reasons git was created - to remove the technical commit restrictions and make it a social committing ability - that is the social leader of the project only needs accept commits from people he filters And we are forgetting the long lessons of bug tracking in the wild - don't overload the use cases 1. Can github explicitly limit the people able to make a issue to those who have ticked the box saying I have read the Commiting.txt file 2. Have a PEP style improvements process - want to make an improvement - great write up a 1000 word doc saying what and why with working code. Don't make a paragraph of a suggestion. Put working code behind the proposal. 3. Write that in big letters in committing.txt 4. In committing.txt require a issue has x number of +1 from different accounts before you even look at it. The must be some api hacks to help that 5. in committing.txt require people submit a bug using your own test harness output - at least you know they ran the test harness Edit: on kernel mailing list Torvalds explicitly warned maintainers of the dangers of just this - I cannot find the link but iirr it went something like "you can spend 12 hours a day on email but eventually you will burn out - not maybe, will- so just find five people you can trust and only pull from them - and they find five they can trust and so on" This is (mostly) voluntary effort so killing ourselves for it is foolish - plus it is highly unlikely random joe comment will produce the next great coffee script improvemt. - so focus on a tight group of devs and keep writing great code Good luck
- shurane 14y ago
  Hey, makes sense. What @jashkenas has is a centralized place where tickets are filed, instead of submitting issues, tasks, code to other maintainers, who then merge those into jashkena's work. Eventually everything trickles into jashkena's master branch.
- benaiah 14y ago
  Arguably, most of what you have just described is already implemented as pull requests. In the cases where it isn't, I agree with you pretty much completely. This definitely should be optional, but it would help the social leaders of large projects tremendously. IANA social leader of a large open-source project, though, so I'm not really an authority on the subject.
- 14y ago
laurent123456 14y ago
Many developers would be glad to have 75 pull requests a day on their open source projects, it doesn't seem to make sense to complain about it. I can understand his frustration but maybe he just needs to delegate more work, give commit access, find reliable moderators, etc. it shouldn't be that hard with so much interest in the project.
- doppel 14y ago
  While these are excellent suggestions, if you check out the links he makes to other posts there is a LOT of noise in there that he has to wade through, weigh (open/close/discuss) and take action on. My interpretation of it is that he is lamenting how the issues list has become a catch-all for everything from bug fixes (which are fine) to random non-Backbone related development questions, and looking at the issues at lot of them are in the form of "HALP!" with a very light description.
  - jaggederest 14y ago
    Honestly, this all comes back to the issue "Why is the person who does the majority of the programming also doing the majority of the customer support?" Let someone else close issues that are offtopic or a bad idea. He insists that this means that 'you have more people who have to read everything' but it absolutely does not. It means you need to learn to trust that if so-and-so closed it, it should be closed.
    - adekok 14y ago
      > "Why is the person who does the majority of the programming also doing the majority of the customer support?" Because no one else cares. It's a huge problem in Open Source projects. Most of them are single-person projects. One person does the coding, bug fixes, releases, documentation, and answering questions on the list. For the OP on github, he needs to learn triage. There is no reason to be polite to people who can't be bothered to read the documentation. My mantra is "if you don't care enough to put some effort into it, then I don't care, either. Go fix it yourself." He needs to quickly read issues, and close the idiotic ones with minimal comment. If they keep arguing, block them. A good project maintainer can't afford to waste his time on loud-mouthed idiots. There are too many quietly competent people who need his time.
hayksaakian 14y ago
Issues need a priority/voting system a lá reddit. People who run the project could set a minimum for getting notifications about issues. Different maintainers could have different minimums.
- mofle 14y ago
  Issues 1.0 had voting, but it was removed in Issues 2.0
- Afforess 14y ago
  Because reddit voting is an excellent example of user moderation. /sarcasm
Perceptes 14y ago
Perhaps a queueing or escalation system in GitHub Issues would help with this. Joe Blow developer creates a new issue, and it goes into a queue that does not make a notification appear for Jeremy, but for some other project developers he delegates to. If these other project devs determine the issue from Joe Blow to be worthy of Jeremy's time, they mark it to be added to the main issue queue and Jeremy gets a notification. If not, they direct Joe Blow to the proper channel for his issue, if applicable, and close it.
jaggederest 14y ago
I wish the bugs were tracked in Git. a more-or-less simple text file with the bug and various metadata could make use of the distributed nature of Git. Submit all bugs as pull requests to subsidiary repositories, important ones get merged upstream (along with their fixes, preferably) An example of this sort of 'subsidiary repo for special purposes which is merged to upstream' is the docrails repository: https://github.com/lifo/docrails https://github.com/lifo/docrails This does require the subsidiary repository to have more liberal commit access (probably 'all users of project with a github account'), but hey, it's subsidiary.
JonnieCache 14y ago
Perhaps contributing.md should be embedded above the new issue form in the same way that readme.md is embedded on the project homepage.
- derekerdmann 14y ago
  Great idea. Stack Overflow uses the same concept when you're asking a new question on the site, and I believe it helps the quality of answers tremendously. Making contributing.md visible when creating issues would be incredibly helpful.
- Serow225 14y ago
  Send your idea to support@github.com; I did that for a suggestion I had regarding the github UI, and got a nice response back in a day or two. They also confirmed that this is their desired way to collect feedback/suggestions.
rbanffy 14y ago
Is it really that hard to get people don't write open source to solve your problems? What state of mind makes people believe they are entitled to someone else's time? When I write software, I'm solving my problems. When I write open-source software, I'm still solving my problems, but I find whatever I'm writing may be useful to someone else, so, feel free to use it and, perhaps, even join the effort to continue better solving our problems. I will not solve your problems for you. What's wrong with these people?
- crusso 14y ago
  If you're doing it only to solve your own problems then why open source it? Obviously, the motivation to help others, contribute to something as a community, show off your skills, etc. are drivers besides just solving your own problems. For some developers, solving their own problems has very little to do with why they work on open source projects.
  - rbanffy 14y ago
    Contributing to a community or showing off my skills would also fall under "solving my problems". It's perfectly logical to assume I may want better communities and recognition and the lack of either to be problems I may be inclined to solve.
    - crusso 14y ago
      So your original post is meaningless since you decried solving other peoples' problems... but solving other peoples' problems could completely fall under the set of "solving your problems". "Is anything we do truly altruistic?" is a fun question philosophically, but makes for really circular/meaningless HN comments.
      - rbanffy 14y ago
        I'm not solving someone else's problem unless it either is also my problem or solving it solves another problem I have. In this case it's obvious adding the requested feature solves no problem of the maintainer.
crusso 14y ago
In your .md file, specify that issues should be researched, follow a certain formatting and include certain key words. The formatted research should include the search terms used when looking for previous issues and list the results found, including a short reason for why those issues didn't apply. Any issues submitted that didn't include the formatting, research, and key words are put into a bin where volunteer users can go through them and correct the problems. Basically, I'm saying to demand better from the people you're looking to help, automate as much as you can, and delegate some of the work to those who can't code but can contribute in some way.
j_s 14y ago
Google Code uses stars, Codeplex allows votes... that seems to be the minimum effort to support crowdsourcing bug prioritization. GitHub's issues haven't gotten much love.
lucian303 14y ago
Well, considering the project, less work is not a bad thing.

127 points by jnwng 14y ago

Github needs an option for repo owners to replace the "Please review the guidelines for contributing to this repository" text on the issue submission page. Or maybe even an obnoxious interstitial page where you have to confirm that you've read the repo-specific notice before being taken to the page with the issue submission form.

mmahemoff 14y ago
Chrome bug tracker (crbug.com) recently added a wizard for new issues, where you have to check a box that you've searched through existing issues as well as provide some background info.

jashkenas 14y ago

Whoa there mods -- please put the title of this back to the original "An Open Source Author's Lament". It's linking to a specific comment, not to the ticket in general. Edit: Thanks!

drivebyacct2 14y ago

>dfkaye https://github.com/jashkenas/coffee-script/issues/2864#issuecomment-15160136 https://github.com/jashkenas/coffee-script/issues/2864#issue... Is that guy serious?

lrem 14y ago

Isn't this just a failure in the art of delegation? Having every maintainer read every ticket clearly doesn't scale...

jashkenas 14y ago
I wish it were. Unfortunately, not all projects are blessed with such lovely and helpful maintainers like Sam, Brad, Tim (for Backbone), and Nami-Doc, Michael, and Demian (for CoffeeScript), just to mention a few. In practice, you'll rarely find a jQuery ticket (for example) that doesn't have to be read in the end by Dave, and you'll rarely find a Bootstrap ticket that doesn't have to be read by Mark: https://github.com/twitter/bootstrap/issues/7334 https://github.com/twitter/bootstrap/issues/7334 https://github.com/twitter/bootstrap/issues/7333 https://github.com/twitter/bootstrap/issues/7333 https://github.com/twitter/bootstrap/issues/7325 https://github.com/twitter/bootstrap/issues/7325 https://github.com/twitter/bootstrap/issues/7320 https://github.com/twitter/bootstrap/issues/7320 https://github.com/twitter/bootstrap/issues/7324 https://github.com/twitter/bootstrap/issues/7324 https://github.com/twitter/bootstrap/issues/7312 https://github.com/twitter/bootstrap/issues/7312 https://github.com/twitter/bootstrap/issues/7302 https://github.com/twitter/bootstrap/issues/7302 https://github.com/twitter/bootstrap/issues/7296 https://github.com/twitter/bootstrap/issues/7296 https://github.com/twitter/bootstrap/issues/7290 https://github.com/twitter/bootstrap/issues/7290 https://github.com/twitter/bootstrap/issues/7282 https://github.com/twitter/bootstrap/issues/7282 https://github.com/twitter/bootstrap/issues/7279 https://github.com/twitter/bootstrap/issues/7279 https://github.com/twitter/bootstrap/issues/7265 https://github.com/twitter/bootstrap/issues/7265 ... and those are just a random smattering from the past week!
- shurane 14y ago
  But for simple issues, is it necessary for Mark or Dave to go through the tickets themselves? The examples you gave didn't have to be personally closed by Mark. If people are willing to contribute, wouldn't they also be willing to help you out with all the gruntwork? Is it just a matter of setting it up with Github, which may or may not support that level of granularity? Man, that really sucks.
- knite 14y ago
  I upvoted the original submission because I think this is an interesting and important problem for maintainers of large OSS projects. It would be nice for Github to provide some administrative tools or interface changes to make maintainers' lives easier. However, I am tentatively in agreement with the posters who suggest that this is largely a management problem. I've read the examples you linked, Jeremy, but I don't see why those issues (and the majority of issues on large-scale projects) require review by the head maintainer/BDFL. Most of these issues are chaff - either they're not reproducible, poorly explained, or requesting features which have already been discussed and dismissed. It shouldn't need Mark's or your time to say "nope, works for us" or "already decided we're not doing that". At Coffeescript/Backbone/Bootstrap/etc levels of activity, you have a huge, vibrant community. Out of all those thousands of developers, surely there are a couple of active contributors who can't commit to the project at the "core dev" level but who have to skill and time to take on the role of "issue maintainer"?
  - jashkenas 14y ago
    That's entirely right. This is more of a problem with the current workflow of the current implementation of GitHub Issues, for large projects -- it's absolutely something that can be solved.
    - gregmolnar 14y ago
      Maybe a kinda "Flag for close" button on the github interface would help with this. Than the community would be able to flag issues and the core devs could de-prioritize the flagged ones or if there are flags from enough members they can just close it without reading it assuming that many member is probably right?

stevensanderson 14y ago

I can so easily relate to this. Although I deal with only a fraction of the GitHub traffic that Jeremy does, it's still demoralising at times, and dominates the effort I spend on OSS. It's the equivalent of every widget owner having the CEO's home number, and it being culturally normal to call to discuss any problem or even idea for minor tweak. One possibility I've wondered about is making the GitHub issues list read-only, except for project maintainers. Then bug reports and feature requests would go initially only to the project's forum or IRC channel, which has much less maintenance cost, because threads or conversations don't need to be "closed". If they attract enough attention (because they describe a painful bug, or a really good idea), then a project maintainer is likely to notice and choose to file an issue.

guywithabike 14y ago

In one message, @humanchimp says: Ok thanks for closing my issue. @humanchimp's very next comment: The sarcasm is not appreciated, [...]

Jare 14y ago
It's the 'my' that rang the alarm bells in my head. Feelings of ownership are often followed by entitlement, and that's never a good mentality.
- caipre 14y ago
  I guess you don't like Perl much then. ducks

rogerbinns 14y ago

A big problem with the Github issue tracker is that there are no priorities. Ideally what you want is someone to do the triage of new reports, prioritise them and then have the main team see them. Sorting by priority then gives an idea of outstanding work (or probably sorting by milestone and then by priority). Bug tracking in general in volunteer communities is terrible. There will be languishing items, duplicates, missed items, really terrible reports, average ones, and a few very good ones. It is hard to be happy with the state no matter side of the reports you are on. (It hasn't been too different in some companies I've worked either.) Hopefully someone can figure out how to solve the problem. I'd imagine some combination of stackoverflow (voting, commenting, karma), trello (visibility and sorting), mailing lists (most communication) and reporting tools all combined would work.

qznc 14y ago
What choice to you have besides getting somebody else to do the triage? I think the problem is that users do not consider this a fun activity to help their open source project.
- Cthulhu_ 14y ago
  > What choice to you have besides getting somebody else to do the triage? I was going to say; if Jeremy has trouble wading through hundreds of issues, he should level up as an OS developer and start asking for help, him becoming the project leader, the underlings distributing the workload of going through issues, escalating the actually important ones to the boss. This isn't exclusive to OS development either, it's what happens and should happen in real life with management and whatnot. Of course, overdoing it causes five levels of management between Joe Developer and The Boss in the corporate world. tl;dr: delegate
  - saurik 14y ago
    This isn't an "issue": it is a "discussion"; people are using his issue tracking system as a discussion forum for ideas. This is the kind of thing that for most projects would happen exactly as he describes: on a mailing list or on IRC, not inside of the issue tracker. I feel like claiming he needs to "level up" is kind of harsh: I'd argue what he's doing right here actually is "leveling up"... as a moderator, directing people to the right place to have different kinds of interactions.

benatkin 14y ago

Here's the author of this issue being touchy in another thread: https://github.com/jashkenas/coffee-script/issues/2836#issuecomment-14944179 https://github.com/jashkenas/coffee-script/issues/2836#issue... > Before blaming me further This reminds me of DHH's "Rails is Omakase" post. http://david.heinemeierhansson.com/2012/rails-is-omakase.html http://david.heinemeierhansson.com/2012/rails-is-omakase.htm... "But there's a fine line between a friendly suggestion and a belligerent diner." That's exactly how humanchimp is acting – belligerent. It's one type of annoying behavior that's easy to recognize but hard to defend against.

lifeisstillgood 14y ago

We seem to be forgetting the explicit reasons git was created - to remove the technical commit restrictions and make it a social committing ability - that is the social leader of the project only needs accept commits from people he filters And we are forgetting the long lessons of bug tracking in the wild - don't overload the use cases 1. Can github explicitly limit the people able to make a issue to those who have ticked the box saying I have read the Commiting.txt file 2. Have a PEP style improvements process - want to make an improvement - great write up a 1000 word doc saying what and why with working code. Don't make a paragraph of a suggestion. Put working code behind the proposal. 3. Write that in big letters in committing.txt 4. In committing.txt require a issue has x number of +1 from different accounts before you even look at it. The must be some api hacks to help that 5. in committing.txt require people submit a bug using your own test harness output - at least you know they ran the test harness Edit: on kernel mailing list Torvalds explicitly warned maintainers of the dangers of just this - I cannot find the link but iirr it went something like "you can spend 12 hours a day on email but eventually you will burn out - not maybe, will- so just find five people you can trust and only pull from them - and they find five they can trust and so on" This is (mostly) voluntary effort so killing ourselves for it is foolish - plus it is highly unlikely random joe comment will produce the next great coffee script improvemt. - so focus on a tight group of devs and keep writing great code Good luck

shurane 14y ago
Hey, makes sense. What @jashkenas has is a centralized place where tickets are filed, instead of submitting issues, tasks, code to other maintainers, who then merge those into jashkena's work. Eventually everything trickles into jashkena's master branch.
benaiah 14y ago
Arguably, most of what you have just described is already implemented as pull requests. In the cases where it isn't, I agree with you pretty much completely. This definitely should be optional, but it would help the social leaders of large projects tremendously. IANA social leader of a large open-source project, though, so I'm not really an authority on the subject.
14y ago

laurent123456 14y ago

Many developers would be glad to have 75 pull requests a day on their open source projects, it doesn't seem to make sense to complain about it. I can understand his frustration but maybe he just needs to delegate more work, give commit access, find reliable moderators, etc. it shouldn't be that hard with so much interest in the project.

doppel 14y ago
While these are excellent suggestions, if you check out the links he makes to other posts there is a LOT of noise in there that he has to wade through, weigh (open/close/discuss) and take action on. My interpretation of it is that he is lamenting how the issues list has become a catch-all for everything from bug fixes (which are fine) to random non-Backbone related development questions, and looking at the issues at lot of them are in the form of "HALP!" with a very light description.
- jaggederest 14y ago
  Honestly, this all comes back to the issue "Why is the person who does the majority of the programming also doing the majority of the customer support?" Let someone else close issues that are offtopic or a bad idea. He insists that this means that 'you have more people who have to read everything' but it absolutely does not. It means you need to learn to trust that if so-and-so closed it, it should be closed.
  - adekok 14y ago
    > "Why is the person who does the majority of the programming also doing the majority of the customer support?" Because no one else cares. It's a huge problem in Open Source projects. Most of them are single-person projects. One person does the coding, bug fixes, releases, documentation, and answering questions on the list. For the OP on github, he needs to learn triage. There is no reason to be polite to people who can't be bothered to read the documentation. My mantra is "if you don't care enough to put some effort into it, then I don't care, either. Go fix it yourself." He needs to quickly read issues, and close the idiotic ones with minimal comment. If they keep arguing, block them. A good project maintainer can't afford to waste his time on loud-mouthed idiots. There are too many quietly competent people who need his time.

hayksaakian 14y ago

Issues need a priority/voting system a lá reddit. People who run the project could set a minimum for getting notifications about issues. Different maintainers could have different minimums.

mofle 14y ago
Issues 1.0 had voting, but it was removed in Issues 2.0
Afforess 14y ago
Because reddit voting is an excellent example of user moderation. /sarcasm

Perceptes 14y ago

Perhaps a queueing or escalation system in GitHub Issues would help with this. Joe Blow developer creates a new issue, and it goes into a queue that does not make a notification appear for Jeremy, but for some other project developers he delegates to. If these other project devs determine the issue from Joe Blow to be worthy of Jeremy's time, they mark it to be added to the main issue queue and Jeremy gets a notification. If not, they direct Joe Blow to the proper channel for his issue, if applicable, and close it.

jaggederest 14y ago

I wish the bugs were tracked in Git. a more-or-less simple text file with the bug and various metadata could make use of the distributed nature of Git. Submit all bugs as pull requests to subsidiary repositories, important ones get merged upstream (along with their fixes, preferably) An example of this sort of 'subsidiary repo for special purposes which is merged to upstream' is the docrails repository: https://github.com/lifo/docrails https://github.com/lifo/docrails This does require the subsidiary repository to have more liberal commit access (probably 'all users of project with a github account'), but hey, it's subsidiary.

JonnieCache 14y ago

Perhaps contributing.md should be embedded above the new issue form in the same way that readme.md is embedded on the project homepage.

derekerdmann 14y ago
Great idea. Stack Overflow uses the same concept when you're asking a new question on the site, and I believe it helps the quality of answers tremendously. Making contributing.md visible when creating issues would be incredibly helpful.
Serow225 14y ago
Send your idea to support@github.com; I did that for a suggestion I had regarding the github UI, and got a nice response back in a day or two. They also confirmed that this is their desired way to collect feedback/suggestions.

rbanffy 14y ago

Is it really that hard to get people don't write open source to solve your problems? What state of mind makes people believe they are entitled to someone else's time? When I write software, I'm solving my problems. When I write open-source software, I'm still solving my problems, but I find whatever I'm writing may be useful to someone else, so, feel free to use it and, perhaps, even join the effort to continue better solving our problems. I will not solve your problems for you. What's wrong with these people?

crusso 14y ago
If you're doing it only to solve your own problems then why open source it? Obviously, the motivation to help others, contribute to something as a community, show off your skills, etc. are drivers besides just solving your own problems. For some developers, solving their own problems has very little to do with why they work on open source projects.
- rbanffy 14y ago
  Contributing to a community or showing off my skills would also fall under "solving my problems". It's perfectly logical to assume I may want better communities and recognition and the lack of either to be problems I may be inclined to solve.
  - crusso 14y ago
    So your original post is meaningless since you decried solving other peoples' problems... but solving other peoples' problems could completely fall under the set of "solving your problems". "Is anything we do truly altruistic?" is a fun question philosophically, but makes for really circular/meaningless HN comments.
    - rbanffy 14y ago
      I'm not solving someone else's problem unless it either is also my problem or solving it solves another problem I have. In this case it's obvious adding the requested feature solves no problem of the maintainer.

crusso 14y ago

In your .md file, specify that issues should be researched, follow a certain formatting and include certain key words. The formatted research should include the search terms used when looking for previous issues and list the results found, including a short reason for why those issues didn't apply. Any issues submitted that didn't include the formatting, research, and key words are put into a bin where volunteer users can go through them and correct the problems. Basically, I'm saying to demand better from the people you're looking to help, automate as much as you can, and delegate some of the work to those who can't code but can contribute in some way.

j_s 14y ago

Google Code uses stars, Codeplex allows votes... that seems to be the minimum effort to support crowdsourcing bug prioritization. GitHub's issues haven't gotten much love.

lucian303 14y ago

Well, considering the project, less work is not a bad thing.