CMS New Feature Life-cycle Management Policy
From Joomla! Documentation
This document outlines a process for managing the incorporation of new features into the Joomla CMS. It should be noted that following this process is not compulsory, however a new feature will be more likely to be accepted and incorporated into Joomla if this process is followed.
Idea[edit]
All new features begin with an idea. It might come from a personal itch you feel the need to scratch or it could be something that many people in the community have requested. Where the idea comes from doesn’t matter, the important first step is to write it down and begin the process of thinking it through. Is the idea feasible? Is the idea appropriate for the core Joomla product or would it make more sense as an installable extension? Ask yourself (and others) these questions and if you still think it’s a good idea, proceed to the next step.
Request for Comments[edit]
To stand a good chance of acceptance your idea will need to pass some degree of peer review. The best way to garner such a review is to write an RFC (Request for Comments) (example) in which you describe your feature idea in as much detail as you can and explain why you think it should be included in the Joomla CMS.
Be prepared to defend your RFC, as most will likely attract criticism as well as praise. Respond to feedback and be willing to amend the RFC if the feedback makes sense to you. It is important to remain respectful at all times, even if your idea is being criticised. It’s easy to become emotionally attached to an idea and become overly defensive about its merits, when it might be better to accept criticism and see it as a way of improving your proposal. Of course, this tends to become a lot more obvious with the benefit of hindsight.
If you can recruit others to help you work on your feature then welcome them to the party. Most features will require the combined efforts of many people in order to reach the holy grail of being merged into the core codebase.
To stand the best chance of being included, your feature RFC needs to be adopted by a Release Team. At any given time there will be three Release Teams: one looking after the current release (x.y); one looking after the following release (x.y+1); and one that will be starting to pull together ideas for the release after that (x.y+2). It is this latter team that is the one most likely to adopt your RFC because it is that team that will be actively looking for new feature proposals that it can shepherd into the codebase.
The Release Team will be looking at the roadmap for planned features, reviewing community feedback for other desired features and seeking community member interest in development and testing of features. A strong RFC with good community support will go a long way to attracting their attention and gaining their support. If the Release Team chooses your feature for their release then you are on your way! But of course, that’s when the hard work really starts.
Production Working Group[edit]
If your RFC is adopted by a Release Team then they will almost certainly encourage you to form a Production Working Group (PWG) in order to develop the feature. All current PWGs are listed on the documentation wiki[1] and there you will also find the procedure for forming a new PWG. You don’t have to form a PWG, but if you do then it will help with recruiting community members to help you and it provides a template which will help everyone to communicate and manage progress towards your goal of having the feature accepted into the codebase.
With approval to form a PWG you will be able to publish your team details on the documentation wiki and you will get a page on the Volunteers Portal. The Release Leader will expect regular progress reports (usually monthly), which you can easily publish on the Volunteers Portal and the wiki.
Code Sprints[edit]
Code Sprints are a great way to get an extra push towards the finish line. Bringing together a group of 6 to 10 talented individuals for a couple of days to focus intensively on a feature is a powerful way of making progress. Consider bringing documentors as well as coders into the mix as full documentation is also a requirement for acceptance of new features.
But Code Sprints take time and effort to organise and there is usually a cost involved, if only for the pizza! Usually there will be travel and accommodation expenses to consider too. The PLT has a budget for funding Code Sprints so if you think that your feature would benefit from one and you are prepared to take on some of the responsibility for organising it, then make your proposal to the PLT (your Release Leader will be able to help you). The PLT will consider it carefully, but don’t be disappointed if the answer is no; funds are limited after all.
Acceptance[edit]
To be accepted and merged into the core CMS codebase your feature will need to meet some minimum requirements that are designed to maintain quality. After all, your code could be running on millions of websites worldwide and the Joomla project has a responsibility to try to ensure the highest standards possible for all our users.
Although the PLT has ultimate responsibility for merging new features into the codebase, in practice the decision to merge is devolved to the CMS Release Team Leader for the release concerned.
Code style[edit]
A basic requirement is that all code should conform to our code style standards. You can read them in detail [here] and you can run automated tests for most of them using phpcs [instructions here].
Unit tests[edit]
All new code added to the CMS must pass all current unit tests (unless, of course, there is a good reason for the test itself to need changing). Unit tests can be run locally (Running Automated Tests for the Joomla CMS) but they are also run automatically using Travis [need link] which is triggered automatically whenever a pull request is submitted.
Nowadays we require all code submitted to the core to be accompanied by unit tests. For writing unit test we have set up guidelines you should follow
System tests[edit]
System tests are a bit thin on the ground and this is an area where we are looking to strengthen in future.
Documentation[edit]
All new features must be accompanied by comprehensive documentation appropriate for the nature of the new feature. This includes both developer and user documentation. If you cannot write the documentation yourself then you will need to put a call out for assistance. You should find plenty of people willing to help.