Skip to content

Latest commit

 

History

History
77 lines (41 loc) · 3.34 KB

README.md

File metadata and controls

77 lines (41 loc) · 3.34 KB

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.


For issue reporters

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


For contributors

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

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)