An Open Source Author's Lament (opens in new tab)

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

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?

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.

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.

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

In one message, @humanchimp says:

    Ok thanks for closing my issue.

@humanchimp's very next comment:

    The sarcasm is not appreciated, [...]

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

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.

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.

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!

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.

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.

Here's the author of this issue being touchy in another thread: 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.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.

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

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.

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.

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.

>dfkaye

https://github.com/jashkenas/coffee-script/issues/2864#issue...

Is that guy serious?