Compare commits

...

4 Commits

Author SHA1 Message Date
Adam bcfa056581
docs: add contributing guidelines 2022-10-12 17:04:26 -06:00
Adam a380e5e57c
docs: update directory structure for contributing guidelines 2022-10-12 17:03:28 -06:00
Adam f45a943bed
docs: add contributing guidelines 2022-10-12 17:02:02 -06:00
Adam 386c722fd4
docs: add directory structure 2022-10-12 16:59:20 -06:00
2 changed files with 177 additions and 0 deletions

161
CONTRIBUTING.md Normal file
View File

@ -0,0 +1,161 @@
# Contributing
- [Code Of Conduct](#code-of-conduct)
- [Principles](#principles)
- [Violations](#violations)
- [Feedback](#feedback)
- [Submission Guidelines](#submission-guidelines)
- [Submitting An Issue](#submitting-an-issue)
- [Commenting On A Issue](#commenting-on-a-issue)
- [Issue Closure](#issue-closure)
- [Issue Re-Opening](#issue-re-opening)
- [Commit Message Guidelines](#commit-message-guidelines)
- [Commit Message Format](#commit-message-format)
- [Type](#type)
- [Subject](#subject)
- [Body](#body)
- [Footer](#footer)
## Code Of Conduct
As contributors and maintainers of the 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 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 contact us.
## 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.

View File

@ -3,11 +3,27 @@
Dotfiles are user-specific configuration files that are typically stored as dotfiles, as in filenames that are prefixed
with a dot or period (.). This project are my personal dotfiles and as such are available for reference and backup.
- [Directory Structure](#directory-structure)
- [Installation](#installation)
- [Assumptions](#assumptions)
- [Dependency Requirements](#dependency-requirements)
- [Setup](#setup)
## Directory Structure
The directory structure listed below is in general terms and only those special
files/directories are listed for explanation purposes.
```console
.
├── bin/ < Executable
├── system/ < System configuration
├── user/ < User configuration
├── CONTRIBUTING.md < Project contributing guidelines
├── LICENSE < Project source code license
└── README.md < Project read me
```
## Installation
### Assumptions