versutus / collaborative-etiquette

A manifesto for happy Open Source projects

Instructions: link this page from your project's README.md and CONTRIBUTING.md:
This project follows [collaborative etiquette](http://git.io/col) guidelines.
[![](https://img.shields.io/badge/%E2%9C%93-collaborative_etiquette-brightgreen.svg)](https://git.io/col)

---

Collaborative etiquette

This project is an Open Source project encouraging everyone to be fearless in their contributions. This document lists some ground rules to foster a happy collaborative atmosphere.

• Individuals making valuable contributions are added as collaborators (commit access).

• This project is more like an open wiki than a standard guarded project.

Contributing

• Don't be afraid! You don't need to submit code to contribute to the success of a project! Don't hold back on submitting issues, commenting on discussions and helping people out.

• Tell us everything. When filing bug reports, be generous in the details: environment, OS, browser, steps to replicate, and so on.

Submitting code

• Check development notes. Any details on setting up a development environment, running tests, releasing versions and such are kept in a file like NOTES.md.

• Be a good citizen. Try your best to adhere to the established styles of the project. This doesn't mean that you shouldn't break them, but be prepared to have a reason if you do.

• Be informative. Format your pull requests nicely. Include screenshots if applicable.

For collaborators

Individuals making valuable contributions are encouraged to be added as collaborators (commit access). This status should be given liberally.

• Work in branches then send a PR. Just because you have full commit access doesn't mean you shouldn't use pull requests. PRs are a great way to solicit feedback from co-collaborators and to give them a nice overview of what's going on.

• Review outstanding PRs. Feel free to merge any you see fit, and leave comments on anything that needs revisions. If you don't feel comfortable merging them, at least comment with a :+1: to signal your co-collaborators that it's passed your review.

• Push directly for micro-fixes. Only push to master for trivial updates that would be too noisy to notify your teammates of, such as typo fixes.

• You can self-merge your PRs. Sometimes the rest of the team may be inactive, in which case, use your best judgement to self-merge PRs.

• Keep history clean. No --force pushing on branches that aren't yours.

• Communicate. You can use GitHub issues to communicate with your co-collaborators. Feel free to @mention them in issues.

• Be nice. The collaborator team is nice, so we are all nice.

For project releases

• Release often. Publish patch versions as soon as fixes are ready.

• Always tag releases. Tag them in the format of v1.0.0.

• Maintain a changelog. Keep the HISTORY.md updated as new changes come in.

• Consult the owner. By default, releases will be the prerogative of the project owner.

For project owners

• Set up continuous-integration. A CI service like Travis will inspect PR's so you don't have to.

• Be decisive. Don't be afraid to put your foot down on issues like API design decisions.

• Thank people. People put in their hard work. Gratitude goes a long way.

• Be nice. The open source community is nice, so we are nice.

Acknowledgements

This is an extension to the Open Open Source manifesto.