
An Open Source Author's Lament - jnwng
https://github.com/jashkenas/coffee-script/issues/2864#issuecomment-15159370
======
lifeisstillgood
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

~~~
dmiladinov
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."_

~~~
lifeisstillgood
Thank you - had not seen that.

no swearing either :-)

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

~~~
mh-
I don't think the parent commenter intended the 'level up' to be disparaging
at all.

It seems you interpreted it as something like 'up his game', but I believe the
commenter meant something like:

He needs to recognize that may no longer be a good use of his time; that he
might need to be 'above' that.

------
jashkenas
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!

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

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

------
guywithabike
In one message, @humanchimp says:

    
    
        Ok thanks for closing my issue.
    

@humanchimp's very next comment:

    
    
        The sarcasm is not appreciated, [...]

~~~
Jare
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
I guess you don't like Perl much then. _ducks_

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

------
hayksaakian
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
Issues 1.0 had voting, but it was removed in Issues 2.0

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

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

------
benatkin
Here's the author of this issue being touchy in another thread:
[https://github.com/jashkenas/coffee-
script/issues/2836#issue...](https://github.com/jashkenas/coffee-
script/issues/2836#issuecomment-14944179)

> Before blaming me further

This reminds me of DHH's "Rails is Omakase" post.
[http://david.heinemeierhansson.com/2012/rails-is-
omakase.htm...](http://david.heinemeierhansson.com/2012/rails-is-omakase.html)
"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.

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

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

~~~
jashkenas
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!

~~~
knite
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
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
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?

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

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

~~~
wladimir
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
The issue in question had no code attached, it was a vague request for a
syntax change.

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

------
drivebyacct2
>dfkaye

[https://github.com/jashkenas/coffee-
script/issues/2864#issue...](https://github.com/jashkenas/coffee-
script/issues/2864#issuecomment-15160136)

Is that guy serious?

