From 9d2b6555054a7070727c7321ee0908a044f73b0a Mon Sep 17 00:00:00 2001 From: Lucas Nicodemus Date: Mon, 10 Oct 2016 16:58:23 -0600 Subject: [PATCH 1/4] Update contributing with new pr-wanted & suggestion stuff --- CONTRIBUTING.md | 16 ++++++++++++++-- 1 file changed, 14 insertions(+), 2 deletions(-) diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md index 7d51b3b0..e0509bc5 100644 --- a/CONTRIBUTING.md +++ b/CONTRIBUTING.md @@ -1,3 +1,5 @@ +_When in doubt, make an issue. If any of these instructions are unclear, make an issue to discuss your issue or suggestion._ + ### Issue Guidelines Please follow these simple requirements before posting a bug report: @@ -20,11 +22,21 @@ Need help? Drop by Slack and we'll be happy to explain it with more words, step ### TShock Additions -If something is better suited to be a plugin for TShock, rather than a TShock core feature, it should not be added! +If something is better suited to be a plugin for TShock, rather than a TShock core feature, it should not be added! Project scope is at times questionable, though, so create an issue on Github for discussion first. If an issue is completely outside of the scope of TShock, it will be made clear in that issue what it is. + +_If you are confused, make a suggestion. We will determine scope and relevance for you._ ### Pull Request Dev Guidelines -These guidelines are for all contributors. Please join 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. +These guidelines are for all contributors. + +* Create an issue first to suggest an improvement or feature addition to TShock. +* Active developers will then give a go/no go for implementation. This is scope related: if an issue is within the scope of TShock, it will be tagged 'pr-wanted.' +* After 'pr-wanted' has been added, an issue should be considered workable in a pull request fashion. +* If you, as a developer, want to claim an issue for a PR, as soon as possible start work and note that in both the original issue and the new PR. The 'pr-wanted' tag will remain but the active PR will become the center for discussion for your implementation. +* If a TShock core developer takes an issue, they'll be assigned to the issue and pull the pr-wanted tag off. TShock core developers should not pull a issue out of 'pr-wanted' unless the PR is going nowhere or needs massive rework to be implemented correctly. If your issue was taken by a TShock developer and you were actively developing it in a PR, you should _make it clear as soon as possible that a process error has been made_ so that the your development resources and our development resources aren't wasted. + +_The pr-wanted tag indicates an issue should be implemented but no developers are currently available to work an issue._ 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. From 8a593f950412e7c101cba20ae607f1b19d513ccc Mon Sep 17 00:00:00 2001 From: Lucas Nicodemus Date: Mon, 10 Oct 2016 17:06:37 -0600 Subject: [PATCH 2/4] Add note about taking suggestions --- CONTRIBUTING.md | 2 ++ 1 file changed, 2 insertions(+) diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md index e0509bc5..8bef9d76 100644 --- a/CONTRIBUTING.md +++ b/CONTRIBUTING.md @@ -26,6 +26,8 @@ If something is better suited to be a plugin for TShock, rather than a TShock co _If you are confused, make a suggestion. We will determine scope and relevance for you._ +_If a person makes a suggestion in Slack, capture the suggestion as a Github issue. If a suggestion crops up on the forums, make a Github issue to capture it. If you want, direct the user to make a suggestion on Github, but set an alarm/timer/reminder so that if they don't know how to use Github or they don't have an account, an issue is still made and discussed. Make it clear that the issue is a surrogate issue for a suggestion from Slack/the forums too._ + ### Pull Request Dev Guidelines These guidelines are for all contributors. From cff0ecbc60a76c2729213e7c4fc457115eb080f2 Mon Sep 17 00:00:00 2001 From: Lucas Nicodemus Date: Mon, 10 Oct 2016 17:09:17 -0600 Subject: [PATCH 3/4] Add submodule init note change (thanks @levi-middleton) --- CONTRIBUTING.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md index 8bef9d76..6fdf6855 100644 --- a/CONTRIBUTING.md +++ b/CONTRIBUTING.md @@ -13,7 +13,7 @@ Please follow these simple requirements before posting a bug report: Note: This includes the API by default. If you need only the API, you need to cd into that folder and do the following with the .sln file for the API. For those new to C#, the .sln and .csproj files contain the necessary definitions to do a complete source build using Microsoft or Mono build tools. - Checkout the source. -- Initialize the submodules: ```git submodule init``` +- Initialize the submodules: ```git submodule update --init``` - Open the source in your favorite text editor that supports .NET building and press the build button OR - Run ```msbuild TShock.sln``` in the root of the cloned folder on Windows in a 'Developer Command Prompt' OR - Run ```xbuild TShock.sln``` in the root of the cloned folder on Unix. From 0e97f299ee17b7392cfc7ff29aab25f73ff71533 Mon Sep 17 00:00:00 2001 From: Lucas Nicodemus Date: Mon, 10 Oct 2016 18:21:19 -0600 Subject: [PATCH 4/4] Gonna be completely honest I forgot I started typing this commit message and then forgot what it was. I'm sure it's related to what wolfje said though. --- CONTRIBUTING.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md index 6fdf6855..e5bd9051 100644 --- a/CONTRIBUTING.md +++ b/CONTRIBUTING.md @@ -36,9 +36,9 @@ These guidelines are for all contributors. * Active developers will then give a go/no go for implementation. This is scope related: if an issue is within the scope of TShock, it will be tagged 'pr-wanted.' * After 'pr-wanted' has been added, an issue should be considered workable in a pull request fashion. * If you, as a developer, want to claim an issue for a PR, as soon as possible start work and note that in both the original issue and the new PR. The 'pr-wanted' tag will remain but the active PR will become the center for discussion for your implementation. -* If a TShock core developer takes an issue, they'll be assigned to the issue and pull the pr-wanted tag off. TShock core developers should not pull a issue out of 'pr-wanted' unless the PR is going nowhere or needs massive rework to be implemented correctly. If your issue was taken by a TShock developer and you were actively developing it in a PR, you should _make it clear as soon as possible that a process error has been made_ so that the your development resources and our development resources aren't wasted. +* If a TShock core developer takes an issue, they'll be assigned to the issue. If your issue was taken by a TShock developer and you were actively developing it in a PR, you should _make it clear as soon as possible that a process error has been made_ so that the your development resources and our development resources aren't wasted. -_The pr-wanted tag indicates an issue should be implemented but no developers are currently available to work an issue._ +_The pr-wanted tag indicates an issue should be implemented. If an issue has a developer assigned, it indicates that they're working on it. When in doubt, ask where an issue is before starting work (so you don't waste time)!_ 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.