From f65629ab73c528f839af48982ae5c0055a25b9e9 Mon Sep 17 00:00:00 2001 From: Ingo Schommer Date: Fri, 25 Oct 2013 12:49:37 +0200 Subject: [PATCH] "House rules" docs --- docs/en/misc/contributing/index.md | 21 +++++++++++++++++++++ 1 file changed, 21 insertions(+) diff --git a/docs/en/misc/contributing/index.md b/docs/en/misc/contributing/index.md index 2d9d90412..19999fbbb 100644 --- a/docs/en/misc/contributing/index.md +++ b/docs/en/misc/contributing/index.md @@ -14,3 +14,24 @@ 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 + + * 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 \ No newline at end of file