tonyair/silverstripe-framework
1
0
Fork 0
mirror of https://github.com/silverstripe/silverstripe-framework synced 2024-10-22 14:05:37 +02:00
Code Issues Projects Releases Wiki Activity

Typo fixes for committers

Browse Source
This commit is contained in:
Cam Findlay 2014-12-15 09:07:54 +13:00
parent 9e7fc7618c
commit f387ffebe6
1 changed files with 8 additions and 8 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

16
docs/en/misc/contributing/core-commiters.md → docs/en/05_Contributing/06_Core_commiters.md
View File

@ -1,5 +1,5 @@
# Core Commiters # Core Committers
The core commiters team is reviewed approximately annually, new members are added based on quality contributions to SilverStipe code and outstanding community participation. The core committers team is reviewed approximately annually, new members are added based on quality contributions to SilverStipe code and outstanding community participation.
## Core committer team ## Core committer team
* [Damian Mooyman](https://github.com/tractorcow/) * [Damian Mooyman](https://github.com/tractorcow/)
@ -14,20 +14,20 @@ The core commiters team is reviewed approximately annually, new members are adde
* [Will Morgan](https://github.com/willmorgan) * [Will Morgan](https://github.com/willmorgan)
* [Will Rossiter](https://github.com/wilr/) * [Will Rossiter](https://github.com/wilr/)
## House rules for the core commiter team ## House rules for the core committer team
The "core commiters" consist of everybody with write permissions to our codebase. The "core committers" consist of everybody with write permissions to our codebase.
With great power comes great responsibility, so we have agreed on certain expectations: With great power comes great responsibility, so we have agreed on certain expectations:
* Be friendly, encouraging and constructive towards other community members * Be friendly, encouraging and constructive towards other community members
* Frequently review pull requests and new issues (in particular, respond quickly to @mentions) * Frequently review pull requests and new issues (in particular, respond quickly to @mentions)
* Treat issues according to our [issue guidelines](/misc/contributing/issues) * Treat issues according to our [issue guidelines](issues_and_bugs)
* Don't commit directly to core, raise pull requests instead (except trivial fixes) * 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. * 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) * Ensure contributions have appropriate [test coverage](/topics/testing), are documented, and pass our [coding conventions](/getting_started/coding-conventions)
* Keep the codebase "releasable" at all times (check our [release process](/misc/release-process)) * Keep the codebase "releasable" at all times (check our [release process](release_process))
* API changes and non-trivial features should not be merged into release branches. * 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)) * 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 mailing list](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. * 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) * Avoid `git push --force`, and be careful with your git remotes (no accidental pushes)
* Use your own forks to create feature branches * Use your own forks to create feature branches