Like every open-source project, django CMS is always looking for motivated individuals to contribute to its source code.
There’s more guidance on how to contribute in our documentation.
Key points:
Attention
If you think you have discovered a security issue in our code, please report it privately, by emailing us at security@django-cms.org.
Please do not raise it on:
- IRC
- GitHub
- either of our email lists
or in any other public forum until we have had a chance to deal with it.
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 the freenode IRC network 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:
As of django CMS 3.1, we will use spaces within frontend code, not tabs as previously. In the meantime, please continue using tabs - all tabs will be converted to spaces in a single commit for 3.1.
Frontend code should be formatted for readability. If in doubt, follow existing examples, or ask.
This is how you fix a bug or add a feature:
And at any point in that process, you can add: discuss discuss discuss, because it’s always useful for everyone to pass ideas around and look at things together.
Running and writing tests is really important: a pull request that lowers our testing coverage will only be accepted with a very good reason; bug-fixing patches must demonstrate the bug with a test to avoid regressions and to check that the fix works.
We have an IRC channel, our django-cms-developers email list, and of course the code reviews mechanism on GitHub - do use them.
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 simple, unfussy English. Elegance of style is a secondary consideration, and your prose can be improved later if necessary.
Documentation should be:
Merging documentation is pretty fast and painless.
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.
Except for the tiniest of change, we recommend that you test them before submitting. Follow the same steps above to fork and clone the project locally. Next, create a virtualenv so you can install the documentation tools:
virtualenv djcms-docs-env
source djcms-docs-env/bin/activate
pip install sphinx sphinx_rtd_theme
Now you can cd into the django-cms/docs directory and build the documentation:
make html
open build/html/index.html
This allows you to review your changes in your local browser. After each change, be sure to rebuild the docs using make html. If everything looks good, then it’s time to push your changes to Github and open a pull request.
Our documentation is divided into the following main sections:
We use Python documentation conventions for section marking:
There should be one consistent way of rendering any technical word, depending on its context. Please follow these rules:
Use absolute links to other documentation pages - :doc:`/how_to/toolbar` - rather than relative links - :doc:`/../toolbar`. This makes it easier to run search-and-replaces when items are moved in the structure.
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.
Top translations django-cms core:
We are using SASS/Compass for our styles. The files are located within cms/static/cms/sass and can be compiled using the compass command compass watch cms/static/cms/ from within the django-cms root.
This will invoke the config.rb within cms/static/cms/ using the predefined settings.