|
| 1 | +# How to contribute |
| 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. |
| 9 | + |
| 10 | +## Getting Started |
| 11 | + |
| 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 |
| 18 | + |
| 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. |
| 31 | + |
| 32 | + |
| 33 | +## Making Trivial Changes |
| 34 | + |
| 35 | +### Documentation |
| 36 | + |
| 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. |
| 40 | + |
| 41 | +```` |
| 42 | + (doc) Add documentation commit example to CONTRIBUTING |
| 43 | +
|
| 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. |
| 47 | +
|
| 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 | +```` |
| 53 | + |
| 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. |
| 60 | + |
| 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. |
| 66 | + |
| 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. |
| 70 | + |
| 71 | +# Additional Resources |
| 72 | + |
| 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/) |
0 commit comments