Skip to content

Commit 43e49a8

Browse files
chhakuli123chhakuli123
committed
feat: add Contributing Guide to outline contribution process and guidelines
1 parent f684e20 commit 43e49a8

File tree

1 file changed

+198
-0
lines changed

1 file changed

+198
-0
lines changed

‎CONTRIBUTING.md

Lines changed: 198 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,198 @@
1+
# Contributing
2+
3+
When contributing to this repository, please first discuss the change you wish to make via [issue](https://github.com/CreoWis/text-compare/issues),
4+
[email](mailto:hello@creowis.com), or any other method with the owners of this repository before making a change.
5+
6+
Please note we have a [Code of Conduct](https://github.com/CreoWis/text-compare/blob/main/CODE_OF_CONDUCT.md), please follow it in all your interactions with the project.
7+
8+
- [Pull Request Process](#prp)
9+
- [Code of Conduct](#coc)
10+
- [Commit Message Format](#commit)
11+
12+
## <a name="prp"></a> Pull Request Process
13+
14+
1. Ensure any install or build dependencies are removed before the end of the layer when doing a
15+
build.
16+
2. Update the README.md with details of changes to the interface, this includes new environment
17+
variables, exposed ports, useful file locations and container parameters.
18+
3. Increase the version numbers in any examples files and the README.md to the new version that this
19+
Pull Request would represent. The versioning scheme we use is [SemVer](http://semver.org/).
20+
4. You may merge the Pull Request in once you have the sign-off of two other developers, or if you
21+
do not have permission to do that, you may request the second reviewer to merge it for you.
22+
23+
## <a name="coc"></a> Code of Conduct
24+
25+
### Our Pledge
26+
27+
In the interest of fostering an open and welcoming environment, we as
28+
contributors and maintainers pledge to making participation in our project and
29+
our community a harassment-free experience for everyone, regardless of age, body
30+
size, disability, ethnicity, gender identity and expression, level of experience,
31+
nationality, personal appearance, race, religion, or sexual identity and
32+
orientation.
33+
34+
### Our Standards
35+
36+
Examples of behavior that contributes to creating a positive environment
37+
include:
38+
39+
- Using welcoming and inclusive language
40+
- Being respectful of differing viewpoints and experiences
41+
- Gracefully accepting constructive criticism
42+
- Focusing on what is best for the community
43+
- Showing empathy towards other community members
44+
45+
Examples of unacceptable behavior by participants include:
46+
47+
- The use of sexualized language or imagery and unwelcome sexual attention or
48+
advances
49+
- Trolling, insulting/derogatory comments, and personal or political attacks
50+
- Public or private harassment
51+
- Publishing others' private information, such as a physical or electronic
52+
address, without explicit permission
53+
- Other conduct which could reasonably be considered inappropriate in a
54+
professional setting
55+
56+
### Our Responsibilities
57+
58+
Project maintainers are responsible for clarifying the standards of acceptable
59+
behavior and are expected to take appropriate and fair corrective action in
60+
response to any instances of unacceptable behavior.
61+
62+
Project maintainers have the right and responsibility to remove, edit, or
63+
reject comments, commits, code, wiki edits, issues, and other contributions
64+
that are not aligned to this Code of Conduct, or to ban temporarily or
65+
permanently any contributor for other behaviors that they deem inappropriate,
66+
threatening, offensive, or harmful.
67+
68+
### Scope
69+
70+
This Code of Conduct applies both within project spaces and in public spaces
71+
when an individual is representing the project or its community. Examples of
72+
representing a project or community include using an official project e-mail
73+
address, posting via an official social media account, or acting as an appointed
74+
representative at an online or offline event. Representation of a project may be
75+
further defined and clarified by project maintainers.
76+
77+
### Enforcement
78+
79+
Instances of abusive, harassing, or otherwise unacceptable behavior may be
80+
reported by contacting the project team at [hello@creowis.com](mailto:hello@creowis.com). All
81+
complaints will be reviewed and investigated and will result in a response that
82+
is deemed necessary and appropriate to the circumstances. The project team is
83+
obligated to maintain confidentiality with regard to the reporter of an incident.
84+
Further details of specific enforcement policies may be posted separately.
85+
86+
Project maintainers who do not follow or enforce the Code of Conduct in good
87+
faith may face temporary or permanent repercussions as determined by other
88+
members of the project's leadership.
89+
90+
### Attribution
91+
92+
This Code of Conduct is adapted from the [Contributor Covenant][homepage], version 1.4,
93+
available at [http://contributor-covenant.org/version/1/4][version]
94+
95+
[homepage]: http://contributor-covenant.org
96+
[version]: http://contributor-covenant.org/version/1/4/
97+
98+
## <a name="commit"></a> Commit Message Format
99+
100+
We have very precise rules over how our Git commit messages must be formatted.
101+
This format leads to **easier to read commit history**.
102+
103+
Each commit message consists of a **header**, a **body**, and a **footer**.
104+
105+
```
106+
<header>
107+
<BLANK LINE>
108+
<body>
109+
<BLANK LINE>
110+
<footer>
111+
```
112+
113+
The `header` is mandatory and must conform to the [Commit Message Header](#commit-header) format.
114+
115+
The `body` is mandatory for all commits except for those of type "docs".
116+
When the body is present it must be at least 20 characters long and must conform to the [Commit Message Body](#commit-body) format.
117+
118+
The `footer` is optional. The [Commit Message Footer](#commit-footer) format describes what the footer is used for and the structure it must have.
119+
120+
#### <a name="commit-header"></a>Commit Message Header
121+
122+
```
123+
<type>(<scope>): <short summary>
124+
│ │ │
125+
│ │ └─⫸ Summary in present tense. Not capitalized. No period at the end.
126+
│ │
127+
│ └─⫸ Commit Scope: common|plays (2048, analog-clock, basic-calculator, etc.)|infra|etc.
128+
│
129+
└─⫸ Commit Type: build|ci|docs|feat|fix|perf|refactor|test
130+
```
131+
132+
The `<type>` and `<summary>` fields are mandatory, the `(<scope>)` field is optional.
133+
134+
##### Type
135+
136+
Must be one of the following:
137+
138+
- **build**: changes that affect the build system or external dependencies
139+
- **ci**: changes to our CI configuration files and script
140+
- **docs**: documentation only changes
141+
- **feat**: new feature
142+
- **fix**: bug fix
143+
- **perf**: code change that improves performance
144+
- **refactor**: code change that neither fixes a bug nor adds a feature
145+
- **test**: add missing tests or correcting existing tests
146+
147+
##### Summary
148+
149+
Use the summary field to provide a succinct description of the change:
150+
151+
- use the imperative, present tense: "change" not "changed" nor "changes"
152+
- don't capitalize the first letter
153+
- no dot (.) at the end
154+
155+
#### <a name="commit-body"></a>Commit Message Body
156+
157+
Just as in the summary, use the imperative, present tense: "fix" not "fixed" nor "fixes".
158+
159+
Explain the motivation for the change in the commit message body. This commit message should explain _why_ you are making the change.
160+
You can include a comparison of the previous behavior with the new behavior in order to illustrate the impact of the change.
161+
162+
#### <a name="commit-footer"></a>Commit Message Footer
163+
164+
The footer can contain information about breaking changes and deprecations and is also the place to reference GitHub issues, Jira tickets, and other PRs that this commit closes or is related to.
165+
For example:
166+
167+
```
168+
BREAKING CHANGE: <breaking change summary>
169+
<BLANK LINE>
170+
<breaking change description + migration instructions>
171+
<BLANK LINE>
172+
<BLANK LINE>
173+
Fixes #<issue number>
174+
```
175+
176+
or
177+
178+
```
179+
DEPRECATED: <what is deprecated>
180+
<BLANK LINE>
181+
<deprecation description + recommended update path>
182+
<BLANK LINE>
183+
<BLANK LINE>
184+
Closes #<pr number>
185+
```
186+
187+
Breaking Change section should start with the phrase "BREAKING CHANGE: " followed by a summary of the breaking change, a blank line, and a detailed description of the breaking change that also includes migration instructions.
188+
189+
Similarly, a Deprecation section should start with "DEPRECATED: " followed by a short description of what is deprecated, a blank line, and a detailed description of the deprecation that also mentions the recommended update path.
190+
191+
### Revert commits
192+
193+
If the commit reverts a previous commit, it should begin with `revert: `, followed by the header of the reverted commit.
194+
195+
The content of the commit message body should contain:
196+
197+
- information about the SHA of the commit being reverted in the following format: `This reverts commit <SHA>`,
198+
- a clear description of the reason for reverting the commit message.

0 commit comments

Comments
 (0)