Skip to content

Commit bad1337

Browse files
9prady99prady9
committed
misc: add CONTRIBUTING.md and markdown templates for issue and PRs
1 parent 1f94592 commit bad1337

File tree

3 files changed

+213
-0
lines changed

3 files changed

+213
-0
lines changed

‎.github/ISSUE_TEMPLATE.md

+7
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,7 @@
1+
**What issue(memory leak, slow renders, docs fix etc.) did you face?**
2+
3+
**Please check if the issue fulfills these requirements**
4+
- [ ] For code issues, please share a small code stub that can reproduce the issue on our end.
5+
- [ ] For performance issues, please share comparison benchmarks.
6+
7+
**Other information**:

‎.github/PULL_REQUEST_TEMPLATE.md

+24
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,24 @@
1+
**What kind of change does this PR introduce? (Bug fix, feature, documentation update, new examples etc.)**
2+
3+
4+
**What is the current behavior? (You can also link to an open issue here)**
5+
6+
7+
**What is the new behavior (if this is a feature change)?**
8+
9+
10+
**Does this PR ensure that key events handling across different window toolkits is identical if it
11+
has changes related to window toolkits?**
12+
13+
14+
**Does this PR introduce a breaking change?**
15+
16+
17+
**Please check if the PR fulfills these requirements**
18+
- [ ] The commit message following the [guidelines](https://github.com/arrayfire/forge/blob/devel/CONTRIBUTING.md#commit-message-format)
19+
- [ ] Examples for all compute backends, CUDA & OpenCL, have been added (for new examples)
20+
- [ ] Docs have been added / updated (for bug fixes / features)
21+
- [ ] Change compiles and executes on Linux, OSX and Windows (for window toolkit changes as CI
22+
builds don't check for this yet).
23+
24+
**Other information**:

‎CONTRIBUTING.md

+182
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,182 @@
1+
# Contributing to Forge
2+
3+
We'd love for you to contribute to our source code and to make Forge even better than it is
4+
today! Here are the guidelines we'd like you to follow:
5+
6+
- [Question or Problem?](#question)
7+
- [Issues and Bugs](#issue)
8+
- [Feature Requests](#feature)
9+
- [Submission Guidelines](#submit)
10+
- [Commit Message Guidelines](#commit)
11+
12+
## <a name="question"></a> Got a Question or Problem?
13+
14+
If you have questions about how to use Forge, please direct these to the [Google Group][groups]
15+
discussion list or [StackOverflow][stackoverflow]. We are also available on [Gitter][gitter].
16+
17+
## <a name="issue"></a> Found an Issue?
18+
19+
If you find a bug in the source code or a mistake in the documentation, you can help us by
20+
submitting an issue to our [GitHub Repository][github]. Even better you can submit a Pull Request
21+
with a fix.
22+
23+
## <a name="feature"></a> Want a Feature?
24+
25+
You can request a new feature by submitting an issue to our [GitHub Repository][github]. If you
26+
would like to implement a new feature then consider what kind of change it is:
27+
28+
* **Major Changes** that you wish to contribute to the project should be discussed first on our
29+
[Github][github] or [Gitter][gitter] so that we can better coordinate our efforts,
30+
prevent duplication of work, and help you to craft the change so that it is successfully accepted
31+
into the project.
32+
* **Small Changes** can be crafted and submitted to the [GitHub Repository][github] as a Pull
33+
Request.
34+
35+
36+
## <a name="docs"></a> Want a Documentation Fix?
37+
38+
If you want to help improve the documentation, it's a good idea to let others know what you're working on to
39+
minimize duplication of effort. Create a new issue (or comment on a related existing one) to let
40+
others know what you're working on.
41+
42+
Please build and test the documentation before submitting the PR to be sure you
43+
haven't accidentally introduced any layout or formatting issues. You should also make sure that your
44+
commit message starts with "docs" and follows the **[Commit Message Guidelines](#commit)** outlined
45+
below.
46+
47+
## <a name="submit"></a> Submission Guidelines
48+
49+
### Submitting an Issue
50+
Before you submit your issue search the archive, maybe your question was already answered.
51+
52+
If your issue appears to be a bug, and hasn't been reported, open a new issue. Help us to maximize
53+
the effort we can spend fixing issues and adding new features, by not reporting duplicate issues.
54+
Providing the following information will increase the chances of your issue being dealt with
55+
quickly:
56+
57+
* **Overview of the Issue**
58+
* **Forge Version(s)** - is it a regression?
59+
* **Operating System** - is this a problem on all OSes?
60+
* **Reproduce the Error** - provide an example piece of code that can replicate the issue on our
61+
end.
62+
* **Related Issues** - has a similar issue been reported before?
63+
* **Suggest a Fix** - if you can't fix the bug yourself, perhaps you can point to what might be
64+
causing the problem (line of code or commit)
65+
66+
### Submitting a Pull Request
67+
Before you submit your pull request consider the following guidelines:
68+
69+
* Search [GitHub](https://github.com/arrayfire/forge/pulls) for an open or closed Pull Request
70+
that relates to your submission. You don't want to duplicate effort.
71+
* Make your changes in a new git branch:
72+
73+
```shell
74+
git checkout -b my-fix-branch hotfixes-major-minor-patch
75+
```
76+
If there is no hotfixes branch, branch off of devel.
77+
78+
```shell
79+
git checkout -b my-fix-branch devel
80+
```
81+
* Commit your changes using a descriptive commit message that follows our
82+
[commit message conventions](#commit). Adherence to the [commit message conventions](#commit) is required.
83+
84+
```shell
85+
git commit -a
86+
```
87+
Note: the optional commit `-a` command line option will automatically "add" and "rm" edited files.
88+
89+
* Build your changes locally to ensure everything checks out.
90+
* Push your branch to GitHub:
91+
92+
```shell
93+
git push origin my-fix-branch
94+
```
95+
96+
In GitHub, send a pull request to `forge`. If we suggest changes, then:
97+
98+
* Make the required updates.
99+
* Re-build and check corresponding examples work as expected.
100+
* Commit your changes to your branch (e.g. `my-fix-branch`).
101+
* Push the changes to your GitHub repository (this will update your Pull Request).
102+
103+
If the PR gets too outdated we may ask you to rebase and force push to update the PR:
104+
105+
_WARNING: Squashing or reverting commits and force-pushing thereafter may remove GitHub comments
106+
on code that were previously made by you or others in your commits. Avoid any form of rebasing
107+
unless necessary._
108+
109+
That's it! Thank you for your contribution!
110+
111+
#### After your pull request is merged
112+
113+
After your pull request is merged, you can safely delete your branch and pull the changes
114+
from the upstream repository:
115+
116+
* Delete the remote branch on GitHub either through the GitHub web UI or your local shell
117+
* Check out the parent(hotfixes-\*.\*.\*/devel) branch
118+
* Delete the local branch
119+
* Update the parent branch with the latest upstream version
120+
121+
## <a name="commit"></a> Git Commit Guidelines
122+
123+
We have very precise rules over how our git commit messages can be formatted. This leads to **more
124+
readable messages** that are easy to follow when looking through the **project history** and while
125+
generating change log.
126+
127+
### Commit Message Format
128+
Each commit message consists of a **header**, a **body** and a **footer**. The header has a special
129+
format that includes a **type**, a **scope** and a **subject**:
130+
131+
```
132+
<type>: <subject>
133+
<BLANK LINE>
134+
<body>
135+
<BLANK LINE>
136+
<footer>
137+
```
138+
139+
The **header** is mandatory.
140+
141+
Any line of the commit message cannot be longer 100 characters! This allows the message to be easier
142+
to read on GitHub as well as in various git tools.
143+
144+
### Revert
145+
If the commit reverts a previous commit, it should begin with `revert: `, followed by the header of the reverted commit.
146+
In the body it should say: `This reverts commit <hash>.`, where the hash is the SHA of the commit being reverted.
147+
148+
### Type
149+
Must be one of the following:
150+
151+
* **feat**: A new feature
152+
* **fix**: A bug fix
153+
* **docs**: Documentation only changes
154+
* **style**: Changes that do not affect the meaning of the code (white-space, formatting, missing
155+
semi-colons, etc)
156+
* **refactor**: A code change that neither fixes a bug nor adds a feature
157+
* **perf**: A code change that improves performance
158+
* **misc**: Changes to the build process or auxiliary tools and libraries such as documentation
159+
generation
160+
161+
### Subject
162+
The subject contains succinct description of the change:
163+
164+
* use the imperative, present tense: "change" not "changed" nor "changes"
165+
* don't capitalize first letter
166+
* no dot (.) at the end
167+
168+
### Body
169+
Just as in the **subject**, use the imperative, present tense: "change" not "changed" nor "changes".
170+
The body should include the motivation for the change and contrast this with previous behavior.
171+
172+
### Footer
173+
The footer should contain any information about **Breaking Changes** and is also the place to
174+
[reference GitHub issues that this commit closes][closing-issues].
175+
176+
**Breaking Changes** should start with the word `BREAKING CHANGE:` with a space or two newlines.
177+
The rest of the commit message is then used for this.
178+
179+
[github]: https://github.com/arrayfire/forge
180+
[gitter]: https://gitter.im/arrayfire/forge
181+
[groups]: https://groups.google.com/forum/#!forum/arrayfire-users
182+
[stackoverflow]: http://stackoverflow.com/questions/tagged/forge

0 commit comments

Comments
 (0)