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

Merge pull request #2611 from chillu/pulls/house-rules

Browse Source 
Written up some "House Rules" for the community, but particularly for the core team.
This commit is contained in:
Will Rossiter 2013-10-25 17:28:35 -07:00
commit e6cdf09519
1 changed files with 21 additions and 0 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

21
docs/en/misc/contributing/index.md
View File

@ -14,3 +14,24 @@ Or, for more detailed guidance, read one of the following pages:
* [Writing and translating **documentation**](documentation) * [Writing and translating **documentation**](documentation)
* [**Translating** user-interface elements](translation) * [**Translating** user-interface elements](translation)
## House Rules for Everybody
* 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)
## House Rules for the Core Team
The "core team" consists 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
* Avoid `git push --force`, and be careful with your git remotes (no accidental pushes)
* Use your own forks to create feature branches