Permalink
Newer
Older
100644 84 lines (63 sloc) 3.47 KB
Sep 20, 2015 @betatim Short guide on contributing
1 # Contributing
2
3 `everware` is an open source project, and we welcome contributions of all kinds
4
5 To report a bug, open an issue on our [issue tracker][issues].
6
Feb 24, 2016 @ibab Add link to CONDUCT.md in CONTRIBUTING.md
7 Contributors to the project are required to follow the [code of
8 conduct](CONDUCT.md).
9
Sep 20, 2015 @betatim Short guide on contributing
10 By contributing, you are agreeing that we may redistribute your work under
11 [these licenses][license].
12
13 We use the [fork and pull][gh-fork-pull] model to manage changes. More information
14 about [forking a repository][gh-fork] and [making a Pull Request][gh-pull].
15
16 To contribute to this repository:
17
Mar 19, 2016 @betatim Updating contribution guide
18 1. create an issue to explain what problem you are tackling and discuss
19 how you plan to tackle it. Or comment on an existing issue saying you
20 want to tackle it.
Sep 20, 2015 @betatim Short guide on contributing
21 1. fork [the project repository](https://github.com/everware/everware/).
22 Click on the 'Fork' button near the top of the page. This creates a copy of
23 the code under your account on the GitHub server.
24 2. clone this copy of the repository to your local disk:
25
26 $ git clone git@github.com:YourLogin/everware.git
27 $ cd everware
28
29 2. create a new branch in your clone `git checkout -b my-new-branch`. Never
30 work in the ``master`` branch!
31 4. Work on this copy on your computer using Git to do the version
Mar 19, 2016 @betatim Updating contribution guide
32 control. When you're done editing, run:
Sep 20, 2015 @betatim Short guide on contributing
33
34 $ git add modified_files
35 $ git commit
36
37 to record your changes in Git, then push them to GitHub with:
38
39 $ git push -u origin my-new-branch
40
Mar 19, 2016 @betatim Updating contribution guide
41 Finally, go to the web page of your fork of the `everware` repository,
Sep 20, 2015 @betatim Short guide on contributing
42 and click 'Pull request' to send your changes to the maintainers for
Mar 19, 2016 @betatim Updating contribution guide
43 review. This will send an email to the committers. A valid PR includes
44 the following items:
45
Mar 20, 2016 @betatim Link to a rebase howto and motivation for why rebase is preferred
46 * a description of the problem you are solving or reference to an existing issue
Mar 19, 2016 @betatim Updating contribution guide
47 * a discussion why you made the choices you made
48 * contains the minimal set of changes needed to solve the problem (do
49 not mix several issues, rather create separate PRs)
50 * unit and frontend tests for your changes
51 * the code should follow the style of the project
52 * the code should contain documentation in the form of docstrings
53 and comments
Mar 20, 2016 @betatim Link to a rebase howto and motivation for why rebase is preferred
54 * [do not merge master]
55 (https://www.atlassian.com/git/tutorials/merging-vs-rebasing/conceptual-overview)
56 into your feature branch, instead [rebase your branch]
57 (https://github.com/edx/edx-platform/wiki/How-to-Rebase-a-Pull-Request).
Mar 19, 2016 @betatim Updating contribution guide
58
Mar 20, 2016 @betatim Incorporate comments from @anaderi
59 These are guidelines and not hard rules, so if you feel one of them does not
60 apply, write a short sentence in the PR's description explaining why you
61 skipped it.
62
Mar 19, 2016 @betatim Updating contribution guide
63 We encourage you to start your PR as soon as possible to get feedback early.
64 Mark it as `[WIP] your subject` if it is not ready for merging. We will try and
65 respond as quickly as possible, but we are all volunteers so it might take 24h.
66 Maintainers, please leave some time for others to think and respond before
67 merging.
68
69 We prefer "getting it right" and having a maintainable project over chasing
70 features or doing things in a hurry.
71
72 Expect to get feedback and suggestions for improvement. This is not a sign that
Mar 20, 2016 @betatim Link to a rebase howto and motivation for why rebase is preferred
73 you are stupid, instead it shows the others care about your changes, want to
Mar 19, 2016 @betatim Updating contribution guide
74 make them better and help you out with things you missed.
Sep 20, 2015 @betatim Short guide on contributing
75
Mar 20, 2016 @betatim Link to a rebase howto and motivation for why rebase is preferred
76 **There is one additional rule:** no one can merge their own pull requests,
77 someone else has to press the button.
Sep 20, 2015 @betatim Short guide on contributing
78
79 [issues]: https://github.com/everware/everware/issues
Sep 20, 2015 @betatim Typo in LICENSE link
80 [license]: LICENSE
Sep 20, 2015 @betatim Short guide on contributing
81 [gh-fork]: https://help.github.com/articles/fork-a-repo/
82 [gh-pull]: https://help.github.com/articles/using-pull-requests/
83 [gh-fork-pull]: https://help.github.com/articles/using-pull-requests/#fork--pull