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:
- Tag your issue as needs drupal.org deployment.
- 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!
Comments
great post; way to go...
great post; way to go...
The image filter is super
The image filter is super helpful, but left some old posts looking broken.
I made a list of these at http://drupal.org/node/1298020 - for folks who can edit old content it would be great to get your help.
--
Morris Animal Foundation
Great Post
I learned a lot from it. I think this is a complete article to be placed in Documentation pages.
About image filter
look at this http://drupal.org/project/imagefield_tagfilter - it's my module for work with fields.
It allows add image fields into nodes via special tag.
And I'm going work on this project in future too cause I use it myself on my site and blog.
I'd love to! I even developed
I'd love to! I even developed my own module, unfortunately, it takes ages to get it approved! :-(
--
Petiar
http://petiar.sk
You don't need the ability to
You don't need the ability to create full projects to contribute to drupal.org.
Only at the end of step 4 is a release of a module necessary (assuming your change is a module, if it's just a patch to drupal.org module then you still don't need to create a module).
It's definitely unfortunate that the approval process takes a long time. I'll take a look at your application now.
Note that some of the work done recently to improve drupal.org was to make the approval process faster.
--
Morris Animal Foundation
Hey Greggles, you are
Hey Greggles,
you are absolutely right and I thank you for your time spent on my issue. Just FYI - I submitted a patch today (a lame one as I am not very familiar with git but I am going through the documentation right now).
Take care, thanks!
--
Petiar
http://petiar.sk
Approval Process
The approval process of complete modules is still not such fast. I know some developers that only make Sandbox projects because they say that approving full projects, need more time and every one prefers to see his project on site after some days. I hope this process speeds up day and day to have much more full projects on Drupal.
Issue summaries
in addition to the above improvement,
for 1 to 5 recent comments, color them red
so that we can find the recent comments/replies easily.
since we can reply to a comment,
the recent replies can not be found at the bottom,
you have to scan from top to bottom.
issues have NO response
Drupal org is not visually appealing as Acquia or Drupalgardens or drupal com
Yes, I concur. I'd like to be
Yes, I concur.
I'd like to be apart of the process of helping make that happen.
So, er, I recommend *reading* the post :)
It outlines exactly how to get your frustrations with drupal.org fixed.
@webchick: Given some of the
@webchick: Given some of the issues described in the post took years, I and probably most users here do not have those resources to commit. Open source, sure... community, sure but at the end of the day I can't eat them. :) I would say that larger organizations should be approached to pay someone for bigger tasks or provide bounties, or organize fundraisings for the tasks, just like they do for drupalcons, or arrange some kind of fund alloted just for drupal.org developments. Where are the elephants Dries mentioned here http://buytaert.net/capgemini-promoting-and-using-drupal? Why dont they step up? Has the Drupal Association thought of approaching these elephants for supporting improvements on drupal.org? They could support such tasks since they have the firepower.
If large organizations could be convinced to publicly support a drupal feature with a bounty, I am sure developers would be trampling on each other to finsh first. :)
My Drupal sites:
It's easy to say "someone
It's easy to say "someone else can do this easier than I can" but if you look at the three issues webchick mentions they were worked on by people who work as freelancers or for relatively small shops or for big companies but they worked on it on their own.
It's certainly possible that "large shops should do more" and I would argue that they should do more proportionately to their size. However change is often easier at smaller shops where you have less bureaucracy. In the end, we are all responsible and must all take on the responsibility.
I would also quibble with your claim that they were all year-long efforts. From my reading the three examples efforts are as old as a year or so and as young as a few months of sustained effort.
--
Morris Animal Foundation