- Contributing to REST framework -
- Community +
- Community +
- Code of conduct
- Issues +
- Triaging issues
- Development -
- Testing +
- Testing +
- Pull requests +
- Managing compatibility issues
- Documentation
- Building the documentation
- Language style
- Markdown style -
- Third party packages -
- Core committers
- When describing issues try to phrase your ticket in terms of the behavior you think needs changing rather than the code you think need changing.
- Search the issue list first for related items, and make sure you're running the latest version of REST framework before reporting an issue. -
-
-
If reporting a bug, then try to include a pull request with a failing test case. This will help us quickly identify if there is a valid issue, and make sure that it gets fixed more quickly if there is one.
-
- -
-
TODO: Triage
-
+ - If reporting a bug, then try to include a pull request with a failing test case. This will help us quickly identify if there is a valid issue, and make sure that it gets fixed more quickly if there is one.
- git clone & PYTHONPATH -
- Pep8 -
- Recommend editor that runs pep8 -
- Make pull requests early -
- Describe branching -
- Describe compat module -
- Running the tests -
- tox +
- Read through the ticket - does it make sense, is it missing any context that would help explain it better? +
- Is the ticket reported in the correct place, would it be better suited as a discussion on the discussion group? +
- If the ticket is a bug report, can you reproduce it? Are you able to write a failing test case that demonstrates the issue and that can be submitted as a pull request? +
- If the ticket is a feature request, do you agree with it, and could the feature request instead be implemented as a third party package?
- Keep paragraphs reasonably short.
- Use double spacing after the end of sentences. -
- Don't use the abbreviations such as 'e.g..' but instead use long form, such as 'For example'. +
- Don't use the abbreviations such as 'e.g.' but instead use long form, such as 'For example'.
- Django reusable app -
- Still use pull reqs -
- Credits -
@@ -215,44 +218,61 @@
There are many ways you can contribute to Django REST framework. We'd like it to be a community-led project, so please get involved and help shape the future of the project.
-Community
-If you use and enjoy REST framework please consider staring the project on GitHub, and upvoting it on Django packages. Doing so helps potential new users see that the project is well used, and help us continue to attract new users.
-You might also consider writing a blog post on your experience with using REST framework, writing a tutorial about using the project with a particular javascript framework, or simply sharing the love on Twitter.
+Community
+The most important thing you can do to help push the REST framework project forward is to be actively involved wherever possible. Code contributions are often overvalued as being the primary way to get involved in a project, we don't believe that needs to be the case.
+If you use REST framework, we'd love you to be vocal about your experiances with it - you might consider writing a blog post on your experience with using REST framework, or publishing a tutorial about using the project with a particular javascript framework. Experiances from beginners can be particularly helpful because you'll be in the best position to assess which bits of REST framework are and aren't easy to understand and work with.
Other really great ways you can help move the community forward include helping answer questions on the discussion group, or setting up an email alert on StackOverflow so that you get notified of any new questions with the django-rest-framework tag.
When answering questions make sure to help future contributors find their way around by hyperlinking wherever possible to related threads and tickets, and include backlinks from those items if relevant.
+Code of conduct
+Please keep the tone polite & professional. For some users a discussion on the REST framework mailing list or ticket tracker may be their first engagement with the open source community. First impressions count, so let's try to make everyone feel welcome.
+Be mindful in the language you choose. As an example, in an environment that is heavily male-dominated, posts that start 'Hey guys,' can come across as unintentionally exclusive. It's just as easy, and more inclusive to use gender neutral language in those situations.
+The Django code of conduct gives a fuller set of guidelines for participating in community forums.
Issues
-It's really helpful if you make sure you address issues to the correct channel. Usage questions should be directed to the discussion group. Feature requests, bug reports and other issues should be raised on the GitHub issue tracker.
+It's really helpful if you can make sure to address issues on the correct channel. Usage questions should be directed to the discussion group. Feature requests, bug reports and other issues should be raised on the GitHub issue tracker.
Some tips on good issue reporting:
Development
--
-
Pull requests
--
-
Managing compatibility issues
--
-
Testing
+Triaging issues
+Getting involved in triaging incoming issues is a good way to start contributing. Every single ticket that comes into the ticket tracker needs to be reviewed in order to determine what the next steps should be. Anyone can help out with this, you just need to be willing to
-
-
Development
+To start developing on Django REST framework, clone the repo:
+git clone git@github.com:tomchristie/django-rest-framework.git
+Changes should broadly follow the PEP 8 style conventions, and we recommend you setup your editor to automatically indicated non-conforming styles.
+Testing
+To run the tests, clone the repository, and then:
+# Setup the virtual environment
+virtualenv env
+env/bin/activate
+pip install -r requirements.txt
+pip install -r optionals.txt
+
+# Run the tests
+rest_framework/runtests/runtests.py
+You can also use the excellent [tox][tox] testing tool to run the tests against all supported versions of Python and Django. Install tox globally, and then simply run:
tox
+Pull requests
+It's a good idea to make pull requests early on. A pull request represents the start of a discussion, and doesn't necessarily need to be the final, finished submission.
+It's also always best to make a new branch before starting work on a pull request. This means that you'll be able to later switch back to working on another seperate issue without interfering with an ongoing pull requests.
+It's also useful to remember that if you have an outstanding pull request then pushing new commits to your GitHub repo will also automatically update the pull requests.
+GitHub's documentation for working on pull requests is available here.
+Always run the tests before submitting pull requests, and ideally run tox in order to check that your modifications are compatible with both Python 2 and Python 3, and that they run properly on all supported versions of Django.
Once you've made a pull request take a look at the travis build status in the GitHub interface and make sure the tests are runnning as you'd expect.
+
Above: Travis build notifications
+Managing compatibility issues
+Sometimes, in order to ensure your code works on various different versions of Django, Python or third party libraries, you'll need to run slightly different code depending on the environment. Any code that branches in this way should be isolated into the compat.py module, and should provide a single common interface that the rest of the codebase can use.
Documentation
The documentation for REST framework is built from the Markdown source files in the docs directory.
There are many great markdown editors that make working with the documentation really easy. The Mou editor for Mac is one such editor that comes highly recommended.
@@ -270,7 +290,7 @@Markdown style
There are a couple of conventions you should follow when working on the documentation.
@@ -299,19 +319,10 @@ More text...If you want to draw attention to a note or warning, use a pair of enclosing lines, like so:
---
-**Note:** Make sure you do this thing.
+**Note:** A useful documentation note.
---
Third party packages
--
-
Core committers
--
-