Comment by lifeisstillgood | Hacker News Reader

Comment by lifeisstillgood | Hacker News Reader

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

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.

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

Thank you - had not seen that.

no swearing either :-)

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.

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.

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 :-)

Reply on news.ycombinator.com