Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

An Open Source Author's Lament

github.com

Post reply on HN
Print view View original

1–10 of 57 posts

Re: An Open Source Author's Lament

#4

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

Re: An Open Source Author's Lament

#6

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

Re: An Open Source Author's Lament

#8

Post by jashkenas »

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

Re: An Open Source Author's Lament

#9

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

Re: An Open Source Author's Lament

#10

Post by qznc »

rogerbinns wrote: post #9

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

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.

Post reply on HN