X-Git-Url: http://git.ithinksw.org/philo.git/blobdiff_plain/d6b4a9041aaccc3e6fac9dbdac4b581ef2e4b573..55b9014e00e00ba004d9c96e0f8e9cce2f203e89:/docs/contributing.rst?ds=sidebyside diff --git a/docs/contributing.rst b/docs/contributing.rst index 8d905b1..4c9fb7d 100644 --- a/docs/contributing.rst +++ b/docs/contributing.rst @@ -3,14 +3,15 @@ Contributing to Philo So you want to contribute to Philo? That's great! Here's some ways you can get started: -* **Report bugs and request features.** :mod:`philo` uses a Redmine installation located at `http://ithinksw.org/projects/philo/issues `_ for issue tracking. In order to report an issue, you will need to register for an account with the tracker. -* **Contribute code.** Philo uses git to manage its code. You can fork philo's repository either on `GitHub `_ or `Gitorious `_. If you are contributing to Philo, you will need to submit a :ref:`Contributor License Agreement `. -* **Join the discussion** on IRC at `irc://irc.oftc.net/#philo `_ if you have any questions or suggestions or just want to chat about the project. You can also keep in touch via :mod:`philo`'s mailing lists: `philo@ithinksw.org `_ and `philo-devel@ithinksw.org `_. +* **Report bugs and request features** using the issue tracker at the `project site `_. +* **Contribute code** using `git `_. You can fork philo's repository either on `GitHub `_ or `Gitorious `_. If you are contributing to Philo, you will need to submit a :ref:`Contributor License Agreement `. +* **Join the discussion** on IRC at `irc://irc.oftc.net/#philo `_ if you have any questions or suggestions or just want to chat about the project. You can also keep in touch using the project mailing lists: `philo@ithinksw.org `_ and `philo-devel@ithinksw.org `_. Branches and Code Style +++++++++++++++++++++++ -We use `A successful Git branching model`__ with the blessed repository. To make things easier, you probably should too. This means that you should work on and against the develop branch in most cases, and leave it to the release manager to create the commits on the master branch if and when necessary. Regardless of what you do, the release manager will usually merge your changes into the develop branch unless you explicitly note they should be treated otherwise. + +We use `A successful Git branching model`__ with the blessed repository. To make things easier, you probably should too. This means that you should work on and against the develop branch in most cases, and leave it to the release manager to create the commits on the master branch if and when necessary. When pulling changes into the blessed repository at your request, the release manager will usually merge them into the develop branch unless you explicitly note they be treated otherwise. __ http://nvie.com/posts/a-successful-git-branching-model/ @@ -21,7 +22,7 @@ Philo adheres to PEP8 for its code style, with two exceptions: tabs are used rat Licensing and Legal +++++++++++++++++++ -In order for the release manager to merge your changes into the blessed repository, you will need to submit a signed CLA. Our CLAs are based on the Apache Software Foundation's CLAs, which is the same source as the `Django Project's CLAs`_. You might, therefore, find the `Django Project's CLA FAQ`_. helpful. +In order for the release manager to merge your changes into the blessed repository, you will need to have already submitted a signed CLA. Our CLAs are based on the Apache Software Foundation's CLAs, which is the same source as the `Django Project's CLAs`_. You might, therefore, find the `Django Project's CLA FAQ`_. helpful. .. _`Django Project's CLAs`: https://www.djangoproject.com/foundation/cla/ .. _`Django Project's CLA FAQ`: https://www.djangoproject.com/foundation/cla/faq/