The revision process
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 in relation to the aims and principles of the project as a whole.
The particular stages that a new feature goes through vary, but a typical cycle for a significant change might include:
- 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.
- Superceded 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.