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
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.
I'd like to piggy-back on your mention of Linus. It reminds me of a recent video I saw wherein he talked about how the work on the kernel works within a natural hierarchy.
The whole video, IMHO is worth a watch, but the relevant snippet is here, you can watch from about 15:57 to about 18:20 to get the idea:
I especially liked his comment at the end of this section:
"The way people work ... is inherent in our brains ... the whole development process ... works really well ... we used the hierarchy that just worked on its own, and that turns out to be the right hierarchy."
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.
A possible implementation of "delegation" would be:
* coffee-script/coffee-script as the "social" hub, where people put requests, bugs, and so on, filtered by "his trusted people"
* jashkenas/coffee-script , where he gets pull requests (and/or) issues from those trusted people
You are still just asking "someone" to read the firehose.
You need to reduce the firehose
1. raise the bar for submitting something a human is expected to read (write a long form proposal, submit a bug with a stacktrace or a test added to the test suite)
2. raise the bar for community supported issues by needing upvotes.
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.
It doesn't support priorities natively, but I've seen several projects use labels with unicode stars to prioritize. Then, you can filter by that tag to to see all 5-star issues, 4-star issues, etc.
> 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.
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.
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.
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.
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.
> Is it really that hard to get people don't write open source to solve your problems?
Yes. There is a persistent set of well-intentioned but clueless people.
> What state of mind makes people believe they are entitled to someone else's time?
"I want the software to work. You wrote it, you need to fix it! It's your problem. What's wrong with you? Why won't your software work? I need it for a deadline! Please fix it now!"
I've been running an open source project for ~15 years, with many millions of running installations. The only solution I've found is to ignore these people. The "d" key comes in handy. Where that isn't possible, I ban/block them.
The level of cluelessness can be seen in the following typical exchange:
- user engages in anti-social activity
- I say "stop or you will be banned"
- user repeats the anti-social activity, and calls me names for "threatening" him.
These people don't even realize that annoying the mailing list administrator is unproductive. It's like their psychology is missing a reward/punishment feedback loop which normal people have.
As someone who writes open source software to help solve other peoples' problems, all I can tell you is that it makes me happy to help other people. There's no logical reasoning behind it beyond that I feel good when I've helped someone else accomplish their goals.
Sure, you could analyze the cost and benefits of it, and maybe even find a logical reason as to why it makes me happy, but _I_ didn't. I just enjoy it! :D
That's the point - you do what you want because you enjoy it. I program because I like programming and I enjoy solving the problems people I like have. Solving a lack of enjoyment is solving a problem.
But I don't enjoy programming for people I don't like.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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:
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"?
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.
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?
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?
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.
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.
Really? Would those be developers with full-time jobs, families and a life?
If the issue is not delegating etc then that's one thing, but there's also the scenario where others don't want to step up and take any responsibility on a project. Or if they do it's not for the Malcolm-reasons https://news.ycombinator.com/item?id=5402137 but for the ego trip of being part of a popular project. Yep, been there and burned by it, so just a little cynical...
Indeed. For me as open source developer, the most frustrating issues are the ones that demand functionality without code attached. Especially if they are worded in a way that the creator is somehow entitled to have his issue solved (without offering any compensation).
Then again, I have never been in a project that got 75 new pull requests per day...
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.
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.
> "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.
Not really, trust me. I have great open-source project, but I am keeping it quiet. After I will publish it, it explodes and floods me with issues/questions. Right now I have low number of highly motivated users and it keeps my backlog full.
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.
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