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

11–20 of 57 posts

Re: An Open Source Author's Lament

#11

Post by Cthulhu_ »

qznc wrote: post #10
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.

> 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

Re: An Open Source Author's Lament

#12

Post by benatkin »

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.

Re: An Open Source Author's Lament

#13

Post by saurik »

Cthulhu_ wrote: post #11
qznc wrote: post #10

Earlier quoted context omitted.

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.

> 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, directing people to the right place to have different kinds of interactions.

Re: An Open Source Author's Lament

#14

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

Re: An Open Source Author's Lament

#15

Post by mmahemoff »

lowboy wrote: post #4

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.

Re: An Open Source Author's Lament

#16

Post by Jare »

guywithabike wrote: post #7

In one message, @humanchimp says: Ok thanks for closing my issue. @humanchimp's very next comment: The sarcasm is not appreciated, [...]

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.

Re: An Open Source Author's Lament

#17

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

Re: An Open Source Author's Lament

#18

Post by shurane »

lifeisstillgood wrote: post #14

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

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.

Re: An Open Source Author's Lament

#19

Post by benaiah »

lifeisstillgood wrote: post #14

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

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.

Re: An Open Source Author's Lament

#20

Post by doppel »

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.

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.

Post reply on HN