|
1 | 1 | # How to contribute |
2 | 2 |
|
3 | | -Community contributions are essential part of any open source project. The |
4 | | -community has access to a large number of unique configurations which would |
5 | | -be extremely difficult for the core maintainers to reproduce. We want to keep |
6 | | -it as easy as possible to contribute changes that get things working in your |
7 | | -environment. There are a few guidelines that we need contributors to follow |
8 | | -so that we can have a chance of keeping on top of things. |
| 3 | +Community contributions are essential part of any open source project. The community has access to a large number of unique configurations which would be extremely difficult for the core maintainers to reproduce. We want to keep it as easy as possible to contribute changes that get things working in your environment. There are a few guidelines that we need contributors to follow so that we can have a chance of keeping on top of things. |
9 | 4 |
|
10 | | -## Getting Started |
| 5 | +Make sure you have a [GitHub account](https://github.com/signup/free) to start with. |
11 | 6 |
|
| 7 | +## Level 1 contributions: easy ways to contribute |
| 8 | +There are several ways to contribute, depending on your background, level of expertise and willingness to spend some time. Everybody should be able to contribute on a minimal level: |
| 9 | +* Create or document issues |
| 10 | +* Create or improve documentation |
| 11 | +* Be a tester |
12 | 12 |
|
13 | | -* Make sure you have a [GitHub account](https://github.com/signup/free) |
14 | | -* **Submit an issue** for your issue, assuming one does not already exist. If you have the rights, you should assign yourself to the issue. If you do not have that ability please add a comment noting that a pull request will be submitted for the issue. After review, if the pull request is accepted, we will mark the issue as resolved and assign it to a release so it can be QA'ed. |
15 | | - * Clearly describe the issue including steps to reproduce when it is a bug. |
16 | | - * Make sure you fill in the earliest version that you know has the issue. |
17 | | -* Fork the repository on GitHub |
| 13 | +### Create issues |
| 14 | +Anybody with a GutHub account can create new issues. Please verify that a simlar issue has not been created before. Clearly describe the issue you encounter. |
18 | 15 |
|
19 | | -## Making Changes |
20 | | - |
21 | | -* Create a topic branch from where you want to base your work. |
22 | | - * This is usually the 'development' branch. |
23 | | - * Release branches should only be targeted by official committers. |
24 | | - * To quickly create a topic branch based on development; `git checkout -b my_contribution development` |
25 | | -* Make commits of logical units. |
26 | | -* Check for unnecessary whitespace with `git diff --check` before committing. |
27 | | -* Make sure your commit messages are in the proper format |
28 | | -* For bonus points run and add unit tests |
29 | | - * Make sure you have added the necessary tests for your changes. |
30 | | - * Run _all_ the tests to assure nothing else was accidentally broken. |
| 16 | +### Create or improve documentation |
| 17 | +Create an issue with suggestions for document improvements. If you have an idea about the new documenation, add that text (prefereably in markdown format) in the issue as proposed new or improved documentation. |
31 | 18 |
|
| 19 | +### Be a tester |
| 20 | +Download an install version of the extension and test it in your own environment. If you are reviewing issues, try to reproduce issues that have been created and enhance documentation of the issue to reproduce any bugs. |
32 | 21 |
|
33 | | -## Making Trivial Changes |
| 22 | +If there is a new version of an extension, be one of the first to test that new version on a fresh install and as an upgrade of a previous version. Report your findings as issues. |
34 | 23 |
|
35 | | -### Documentation |
| 24 | +# Level 2 contributions: Provide improved or new code |
| 25 | +If you are commited as community member and have programming skills, there is more that you can do: |
| 26 | +* Create code fixes |
| 27 | +* Create new functionality |
36 | 28 |
|
37 | | -For changes of a trivial nature to comments and documentation, it is not |
38 | | -always necessary to create a new ticket in the issue tracker. In this case, it is appropriate to start the first line of a commit with '(doc)' instead of |
39 | | -a ticket number. |
| 29 | +We asume that you have some basic Git(Hub) knowledge and know how to work with fork, clone, create issue, commit, push, pull requests |
40 | 30 |
|
41 | | -```` |
42 | | - (doc) Add documentation commit example to CONTRIBUTING |
| 31 | +## Get started with code contributions |
43 | 32 |
|
44 | | - There is no example for contributing a documentation commit |
45 | | - to the DNN repository. This is a problem because the contributor |
46 | | - is left to assume how a commit of this nature may appear. |
| 33 | +### Fork the repository on GitHub |
| 34 | +If this is your first time working with the repository, you will need to fork the repository to get your system configured for local development. |
47 | 35 |
|
48 | | - The first line is a real life imperative statement with '(doc)' in |
49 | | - place of what would have been the ticket number in a |
50 | | - non-documentation related commit. The body describes the nature of |
51 | | - the new documentation or comments added. |
52 | | -```` |
| 36 | +If you are new to Dnn Development, you can start by watching this video playlist which explains how to setup the required tools, your development environment and submit pull requests for modules, the Platform and the Persona Bar. |
| 37 | +[How to make a pull requests playlist](https://www.youtube.com/playlist?list=PLIx1M8IdVvqZ0bnODGqJyxvONNPj5BzMP) |
53 | 38 |
|
54 | | -## Submitting Changes |
55 | | - |
56 | | -* Sign the [Contributor License Agreement](http://www.dnnsoftware.com). |
57 | | -* Push your changes to a topic branch in your fork of the repository. |
58 | | -* Submit a pull request to the DNN.Platform repository in the DNNSoftware organization. |
59 | | -* The committers will handle updating the associated issue in the DNN Tracker to ensure it gets the necessary code review and QA. |
| 39 | +* Click fork on the project. You will get a fork of the repository in your own GitHub account |
| 40 | +* Clone your fork locally with `git clone |
| 41 | +* Add the *upstream connection* to the original repository, so you can rebase and update your fork with `git remote add upstream` to the base (the original) repository |
| 42 | +* To update your fork to the latest, you can then run `git fetch upstream` followed by `git push` |
| 43 | + |
| 44 | +## Making Changes |
| 45 | +* Create a topic branch from where you want to base your work. This is usually a branch linked to the *issue #* your are trying to solve |
| 46 | +* Make commits of logical units |
| 47 | +* When ready to publish your changes, you can with `git push -u origin my_contribution` |
| 48 | +* Make sure your pull request description tags the GitHub issue ID, so it is clear what issue you have fixed |
| 49 | +* Make sure your commit messages are in the proper format |
60 | 50 |
|
61 | | -## Acceptance of your Changes |
62 | | -* We have a group of fellow developers that review pull requests submitted by developers like yourself. |
63 | | -* If your changes look good, then changes are merged to an appropriate release. |
64 | | -* We may ask you to make further changes or reject the change (with proper reasonsing - we hope that's not the case though). |
65 | | -* You should get an email notification as we complete processing of your pull request. |
| 51 | +## Submitting changes |
| 52 | +* Push your changes to a topic branch in your fork of the repository |
| 53 | +* Submit a pull request to the original (upstream( repository |
| 54 | +* The committers will handle updating the associated issue in the DNN Tracker to ensure it gets the necessary code review and QA |
66 | 55 |
|
67 | | -## Downloading latest package with your changes |
68 | | -* As soon as changes are accepted, our team city build server gets into action. |
69 | | -* New builds are usually available within 10 minutes of acceptance. |
| 56 | +## Acceptance of your changes |
| 57 | +* We have a group of fellow developers that review pull requests submitted by developers like yourself |
| 58 | +* If your changes look good, then changes are merged to an appropriate release |
| 59 | +* You should get an email notification as we complete processing of your pull request |
70 | 60 |
|
71 | | -# Additional Resources |
| 61 | +# Level 3 contributions: Become a repository custodian |
| 62 | +If you are really commited, want to work with highly commited team members (like yourself?) and want to contibute by taking care of one or more repositories, you might want to become a *repository custodian*. |
72 | 63 |
|
73 | | -* [Contributor License Agreement](http://www.dnnsoftware.com) |
74 | | -* [General GitHub documentation](http://help.github.com/) |
75 | | -* [GitHub pull request documentation](http://help.github.com/send-pull-requests/) |
| 64 | +Contact one of the team members of the organisation and discuss the opportunities. |
0 commit comments