Like every open-source project, Django-CMS is always looking for motivated individuals to contribute to it’s source code. However, to ensure the highest code quality and keep the repository nice and tidy, everybody has to follow a few rules (nothing major, I promise :) )
People interested in developing for the django-cms should join the django-cms-developers mailing list as well as heading over to #django-cms on freenode for help and to discuss the development.
You may also be interested in following @djangocmsstatus on twitter to get the github commits as well as the hudson build reports. There is also a @djangocms account for less technical announcements.
Here’s what the contribution process looks like, in a bullet-points fashion, and only for the stuff we host on github:
If you’re interested in developing a new feature for the cms, it is recommended that you first discuss it on the django-cms-developers mailing list so as not to do any work that will not get merged in anyway.
Since we’re hosted on github, django-cms uses git as a version control system.
The Github help is very well written and will get you started on using git and github in a jiffy. It is an invaluable resource for newbies and old timers alike.
We try to conform to PEP8 as much as possible. A few highlights:
This is how you fix a bug or add a feature:
Having a wide and comprehensive library of unit-tests and integration tests is of exceeding importance. Contributing tests is widely regarded as a very prestigious contribution (you’re making everybody’s future work much easier by doing so). Good karma for you. Cookie points. Maybe even a beer if we meet in person :)
Generally tests should be:
In a similar way to code, pull requests will be reviewed before pulling (obviously), and we encourage discussion via code review (everybody learns something this way) or IRC discussions.
To run the tests simply execute runtests.sh from your shell. To make sure you have the correct environment you should also provide the --rebuild-env flag, but since that makes running the test suite slower, it’s disabled by default. You can also see all flags using --help.
Perhaps considered “boring” by hard-core coders, documentation is sometimes even more important than code! This is what brings fresh blood to a project, and serves as a reference for old timers. On top of this, documentation is the one area where less technical people can help most - you just need to write a semi-decent English. People need to understand you. We don’t care about style or correctness.
Documentation should be:
Pulling of documentation is pretty fast and painless. Usually somebody goes over your text and merges it, since there are no “breaks” and that github parses rst files automagically it’s really convenient to work with.
Also, contributing to the documentation will earn you great respect from the core developers. You get good karma just like a test contributor, but you get double cookie points. Seriously. You rock.
We use Python documentation conventions fo section marking:
For translators we have a transifex account where you can translate the .po files and don’t need to install git or mercurial to be able to contribute. All changes there will be automatically sent to the project.