Drupal.org is our home. It's where we solve tough problems, it's where we innovate on creative solutions, and it's where we meet and interact with others in our community. It only makes sense then that our community should be able to actively participate in making improvements happen on Drupal.org, but the process to do so has traditionally been seen as a bit confusing and opaque.

This post attempts to outline the process of making changes to Drupal.org, and highlight some recent successes we've had putting this process into practice. This information is compiled from the Make Drupal.org awesome guide!

Step 1: Think it up

Have a great new idea for improving Drupal.org? Great! Search first, to see if someone else has already had your amazing idea and maybe started work on it. If not, begin by creating an issue in the webmasters issue queue to discuss, unless you happen to know the appropriate issue queue for it.

Prefer to collaborate on some ongoing efforts that other passionate people are working on? Check out the Drupal.org improvements community initiatives page, and its various sub-pages, to join up with others on their big ideas. :)

Step 2: Talk it out

(Note that if you're participating in an existing issue that the Drupal.org maintainers have already signed off on, you can skip this step!)

At this stage, what you want to do is gather feedback from the rest of the community about your idea. Since Drupal.org is a shared resource, it's important that there be buy-in for any given change from multiple people, particularly given the performance challenges of Drupal.org (1,000 people logged in at any given time hitting refresh repeatedly on "My issues"... egad!).

Start by asking for some initial, informal feedback from folks in IRC, Twitter, or a local Drupal user meetup. If that goes well, consider cross-posting your issue to Planet Drupal or potentially interested groups on http://groups.drupal.org to get wider exposure for your idea and broader discussion (but please don't be obnoxious about it :P).

If it looks like the community thinks your idea is a good idea, the final step is to run it past the appropriate members of the Drupal.org infrastructure team.

The Drupal.org infrastructure team "org chart" (click for big version)

Run the idea past the person who's "in charge" of that particular area. For example, if your idea was to make improvements to the themes listing on Drupal.org, you'd want to talk with one of the folks in the "Issue tracker and downloads" section (dww or mikey_p) about that. If it's a larger-scale change with major new functionality, the Drupal.org infrastructure manager (killes) should also be pinged.

Got sign-off from the infrastructure maintainer(s)? Perfect! Now you're ready to...

Step 3: Code it up

There are two ways to develop improvements against Drupal.org:

Get a drupal.org development sandbox (preferred)

Drupal.org sandboxes are hosted on a domain like http://issue-summaries-drupal.redesign.devdrupal.org/ and contain a sanitized/trimmed copy of a real Drupal.org database. These work really well for allowing others to test your changes in a "real" environment.

Develop locally with Drupal.org testing profile

Ideal for smaller tweaks, or self-contained features that doesn't require "real" Drupal.org data. The Drupal.org testing installation profile will hook you up with an installation of Drupal with all of the various modules that Drupal.org uses, plus some basic configuration. It's definitely not perfect, but good enough for a lot of smaller things.

Now. Remember all of those people who supported your idea back in step 2? Tell 'em to turn out and help with development, UI feedback, and reviewing. :D

It's really helpful to have a single "meta" issue tracking any sub-tasks, as well as an up-to-date issue summary at the top of that issue, outlining the remaining tasks before your initiative is ready to be deployed. This helps new people coming in to know where to be the most effective.

Before moving onto the next step, it's a good idea to make sure that any dependent patches have been committed upstream (if at all possible), and a clear list of deployment tasks (e.g. new modules to be added, what settings to change, etc.) are added to the issue summary. This will make deployment as easy as possible.

Step 4: Get 'er done

Once the change gets to "reviewed & tested by the community," it's time to prepare for deployment:

1. Tag your issue as needs drupal.org deployment.
2. Post an issue to the infrastructure issue queue which points to the issue where the change has been implemented, point to the deployment steps, the dev site, and request a final review of the changes.

If it's a big enough change, its deployment might need to be scheduled if it will incur any drupal.org downtime. You should be a good Drupal citizen and make yourself available to the infrastructure team if they have any questions during deployment in #drupal-infrastructure on IRC.

Assuming your change passes a final review from the infrastructure team on things like performance and maintenance considerations, your brilliant idea should now be up singing and dancing in front of everyone on Drupal.org. WOOHOO!!

Sounds good, but does it actually work?

In a word, absolutely! Here is a list of recent improvements that have been pushed out through this process:

Better system for tracking API changes

During Drupal 7's release cycle (and before), making an API change to Drupal core involved editing this gigantic page of horror and tears. It was cumbersome, and therefore it was very difficult to get developers to do this, and there are probably still API changes today, ten months after Drupal 7's release, which are not tracked here. :(

Jennifer "jhodgdon" Hodgdon spear-headed the initiative to turn these API changes into nodes, with a view that can filter by version, who it affects, and so on. It can also track whether or not Coder Upgrade rules were written, whether or not relevant documentation was updated, etc. for each change. YAY!

Issue summaries

A huge barrier to entry to core development and other places where large sections of the community have a lot of things to say about things is long, sprawling, complicated discussions. Take a typical critical bug report in Drupal 7 like #228818: IE: Stylesheets ignored after 31 link/style tags and watch it grow from 20 to 50 to 100 to 400 comments over time. Coming in fresh to these types of issues is almost impossible; it can require hours' worth of reading, and entire code sprints intended to focus on fixing critical issues have been taken up doing just that. :(

This issue resulted in making issue bodies themselves editable, so that in these types of complex issues all a new person (or a busy core maintainer) has to do is read the first post and then be caught up with major happenings. All issues on Drupal.org now have an "Edit" tab, which refers to an issue summary template to highlight what's going on in this issue, what the proposed solution is, and what remains to be done about it. This has collectively shaved hundreds of hours off of collaboration on tricky issues already, and has even started an "Issue summary initiative" led by xjm to specifically seek out these complex issues and write up summaries for them. A great way to dive in for people new to core development!

Images for all on Drupal.org

The ability to post inline images on Drupal.org has been traditionally locked down to only privileged users (the "documentation team" role or higher) in order to prevent possible Cross-site request forgery attacks, and also to prevent mixed content errors when Drupal.org moves to HTTPS. While great from a security POV, this is absolutely terrible from a collaboration POV. :\ Designers, usability folks, bug reporters, casual documentation editors, and others are prevented from participating unless they ask for and receive elevated permissions on the site.

sun and chx worked together on a new general-use module called Local image input filter to meet Drupal.org's needs. It restricts <img> tags to the local site only, and also verifies that what's being linked to is actually an image. No chance of linking to something nefarious on evilh4x0r.com, and no chance of mixed content errors either since all URLs are re-written as relative. NICE! So not only was a useful problem solved for Drupal.org, but others who need the same capability can take advantage of it as well.

The key thing about these patches? They were all developed by people not in the infrastructure team org chart! Just regular ol' Drupal contributors like you and me. :)

So, let's make Drupal.org awesome!

Come along and join us!