docs: add contributing guidelines

This commit is contained in:
Adam Douglas 2020-02-07 13:58:54 -06:00
parent 22119c51a1
commit bb2d1c061b
1 changed files with 151 additions and 0 deletions

151
CONTRIBUTING.md Normal file
View File

@ -0,0 +1,151 @@
# Contributing To Minecraft Server Systemd Services
- [Code Of Conduct](#code-of-conduct)
- [Submission Guidelines](#submission-guidelines)
- [Commit Message Guidelines](#commit-message-guidelines)
## Code Of Conduct
As contributors and maintainers of the Minecraft Server Systemd Services
project, we pledge to respect everyone who contributes by posting issues,
updating documentation, submitting pull requests, providing feedback in comments
and any other associated project activities.
### Principles
- Be constructive
- Be positive
- Be respectful
- Be courtesy
- Be honest
- Be trustworthy
- Never resort to personal attacks
- Never troll
- Never publicly or privately harass
- Never insult
### Violations
If a community member associated to the project violates this code of conduct,
the maintainers of the Minecraft Server Systemd Services project may take
appropriate actions as deemed necessary. Such actions maybe but not limited to,
removing issues, comments, public relations and/or blocking accounts.
### Feedback
If you are subject to or witness of unacceptable behavior or have any other
concerns, please email us at feedback@adamsdesk.com.
## Submission Guidelines
### Submitting An Issue
- All issues must be submitted using GitLab issues.
- Search first before creating an issue.
- Preview the issue to ensure it is rendering as intended.
- Be as descriptive as possible.
- Provide steps required to re-produce.
- Utilize the provided form fields.
- Attach necessary reference documents (error messages, screenshots, sample
data, logs, etc.).
- **Do Not** submit or reply to an issue outside of GitLab.
- **Do Not** submit multiple issues within one submission.
- **Do Not** duplicate an issue.
### Commenting On A Issue
- **Do Not** comment on a issue outside of GitLab.
- Stay on topic per the issue description.
### Issue Closure
Valid reasons for closing an issue:
- Duplicate issue.
- A reference to the duplicate must be added before closure.
- Lacks enough information to re-produce.
- No longer relevant.
- Off topic.
- Resolved.
- Multiple issues within the submission.
- Will not be resolved.
- Provide a reason that this issue will not be resolved.
### Issue Re-Opening
- Reasons for re-opening:
- Issue has not been resolved.
- A detailed comment is required.
- **Do Not** re-open an issue that was closed more than 2 months ago. Instead
Create a new issue.
## Commit Message Guidelines
Git commit messages must adhere to a specific format. This is done to ensure
good communication, consistency and readability.
### Commit Message Format
Each commit message consists of three properties as shown below.
Property | Sub-Property | Character Limit | Mandatory
---------|---------------|-----------------|----------
header | type, subject | 100 | True
body | | 100 | False
footer | | 100 | False
Structure
```
<type>: <subject>
<BLANK LINE>
<body>
<BLANK LINE>
<footer>
```
#### Type
Use one of the following applicable type.
- build
- Changes that affect the build system or external dependencies.
- ci
- Changes continuous integration (CI) configuration files and scripts.
- docs
- Documentation only changes.
- feat
- A new feature.
- fix
- A bug fix.
- perf
- A code change that improves performance.
- refactor
- A code change that neither fixes a bug nor adds a feature.
- revert
- When commit reverts a previous commit.
- style
- Changes that do not affect the meaning of the code (white-space, formatting, missing semi-colons, etc.).
- test
- Adding or modifying tests.
#### Subject
- Be concise description of the change.
- Use the imperative, present tense: "change" not "changed" nor "changes".
- Do not capitalize the first letter.
- No period/dot (.) at the end.
#### Body
- Use the imperative, present tense: "change" not "changed" nor "changes".
- Include the motivation for the change and contrast this with previous
behavior.
- If commit type is **revert**, in the body state `This reverts commit <hash>`.
The `<hash>` is the hash value of the commit being reverted.
#### Footer
- Reference GitLab issue(s) that the commit closes.
- State breaking changes.
- Breaking changes start with **BREAKING CHANGE:** with a space or two
newlines. Following is the description of change, motivation for change and migration notes.