Drupal 7 Code Sprint on December 7th, 2013 (D7onD7)
Drupal 7 Code Sprint on December 7th, 2013 (D7onD7)
With the community pushing to get Drupal 8 finished, and with building pressure for module maintainers to begin porting their modules to D8, not as much attention is being given to the large numbers of Drupal 7 modules and D7-only core issues that need TLC – Tender Loving Contributions.
Lets do something about this.
I’m calling on the community to make the upcoming December 7th a day when we work together to improve Drupal 7 core and the many Drupal 7 contrib modules & themes – a code sprint just for Drupal 7, aka “D7onD7.” On December 7th log onto drupal.org, find your favorite Drupal 7 module and look through its issue queue – if there are “needs review” issues then review them, and if there are “needs work” issues then roll up your sleeves and do the work! I think we cal all agree that there are always more bugs than we have time to deal with, so lets work on some of this technical debt. If enough people work together on this we can get a huge number of possibly long-standing issues resolved and help solidify our favorite CMS.
Why not Drupal 8?
With so much emphasis on Drupal 8, why focus on Drupal 7? The simple reason is that most of us rely upon Drupal 7 for our livelihood and won’t be using D8 for production work (excluding miniscule testbed sites) for some time. Until then it’s in everyone’s best interest to make sure we have a stable foundation to work from, that the tools we use day-to-day are reliable.
Another reason to focus on Drupal 7 contrib modules is that it will give people an opportunity to see if they could contribute more to their favorite module(s) and become co-maintainers. Several leading module developers have announced that they are looking for people to help maintain / lead their Drupal 6 & 7 projects as they're focusing on Drupal 8 core or other things. Notable contributors looking for help including Earl “mearlinofchaos” Miles who wrote CTools, Views, Panels, etc, and Kristof “swentel” De Jaeger who wrote Display Suite, Entity Cache Flusher and several others, and as the Drupal 8 march continues I expect many others to do likewise. So lets see what we can do to find additional long-term help for these and the many other modules that are in need of TLC.
Finally, doing a Drupal 7-focused code sprint on December 7th gives us the chance to use the "D7onD7" moniker, so why not!
Gather around the fire
As with all other community ventures, we’ll be hanging out in IRC for the day. If you can’t find something to work on just pop into the #D7onD7 channel (or the main #drupal channel) and we’ll help you find something. Remember that you don’t have to eat, sleep and dream in PHP in order to help, everyone can help with something, be it issue queue triage, UX review, documentation writing, front-end design, etc.
User groups loves code sprints
Attendees had so much fun at the recent DrupalCamp NH 2013’s code sprint that we are making this code sprint an official event for the state’s Drupal group. Through the NH GDO group we are organizing locations around the state where people can come to help with the code sprint and hang out with other Drupal users of all skill levels.
If you’re involved in a regional Drupal user group perhaps you could try organizing a local sprint on December 7th too? All that’s needed is internet access and something to sit on, it doesn’t have to be anything grandiose. People new to running code sprints might benefit from listening to the recent Modules Unraveled podcast with Cathy Theys where they discuss code sprints at length; additionally there is a great deal of information available in the Code sprints page on Drupal.org, and a GDO group specially for organizing sprints with lots of discussions on how to plan a sprint.
What to do?
As mentioned above, anyone who has worked with Drupal can attest to the fact that there's always something to work on, always some bug that needs fixing, a feature request to work on, or documentation to improve. I recommend we focus on reviewing issues that are in an "in review" state or, time & expertise allowing, looking at some "needs work" issues, and that we also favor bug reports rather than feature requests as it is the bugs that cause us the most grief. Specific issue queues to consider are:
- Drupal core: "Needs review", "Needs work"
- Metatag: "Needs review", "Needs work"
- CTools: "Needs review", "Needs work"
- Panelizer: "Needs review", "Needs work"
- Panels: "Needs review", "Needs work"
- Views: "Needs review", "Needs work"
- Media: "Needs review", "Needs work"
You can see what some of my favorite modules are..
Honestly, though, reviewing and getting any issues from either a Needs Work or Needs Review state to "Reviewed and tested by the community", aka RTBC, would be a tremendous help.
Towards Metatag v1.0
On a more personal level, I’m intending to use the time to push towards getting Metatag v1.0 out before the end of this year. Given that Drupal 7 is going to be three years old soon, we’re way past due for a stable release for one of Drupal’s most important SEO modules — so lets finish it! Right now we’ve got a critical blocker with the new support for entity revisions that needs help with testing, and once we get past that there’s a pretty clear path towards v1.0.
I hope to see lots of you online!