Ask HN: What Are Some Good GitHub "Contributing" Examples?
I have written what I think is a good set of guidelines[2], but there is a chicken-and-egg problem in that I don’t really have the following to test it on; on the other hand, it might very well have discouraged some people from posting borderline-useless project feedback.
In addition, my Travis continuous integration also automatically vets the pull request code on a very, very basic level, which is something akin to a second layer of defence against bad contributions.
Where else are there some guidelines that could be instructive to learn from with direct application to a GitHub project? I don’t think community guidelines like those by pg are relevant here, especially in the spirit of brevity.
Perhaps we could look into creating a CONTRIBUTING Bootstrap as a default template for writing your GitHub contribution guidelines?
What are your experiences? Especially those of you with very popular projects that have to straddle a deluge of feedback and scale accordingly[3]?
[1]: https://github.com/blog/1184-contributing-guidelines
[2]: http://pygm.us/9uVqoDHQ
[3]: http://news.ycombinator.com/item?id=4820149
10 comments
[ 3.1 ms ] story [ 27.6 ms ] thread[1]: https://github.com/blog/1184-contributing-guidelines
[2]: http://pygm.us/9uVqoDHQ
[3]: http://news.ycombinator.com/item?id=4820149
The odd thing about OpenStack (from a GitHub perspective) is that the OpenStack development process doesn't use GitHub's issues or pull requests. This has been documented on the OpenStack wiki, but that info is now also in our CONTRIBUTING file. Our file is an example of something to share with potential contributors to point them in the right direction.
OpenStack doesn't use GitHub for issues or pull requests, while MongoDB doesn't use their issues but does use pull requests. Some projects require you to sign a contributor agreement, some don't. Different languages (coding standards), different platforms (testing), etc. So you'll probably want to bake the customization aspect (a la http://twitter.github.com/bootstrap/customize.html) into the very core of your idea.
As for examples: - the guidelines for the MongoDB project (not bad, I think) are here: https://github.com/mongodb/mongo/blob/master/CONTRIBUTING.rs... - and the Contributor Guidelines for Chef are quite good too: http://wiki.opscode.com/display/chef/How+to+Contribute
Because you are entirely right, and there will never be a one-size-fits-all file. That’s why I am thinking about a solution that instead uses one-size-fits-all questions that people have to ask themselves, and these could dynamically either create the guidelines outright or prompt the authors to think about the question for themselves.
As my own guidelines highlight, you inevitably veer into subjective style guidelines, and we all know how long people can go on endlessly about JavaScript style guidelines.
Thinking over these guidelines, I think it could be useful to popular projects to have a set of canned responses to different kinds of erroneous issues and pull requests. They could also come with attacked action such as labelling and the closing of the issue or pull request.
Although I guess this could be implemented through a browser extension, if the people at GitHub don’t implement it.
http://contributing.appspot.com/
On Github at: https://github.com/bradfitz/contributing
* [OpenGovernment][1]
* [Factory Girl][2]
* [agner][3]
* [suspenders][4]
[1]: https://github.com/opengovernment/opengovernment/blob/master...
[2]: https://github.com/thoughtbot/factory_girl_rails/blob/master...
[3]: https://github.com/agner/agner/blob/master/CONTRIBUTING.md
[4]: https://github.com/thoughtbot/suspenders/blob/master/CONTRIB...