An Open Source Author's Lament • Hacker News Board

Re: An Open Source Author's Lament

#21

Post by shurane » Wed, Mar 20, 2013, 9:26 AM UTC

jashkenas wrote: post #8

lrem wrote: post #3

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

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

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.

Re: An Open Source Author's Lament

#22

Post by knite » Wed, Mar 20, 2013, 9:32 AM UTC

jashkenas wrote: post #8

lrem wrote: post #3

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

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

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

Re: An Open Source Author's Lament

#23

Post by hayksaakian » Wed, Mar 20, 2013, 9:32 AM UTC

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.

Re: An Open Source Author's Lament

#24

Post by jashkenas » Wed, Mar 20, 2013, 9:50 AM UTC

knite wrote: post #22

jashkenas wrote: post #8

Earlier quoted context omitted.

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

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…

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.

Re: An Open Source Author's Lament

#25

Post by wladimir » Wed, Mar 20, 2013, 9:53 AM UTC

laurent123456 wrote: post #17

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.

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

Re: An Open Source Author's Lament

#26

Post by porker » Wed, Mar 20, 2013, 9:55 AM UTC

laurent123456 wrote: post #17

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

Re: An Open Source Author's Lament

#27

Post by Perceptes » Wed, Mar 20, 2013, 10:09 AM UTC

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.

Re: An Open Source Author's Lament

#28

Post by qwerta » Wed, Mar 20, 2013, 10:15 AM UTC

laurent123456 wrote: post #17

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.

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.

Re: An Open Source Author's Lament

#29

Post by mh- » Wed, Mar 20, 2013, 10:23 AM UTC

saurik wrote: post #13

Cthulhu_ wrote: post #11

Earlier quoted context omitted.

> 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 w…

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, direct…

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.

Re: An Open Source Author's Lament

#30

Post by jaggederest » Wed, Mar 20, 2013, 10:23 AM UTC

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.