An Open Source Author's Lament

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

by jnwng • 13 years ago

127 55 13 years ago

jashkenas3• 13 years 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!

lrem• 13 years ago

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

jashkenas3• 13 years 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/7333

https://github.com/twitter/bootstrap/issues/7325

https://github.com/twitter/bootstrap/issues/7320

https://github.com/twitter/bootstrap/issues/7324

https://github.com/twitter/bootstrap/issues/7312

https://github.com/twitter/bootstrap/issues/7302

https://github.com/twitter/bootstrap/issues/7296

https://github.com/twitter/bootstrap/issues/7290

https://github.com/twitter/bootstrap/issues/7282

https://github.com/twitter/bootstrap/issues/7279

https://github.com/twitter/bootstrap/issues/7265

... and those are just a random smattering from the past week!

shurane2• 13 years 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• 13 years 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"?

lowboy• 13 years 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• 13 years 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.

drivebyacct2• 13 years ago

>dfkaye

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

Is that guy serious?

stevensanderson• 13 years 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• 13 years ago

In one message, @humanchimp says:

    Ok thanks for closing my issue.

@humanchimp's very next comment:

    The sarcasm is not appreciated, [...]

Jare• 13 years 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• 13 years ago

I guess you don't like Perl much then. ducks

rogerbinns• 13 years 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• 13 years 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_• 13 years 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

Osmose2• 13 years ago

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.

benatkin• 13 years ago

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.

lifeisstillgood3• 13 years 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

shurane2• 13 years 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• 13 years 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.

Heliosmaster• 13 years ago

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

Also interchanging the two repos work.

lifeisstillgood3• 13 years ago

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.

3. ignore some people randomly :-)

dmiladinov• 13 years ago

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:

https://www.youtube.com/watch?v=MShbP3OpASA#t=15m57s

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."

lifeisstillgood3• 13 years ago

Thank you - had not seen that.

no swearing either :-)

laurent123456• 13 years 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• 13 years 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.

jaggederest2• 13 years 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.

wladimir• 13 years ago

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...

grey-area• 13 years ago

The issue in question had no code attached, it was a vague request for a syntax change.

porker• 13 years ago

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...

qwerta• 13 years ago

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.

hayksaakian• 13 years 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• 13 years ago

Issues 1.0 had voting, but it was removed in Issues 2.0

Afforess• 13 years ago

Because reddit voting is an excellent example of user moderation. /sarcasm

Perceptes• 13 years 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.

jaggederest2• 13 years 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

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• 13 years 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• 13 years 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• 13 years 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.

rbanffy4• 13 years 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?

crusso3• 13 years 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.

rbanffy4• 13 years 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.

commentzorro• 13 years ago

Because it _may_ solve someone else's problem too. And someone else _may_ contribute something back that also solves one of my problems.

Osmose2• 13 years ago

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

rbanffy4• 13 years ago

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.

adekok2• 13 years ago

> 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.

crusso3• 13 years 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• 13 years 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.

An Open Source Author's Lament

Related Stories