Last updated April 10, 2010. Created by NonProfit on August 22, 2004.
Edited by figaro, catch, webchick, puregin. Log in to edit this page.
Changes to the Drupal core are usually made after consideration, planning, and consultation. They are also made on a priority basis: fixes come before additions, and changes for which there is a high demand come before proposals that have gone relatively unnoticed. Any potential change has to be considered not only on its own merits but also in relation to the Drupal project aims.
The particular stages that a new feature goes through vary, but typical stages are as follows:
- General discussion of the idea, for example through a posting in a drupal.org forum. This can be a chance to gauge support and interest, scope the issue, and get some direction and suggestions on approaches to take. If you're considering substantive changes, starting out at the discussion level, rather than jumping straight into code changes, can save you a lot of time.
- Posting an issue through the drupal.org project system.
- Discussion raising issues on the proposed direction or solution, which may include a real-time meeting through IRC.
Individual Drupal community members may vote for (+1) or against (-1) the change. While informal, this voting system can help quantify support. - Producing a patch with specific proposed code changes.
- Review of the changes and further discussion.
- Revisions to address issues.
- Possible application of the patch.
The process of discussion and revision might be repeated several times to encompass diverse input. At any point in the process, the proposal might be:
- Shelved as impractical or inappropriate.
- Put off until other logically prior decisions are made.
- Rolled into another related initiative.
- Superseded by another change.
If you submit suggestions that don't end up being adopted, please don't be discouraged! It doesn't mean that your ideas weren't good, just that they didn't end up finding a place. The discussion itself may have beneficial outcomes. It's all part of collaboratively building a quality open source project.
Comments
After reading this excerpt,
After reading this excerpt, it is no clear yet criteria to transit an Drupal core's issue from state "needs review" to state "reviewed and tested by the community".
More specifically, who is in charge to assert such a transition?
You are
Every person decides for herself when she's qualified to set the RTBC status. When you set this status, you are asking the maintainer(s) to commit the patch, and staking a tiny piece of your reputation on the claim that it's ready and that any problems raised in the issue have been addressed. It's normal for contributors to sometimes disagree, and someone may change the status back - so don't worry too much if that happens.