From e6f787755108066737514b55204e38a3063fb1a4 Mon Sep 17 00:00:00 2001 From: Lucas Nicodemus Date: Fri, 1 May 2015 09:57:18 -0600 Subject: [PATCH 1/3] Add new contributing guidelines --- CONTRIBUTING.md | 5 ++++- 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md index ead501b8..b17d99c2 100644 --- a/CONTRIBUTING.md +++ b/CONTRIBUTING.md @@ -19,6 +19,10 @@ Required: - Use tabs, not spaces. - Use UpperCamelCase for public function names. - Prior to developing, make sure your clone is up to date with general-devel. This means that we don't get merge commits in your pull request. +- Document all code with public access at minimum. Use the ```Description``` style -- do not repeat the param type or name in the xml comment field. +- Use explicit type declaration (```int, long, float```) when the type is not easily inferred (such as return types). +- Use implicit type declaration (```var```) when the type is easily inferred (such as private lists, temporary values, etc). +- Use Microsoft code conventions on variable naming (including ```_name``` for private members). ### Dev Team Guidelines @@ -30,7 +34,6 @@ These guidelines are to be followed by all developers with commit level access t - This is not a professional software product. Your results may vary with code quality, buginess, etc. Do not complain about something -- just fix it and move on. - __Do not force push the repo__, or you will be removed. - __Do not revert commits__, unless you have sign-off from one other developer (the two-man rule), or you will be removed. -- __This is not a meritocracy.__ - Deprecation of a function guarantees that it will exist in the given release, but may be removed, at any time following, from subsequent releases without further warning. Warning should be given in the release thread prior to it going live. - Updates should be discussed, via pull request of a version tick, prior to release. Only after consensus from active contributing community members has been given can a release happen. - Breaking API changes (excluding removal of already deprecated and warned code) should be forewarned with a one week notice on the forums, which may be given at any time prior to release (as soon as a pull request for a version push has been made, an update can be warned). From dc704c3efe67093648ac43e9d547ae321f8974cb Mon Sep 17 00:00:00 2001 From: Lucas Nicodemus Date: Mon, 4 May 2015 21:11:54 -0600 Subject: [PATCH 2/3] Update guidelines with suggestions from @MarioE --- CONTRIBUTING.md | 4 ++++ 1 file changed, 4 insertions(+) diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md index b17d99c2..93824586 100644 --- a/CONTRIBUTING.md +++ b/CONTRIBUTING.md @@ -20,9 +20,13 @@ Required: - Use UpperCamelCase for public function names. - Prior to developing, make sure your clone is up to date with general-devel. This means that we don't get merge commits in your pull request. - Document all code with public access at minimum. Use the ```Description``` style -- do not repeat the param type or name in the xml comment field. +- Document functions that can throw exceptions with ``````. - Use explicit type declaration (```int, long, float```) when the type is not easily inferred (such as return types). - Use implicit type declaration (```var```) when the type is easily inferred (such as private lists, temporary values, etc). - Use Microsoft code conventions on variable naming (including ```_name``` for private members). +- When using static methods on primitives, use the CLR type. E.g. ```String.Format``` instead of ```string.Format```. +- Always use properties, not public fields. +- Document deprecations and fail compilation if they're included with ```[Obsolete("Use blah instead of blahx...", true)]```. ### Dev Team Guidelines From d4851b8e0f16d2dd10ae6881993ee500292eb020 Mon Sep 17 00:00:00 2001 From: Lucas Nicodemus Date: Tue, 5 May 2015 22:14:47 -0600 Subject: [PATCH 3/3] Add Github flow; fixes #924 --- CONTRIBUTING.md | 2 ++ 1 file changed, 2 insertions(+) diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md index 93824586..9292b0e8 100644 --- a/CONTRIBUTING.md +++ b/CONTRIBUTING.md @@ -14,6 +14,8 @@ If something is better suited to be a plugin for TShock, rather than a TShock co These guidelines are for all contributors. Please join #pull-request on our Slack instance and ask about your idea first, if you're implementing a new feature, system, or changing an existing implementation. Pull requests that change large feature sets or swathes of code will be dissected for quality and purpose prior to approval, and requests that conflict with a team developer's work may be declined if the project is already being worked on internally, but not released. In addition, issues assigned to Nyx developers that are recent and fresh should be considered a no-go zone, while that developer works on their solution outside the scope of Github. +Even if you have write access to the repository, follow [Github flow](https://guides.github.com/introduction/flow/) when sending commits. Don't send commits directly to either ```master``` or ```general-devel``` unless those commits modify either the deploy scripts or non-code components. If it compiles, follow Github Flow. + Required: - Push code to the general-devel branch. Do not push it anywhere else. - Use tabs, not spaces.