Contributing

Mykhailo Kolesnyk edited this page Jan 18, 2016 · 7 revisions

Contributing

Claiming Issues

Since github issues does not support assigning an issue to a non collaborator (yet), please just add a comment on the issue to claim it.

Code Guidelines

The code should be pep8 compliant. With the exception that the line width is not limited to 80, but to 120 characters.

The flake8 command can be very helpful (we run it as a separate env through Tox on Travis). If you want to check your changes for code style:

$ flake8

This runs the checks without line widths and other minor checks, it also ignores source files in the migrations and tests and some other folders.

This is the last command to run before submitting a PR (that will run tests in all tox environments):

$ tox

Another useful tool is reindent. It fixes whitespace and indentation stuff:

$ reindent -n filer/models/filemodels.py

Workflow

Fork -> Code -> Pull request

django-filer uses the excellent branching model from nvie. It is highly recommended to use the git flow extension that makes working with this branching model very easy.

  • fork django-filer on github
  • clone your fork git clone git@github.com:username/django-filer.git
  • cd django-filer
  • initialize git flow: git flow init (choose all the defaults)
  • git flow feature start my_feature_name creates a new branch called feature/my_feature_name based on develop
  • ...code... ...code... ..commit.. ..commit..
  • git flow feature publish creates a new branch remotely and pushes your changes
  • navigate to the feature branch on github and create a pull request to the develop branch on divio/django-filer
  • after reviewing the changes may be merged into develop and then eventually into master for the release.

If the feature branch is long running, it is good practice to merge in the current state of the develop branch into the feature branch sometimes. This keeps the feature branch up to date and reduces the likeliness of merge conflicts once it is merged back into develop.