DOCS Repositioned house rules and added core commiter list.

This commit is contained in:
Cam Findlay 2014-11-21 12:05:21 +13:00
parent 836ea04d90
commit 22ecab555c
2 changed files with 38 additions and 0 deletions

View File

@ -0,0 +1,34 @@
# Core Commiters
The core commiters team is reviewed approximately annually, new members are added based on quality contributions to SilverStipe code and outstanding community participation.
## Core committer team
* [Damian Mooyman](https://github.com/tractorcow/)
* [Daniel Hensby](https://github.com/dhensby)
* [Hamish Friedlander](https://github.com/hafriedlander)
* [Ingo Schommer](https://github.com/chillu)
* [Loz Calver](https://github.com/kinglozzer)
* [Mateusz Uzdowski](https://github.com/mateusz/)
* [Sam Minnée](https://github.com/sminnee)
* [Sean Harvey](https://github.com/halkyon/)
* [Stig Lindqvist](https://github.com/stojg)
* [Will Morgan](https://github.com/willmorgan)
* [Will Rossiter](https://github.com/wilr/)
## House rules for the core commiter team
The "core commiters" consist of everybody with write permissions to our codebase.
With great power comes great responsibility, so we have agreed on certain expectations:
* Be friendly, encouraging and constructive towards other community members
* Frequently review pull requests and new issues (in particular, respond quickly to @mentions)
* Treat issues according to our [issue guidelines](/misc/contributing/issues)
* Don't commit directly to core, raise pull requests instead (except trivial fixes)
* Only merge code you have tested and fully understand. If in doubt, ask for a second opinion.
* Ensure contributions have appropriate [test coverage](/topics/testing), are documented, and pass our [coding conventions](/misc/coding-conventions)
* Keep the codebase "releasable" at all times (check our [release process](/misc/release-process))
* API changes and non-trivial features should not be merged into release branches.
* API changes on master should not be merged until they have the buy-in of at least two core committers (or better, through the [core mailinglist](https://groups.google.com/forum/#!forum/silverstripe-dev))
* Be inclusive. Ensure a wide range of SilverStripe developers can obtain an understanding of your code and docs, and you're not the only one who can maintain it.
* Avoid `git push --force`, and be careful with your git remotes (no accidental pushes)
* Use your own forks to create feature branches

View File

@ -14,3 +14,7 @@ Or, for more detailed guidance, read one of the following pages:
* [Writing and translating **documentation**](documentation)
* [**Translating** user-interface elements](translation)
## House rules for everybody contributing to SilverStripe
* Ask questions on the [forum](http://silverstripe.org/forum), and stick to more high-level discussions on the [core mailinglist](https://groups.google.com/forum/#!forum/silverstripe-dev)
* Make sure you know how to [raise good bug reports](/misc/contributing/issues)
* Everybody can contribute to SilverStripe! If you do, ensure you can [submit solid pull requests](/misc/contributing/code)