Community

Process for getting changes deployed on Drupal.org

Last updated January 17, 2013.

This page describe the process whereby you can take an idea you have to improve Drupal.org and actually see the change deployed on Drupal.org. If on any step in the process you need some guidance, find tvn in IRC (or, failing that, use contact form).

    Propose the change

  1. Post your idea in Drupal.org group and get some initial feedback from the community.
  2. Once an idea is clearly formulated - open an issue in the appropriate issue queue. If you know it's related to a contributed module that runs on Drupal.org you can submit the issue directly to that module's queue. If you're unsure, start with the webmasters queue and it can always be reclassified as needed.
  3. Discuss with others in the community and see if there's support for your idea. Try and rally a few folks to pitch in with patches.
  4. If it looks like there's strong support, get sign-off on the idea from the appropriate infrastructure lead for whichever website(s) you're working on. Note that killes should be contacted (via IRC or, failing that, contact form) on any main Drupal.org site changes, so that performance impact can be assessed, and other key infra members pulled in if required). Make sure to get sign-off before proceeding to the next step.
  5. Code and Test the change

  6. Either apply for a drupal.org development site or find someone that already has one that's appropriate for your change, and get the change deployed on the dev site for wider testing and review. Update the issue (and g.d.o posts) about the fact the change is available for public testing.
  7. If your idea requires new code, not just a simple configuration change, either write the code yourself, find someone else to write it, or hire someone to do so.
  8. Ensure the code meets all of the Drupal.org development guidelines.
  9. Ensure text content meets Drupal.org style guidelines.
  10. Post deployment instructions including patches, module updates additions with specific version numbers, and configuration settings to the issue. Iterate with the project maintainer(s) and/or Drupal.org maintainer(s) to ensure the changes meet all the criteria.
  11. Request a review

  12. Open an issue in the Infrastructure issue queue that points to the issue where the change has been implemented, point to the dev site, and request a final review of the changes.
  13. Ensure that the change has been committed "upstream" to the appropriate contributed module and tagged needs drupal.org deployment.
  14. Update the infrastructure issue saying your change is committed and ready to deploy.
  15. First you changes will be deployed on the staging site for final integration and public testing. You will be notified in your issue once changes are on the staging site and ready for testing.
  16. Test your changes on the staging site and report any problems found in the issue, or confirm there are none.
  17. This is the point when you will get your change scheduled for one of the weekly Drupal.org deployments (currently Thursdays at 01:00pm PDT). Depending on the size and scope of the change, the Infrastructure Team might decide that Drupal.org downtime needs to be scheduled.
  18. Support the change

  19. (Optional) Make yourself available in IRC to answer questions during the actual deployment day in case the person from the Infrastructure Team deploying your change has any final ones.
  20. Update any documentation that becomes invalidated by your change or add new documentation if necessary to explain the change.
  21. Be available after the change goes live to watch for any problems that arise and help the Infrastructure Team resolve them.
  22. Depending on the size and scope of your change, announce the change publicly. This could be:
  23. Remove the "needs drupal.org deployment" tag from the issue, and mark it "fixed" (if it isn't already)
  24. Rejoice!