|
1 | 1 | # How to contribute |
2 | 2 |
|
3 | | -We heartily welcome contributions to the source code for the Adapt Authoring |
4 | | -project. This document outlines some contributor guidlines to help you get |
5 | | -started. |
6 | | - |
7 | | -## Getting Started |
8 | | - |
9 | | -* Make sure you have a [GitHub account](https://github.com/signup/free) |
10 | | -* Pick an open issue from the list [here](https://github.com/adaptlearning/adapt_authoring/issues) OR |
11 | | -* Submit a ticket for an issue you have noticed |
12 | | - * If submitting a bug, clearly describe the issue including steps to |
13 | | - reproduce and add the "bug" label |
14 | | - * If submitting a request for a new feature, add the "enhancement" |
15 | | - label |
16 | | -* Fork the repository on [GitHub](https://github.com/adaptlearning/adapt_authoring) |
17 | | -* Follow the developer set-up guide [here](https://github.com/adaptlearning/adapt_authoring/wiki/Developer's-Install) |
18 | | - |
19 | | -We try to add one of the following labels to all our issues to indicate difficulty: |
20 | | - |
21 | | -* Easy |
22 | | -* Medium |
23 | | -* Hard |
24 | | -* Insane |
25 | | - |
26 | | -Picking up an "Easy" issue is a good way to start contributing if you have |
27 | | -not worked on a nodejs or backbone project before. Otherwise, you should have |
28 | | -no problems working on a "Medium" issue. "Hard" and "Insane" issues are |
29 | | -targeted at contributors that have had extensive experience of developing |
30 | | -for this project. |
| 3 | +We heartily welcome contributions to the source code for the Adapt authoring project. This document outlines some contributor guidelines to help you get started. |
| 4 | + |
| 5 | +## Before you begin |
| 6 | + |
| 7 | +* Make sure you have a [GitHub account](https://github.com/signup/free), as all contributions are made through GitHub. |
| 8 | +* Fork the [`adapt_authoring`](https://github.com/adaptlearning/adapt_authoring) repository to your GitHub account. |
| 9 | +* Follow the [developer set-up guide](https://github.com/adaptlearning/adapt_authoring/wiki/Developer's-Install) to get a developer instance of the authoring tool installed. |
| 10 | + |
| 11 | +## Finding work |
| 12 | + |
| 13 | +* Pick an open issue from the list [here.](https://github.com/adaptlearning/adapt_authoring/issues) |
| 14 | +* Create a new ticket for the issue you have noticed, following our guidelines on [submitting new bugs and features.](https://github.com/adaptlearning/adapt_framework/wiki/Bugs-and-features) |
| 15 | + * If submitting a new ticket, we recommend getting the go-ahead for the change from the core team before you start work. |
| 16 | + |
| 17 | +### Use the labels |
| 18 | + |
| 19 | +We add difficulty rating labels to issues to give developers an idea of the work involved (always prefixed with `D:`). Picking up a `D: beginner` or `D: easy` issue is a good place to start if you're new to the project, and have limited Node.js and Backbone.js experience. For more confident developers, `D: medium` issues should be no problem. Any `D: hard` and `D: insane` issues are likely to involve very complex solutions, and potentially collaboration, to solve. Due to the work involved, these should only be attempted by developers with an extensive knowledge of the codebase, and a good working relationship with the core team. |
31 | 20 |
|
32 | 21 | ## Making Changes |
33 | 22 |
|
34 | | -* Create a new branch named for the issue that you are fixing, and base it on |
35 | | - the target branch (e.g. `git checkout -b issues/123 origin/develop`) |
36 | | -* Make your changes |
37 | | -* Add some tests if your changes warrant it |
38 | | -* Run all tests using `npm test` |
39 | | -* Commit your changes using [best practice](http://www.git-scm.com/book/en/v2/Distributed-Git-Contributing-to-a-Project#Commit-Guidelines) in your commit message and take |
40 | | - advantage of GitHub's built in features to [close issues via commits](https://help.github.com/articles/closing-issues-via-commit-messages/) |
| 23 | +* Create a new branch for the issue that you are fixing: |
| 24 | + * Make sure to base it on the correct parent branch; in most cases this will be develop. Getting this step wrong may cause you a lot of heartbreak when it comes to merging later on, so it's worth checking before starting work. |
| 25 | + * Name your branch according to the issue it addresses (i.e. `issue/1234`). |
| 26 | + * Create your branch (e.g. `git checkout -b issue/123 origin/develop`). |
| 27 | +* Make your changes (please make sure that your commit messages stick to the [guidelines](http://www.git-scm.com/book/en/v2/Distributed-Git-Contributing-to-a-Project#Commit-Guidelines), and take advantage of GitHub's built in features to [close issues via commits.](https://help.github.com/articles/closing-issues-via-commit-messages/) |
| 28 | +* Add unit tests to cover your new functionality, if appropriate. |
| 29 | +* Run the existing unit tests using `npm test` (and ensure they pass!) |
41 | 30 |
|
42 | 31 | ## Submitting Changes |
43 | 32 |
|
44 | | -* Push your changes to your fork of the adapt_authoring repository |
45 | | -* Submit a pull request using the GitHub interface, and reference the issue |
46 | | - number |
47 | | -* The core team will be automatically notified of your changes, but you can |
48 | | - also bring it to our attention via the [gitter.im channel](https://gitter.im/adaptlearning/adapt_authoring) |
| 33 | +* Push your changes to your personal fork of the `adapt_authoring` repository. |
| 34 | +* Submit a pull request using the GitHub interface, and make sure to link to the issue you're addressing. |
| 35 | +* The core team will be automatically notified of your changes, but you can also bring it to our attention via the [gitter.im channel](https://gitter.im/adaptlearning/adapt_authoring). |
49 | 36 |
|
50 | 37 | # Additional Resources |
51 | 38 |
|
|
0 commit comments