CONTRIBUTING.md 9.27 KB
Newer Older
1
2
# Contributing to What's Open

3
We would love for you to contribute to What's Open and help make it even better
4
5
6
than it is today! As a contributor, here are the guidelines we would like you to
follow:

7
8
9
10
11
12
13
- [Code of Conduct](#coc)
- [Question or Problem?](#question)
- [Issues and Bugs](#issue)
- [Feature Requests](#feature)
- [Submission Guidelines](#submit)
- [Coding Rules](#rules)
- [Commit Message Guidelines](#commit)
14
15
16

## <a name="coc"></a> Code of Conduct

17
Help us keep What's Open open and inclusive. Please read and follow the
18
19
20
21
[GMU Student Code of Conduct][coc].

## <a name="question"></a> Got a Question or Problem?

22
23
24
Please, do not open issues for the general support questions as we want to keep
GitLab issues for bug reports and feature requests. You've got much better
chances of getting your question answered on [Slack Group][slack] where
25
26
27
28
29
questions should be asked in their respective channels.

## <a name="issue"></a> Found a Bug?

If you find a bug in the source code, you can help us by
30
[submitting an issue](#submit-issue) to our [GitLab Repository][gitlab]. Even
31
32
33
34
better, you can [submit a Merge Request](#submit-pr) with a fix.

## <a name="feature"></a> Missing a Feature?

35
36
You can _request_ a new feature by [submitting an issue](#submit-issue) to our
GitLab Repository. If you would like to _implement_ a new feature, please ensure
37
38
an issue already exists to be associated with your commits.

39
40
41
- For any **contribution**, first [open an issue](#submit-issue) and outline your proposal so that it can be
  discussed. This will also allow us to better coordinate our efforts, prevent duplication of work,
  and help you to craft the change so that it is successfully accepted into the project.
42
43
44
45
46

## <a name="submit"></a> Submission Guidelines

### <a name="submit-issue"></a> Submitting an Issue

47
48
Before you submit an issue, please search through open issues, maybe an issue for
your problem already exists and the discussion might inform you of workarounds
49
50
readily available.

51
52
53
We want to fix all the issues as soon as possible, but before fixing a bug we
need to reproduce and confirm it. In order to reproduce bugs we may
ask you to describe a use-case that fails to assist in the debugging process.
54

55
In GitLab there are issue templates that you can use which paste in a sample
56
57
58
59
60
61
62
63
64
65
format for you to use.

Check out the following issue for an example: [https://git.gmu.edu/srct/whats-open/issues/31](https://git.gmu.edu/srct/whats-open/issues/31)

You can file new issues by filling out our [new issue form][new-issue].

### <a name="submit-pr"></a> Steps to contribute and submit a Merge Request (MR)

Before you submit your Merge Request (MR) consider the following steps:

66
67
- Search [GitLab][merge-request] for an open or closed MR that relates to your
  submission. You don't want to duplicate effort.
68

69
- Pull the latest commits from GitLab
70

71
72
73
  ```sh
  git pull
  ```
74

75
- Check into the current development branch:
76

77
78
  All new commits are merged into this development branch before going live on
  the site in a tagged release (merge into master branch).
79

80
81
82
  ```sh
  git checkout consolidation
  ```
83

84
- Create a new git branch:
85

86
87
88
89
90
  ```sh
  git checkout -B ##-shortdescription
  # Example
  git checkout -B 31-contibution-guidelines-proposal
  ```
91

92
93
94
95
96
97
  All branches need to follow the above convention (`##-shortdescription`) `##`
  in this case represents the issue number that your branch is related to. Each
  issue has one and only one branch and each branch has one and only one purpose:
  to add, modify, or remove a feature/bug from the repo. `shortdescription` is
  a few hyphon (`-`) seperated words that consisely describe the branch. This helps people
  who may be unfamiliar with the issue number to know at a glance what the branch
98

99
100
101
- Now you're ready to write your code in your new branch! Make sure to follow
  listed [style](#rules) & [commit](#commit) guidelines/rules when contributing
  code.
102

103
104
105
106
- Unit tests are run at the CI (GitLab-CI) level once you push your code to GitLab.
  We do this to ensure that the project builds properly and passes tests. In general,
  if you are adding some new piece of code like a function you must **include
  appropriate test cases**.
107

108
  For example if I compose the following function:
109

110
111
112
113
114
  ```python
  # file.py
  def oneplus(num):
      return num + 1
  ```
115

116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
  then I would additionally write the following test case:

  ```python
  # test_file.py
  def TestOneplus(TestCase):
      assertEquals(oneplus(1), 2)
  ```

- Before you push your code to GitLab it is suggested that you run all unit tests locally.

  ```sh
  python manage.py test
  ```

- Commit your changes using a descriptive commit message that follows our
  [commit message conventions](#commit). Adherence to these conventions is strongly
  suggested as it makes it easier to determine what each commit does when, for example,
  things break.

  ```sh
  git add --all
  git commit # first line is title, two newlines is description
  ```
139

140
141
142
- You will need to ask in the slack channel to be added to the GitLab repo. This
  step is necessary such that you have the necessary permissions to push up your
  branch.
143

144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
- Push your branch to GitLab:

  ```sh
  git push origin ##-shortdescription
  # ex.
  git push origin 31-contibution-guidelines-proposal
  ```

- In GitLab, send a merge request to the current development branch.

- If we suggest changes to your branch then:

  - Make the required updates.
  - Re-run the unit tests to ensure tests are still passing.
  - Rebase your branch and force push to your GitLab repository (this will update
159
160
161
162
163
164
165
166
167
168
169
    your Merge Request):

    ```sh
    git rebase consolidation -i
    git push -f
    ```

That's it! Thank you for your contribution! :tada:

#### After your merge request is merged

170
After your merge request is merged, you can safely delete your branch and merge
171
172
the changes from the main (upstream) repository:

173
174
- Delete the remote branch on GitLab either through the GitLab web UI or your
  local shell as follows:
175

176
177
178
179
180
  ```sh
  git push origin --delete ##-shortdescription
  # ex.
  git push origin --delete 31-contibution-guidelines-proposal
  ```
181

182
- Check out the current development branch:
183

184
185
186
  ```sh
  git checkout consolidation -f
  ```
187

188
- Delete the local branch:
189

190
191
192
193
194
  ```sh
  git branch -D ##-shortdescription
  # ex.
  git branch -D 31-contibution-guidelines-proposal
  ```
195

196
- Update your current development branch with the latest upstream version:
197

198
199
200
  ```sh
  git l --ff upstream consolidation
  ```
201
202
203
204
205
206

## <a name="rules"></a> Coding Rules

To ensure consistency throughout the source code, keep these rules in mind as you
are working:

207
208
- All features or bug fixes **must be tested** by one or more specs (unit-tests).
- We follow [the PEP8 styleguide][style-guide].
209
210
211
212
213
214
215
216

## <a name="commit"></a> Commit Message Guidelines

Consistant commit messages are easier to follow when looking through the **project
history**.

### Commit Message Format

217
Each commit message consists of a **header**, a **body** and a **footer**. The
218
219
220
221
222
223
224
225
226
227
228
229
230
header has a special format that includes a **type** and a **subject**. The **header**
is mandatory.

Layout:

```
<type>: <subject> # this is the <header>
<BLANK LINE>
<body>
<BLANK LINE>
<footer>
```

231
Sample headers:
232
233
234
235

```
docs: update change log to beta.5
```
236

237
238
239
240
241
```
fix: need to depend on latest rxjs and zone.js
```

### \<header> Type
242

243
244
Must be one of the following:

245
246
247
248
249
250
251
252
253
254
255
- **build**: Changes that affect the build system or external dependencies
  (example scopes: gulp, broccoli, npm)
- **ci**: Changes to our gitlab-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
- **style**: Changes that do not affect the meaning of the code (white-space, formatting,
  etc.)
- **test**: Adding missing tests or correcting existing tests
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280

### \<header> Subject

The subject contains succinct description of the change.

Sample Subject:

```
add in contributing guide
```

### Body

The body should include a brief description of the changes made in the commit to
provide additional detail.

Sample Body:

```
- Introduce my proposal for CONTRIBUTING.md
- Filled with the whats-open-web contributing guide but contains friendlier language
```

### Footer

281
The footer should contain any information about **Breaking Changes** (**Breaking
282
Changes** should start with the word `BREAKING CHANGE:` with a space or two newlines.
283
The rest of the commit message is then used for this. and is also the place to
284
285
286
reference GitLab issues that this commit **Closes**.

Sample footers:
287

288
```
289
BREAKING CHANGE: remove outdated dependency from requirements.txt. be sure to
290
291
292
293
294
295
reinstall your packages in order for the project to build.
```

```
Closes #31
```
296

297
298
299
300
301
302
303
304
305
306
This "Closes" statement should only be incuded in commits that resolve an issue.
What's nice about the statement itself is that when the commit is merged, the issue
will auto close.

If neither of these situations are the case (breaking changes or issue closing)
then feel free to omit the footer.

[coc]: https://studentconduct.gmu.edu/wp-content/uploads/2011/09/2016-17-Code-of-Student-Conduct.pdf
[gitlab]: https://git.gmu.edu/srct/whats-open
[style-guide]: https://www.python.org/dev/peps/pep-0008/
307
308
309
[slack]: https://srct.slack.com/
[new-issue]: https://git.gmu.edu/srct/whats-open/issues/new
[merge-request]: https://git.gmu.edu/srct/whats-open/merge_requests