themaster1970sf/TShock
1
0
Fork 0
Code Issues Pull requests Projects Releases 1 Packages Wiki Activity Actions

Update contributing guidelines & issue template

Browse source
This commit is contained in:
Lucas Nicodemus 2017-12-14 00:00:19 -07:00
parent 2bd4636446
commit 76b5ba6af5
2 changed files with 19 additions and 20 deletions
Download patch file Download diff file Expand all files Collapse all files

21
.github/CONTRIBUTING.md vendored
View file

@ -8,18 +8,6 @@ Please follow these simple requirements before posting a bug report:
- How to reproduce the issue
- Screenshots of the issue (if applicable)
### To build the source
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 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.
Need help? Drop by Discord and we'll be happy to explain it with more words, step by 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! 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.
@ -33,13 +21,13 @@ _If a person makes a suggestion in Discord, capture the suggestion as a Github i
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.
* 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 'Contribution Wanted.'
* After 'Contribution 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 'Contribution 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. 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.
* Please send a pull request with at least a sentence description and something meaningful as the title, not just the issue number you're fixing.
_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)!_
_The 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.
@ -56,6 +44,7 @@ Required:
- 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)]```.
- Update the `CHANGELOG.md` file.
### Dev Team Guidelines

18
.github/ISSUE_TEMPLATE.md vendored
View file

@ -1,11 +1,21 @@
!!!!!! PLEASE FILL IN THE TEMPLATE BELOW THANK YOU VERY MUCH !!!!!!
## TShock version
If you don't need help, delete this template and just post an issue (feature requests and discussions and the like).
* TShock version:
* TShock build number (if known):
## Any stack traces that may have happened when the issue occurred
#### Reproduction steps (if applicable)?
1. Some step
2. Some other step
3. Some bigger step
4. This is the problem
## Steps to reproduce
#### Any stack traces or error messages (if known)?
```
PUT SUPER LONG ERROR MESSAGES IN THE TICK MARKS
```
## Screenshots of the problem, if applicable
#### Any screenshots?