The Spark distribution is a Drupal 7 distribution which aims to prototype cutting-edge authoring experience improvements that we hope to propose for inclusion in Drupal 8 core, announced back in May. Please download the latest release and check it out, and give us lots of feedback! (And/or patches! ;))
Greetings, Drupal Planet!
Here are the slides from my DrupalCamp Vancouver "hook_future_alter()" talk. This outlines the major changes currently in development for Drupal 8, how Drupal 8 will impact end users, site builders, designers, and developers, and how to jump in and help!
I'm crack-addicted to the iPhone/iPad game No Zombies Allowed, and for whatever reason can't find anything about it anywhere on the Internet.
Back in September, http://drupalcontribstatus.com/ was launched to track the porting status of the top 60 contributed projects to Drupal 7. Since then, we've whittled the list down to just 20 projects remaining, as well as tons of progress on the rest! YEAH!
I contacted each of the maintainer(s) of those remaining projects and have come up with a list of next steps for each. Your help is needed if we want to get that graph up to 100% by year's end. (Just in time for Drupal 7's first birthday! :))
As a general rule, help is needed in the following areas:
- Issue queue triage (Difficulty: Novice): Going through the issue queues of these modules and doing things like closing duplicate reports, verifying that bug reports are valid, and so on. None of this is particularly difficult work, but time that maintainers have to spend doing it is time they can NOT spend porting their modules to Drupal 7.
- Reviewing patches (Difficulty: Intermediate): Going through the issues in the queue marked "needs review" and making sure patches still apply, then testing to make sure that they still work, then reporting on the results of your testing are all critical things that really help save maintainers time, and ensure that any actionable issues are escalated to their attention.
- Experience in various core sub-systems (Difficulty: Intermediate to Advanced): If you know how to write automated tests, are familiar with how the render API works, can answer questions about the new Field API or File API, there are several issues identified that could use YOUR help! Note that you don't necessarily need to be in MAINTAINERS.txt to provide this help, either; if you've already started building Drupal 7 sites and modules, you likely know enough to be helpful!
- Co-maintainership (Difficulty: Intermediate) Many of these projects are seeking co-maintainers. If you or your business/customers depend on any of these modules, investing solid time in the issue queue to help review and roll patches for issues in need would be of tremendous benefit, and would help position yourself to ask for commit rights so that you can ensure these modules stay solid going forward.
So, without further ado, here are some specifics on how you can help Drupal 7, and the maintainers whose code you rely on!
Here are some notes from the Drupal 8 status update talk that Dries and I gave today to the Acquia team, since this seemed like useful info for the community to know as well. :) It covers both process changes for addressing previous issues that arose in Drupal 7, as well as a status update on Drupal 8 progress to-date. This could be useful to folks who have been wondering where all of the various Drupal 8 status updates fit into the "bigger" picture.
Please comment here if I left anything out, or messed up anything.
One of the things the Drupal Association struggles a lot with is the pricing of DrupalCon tickets for attendees. As detailed in the 2011 Annual Report (1.3 MB PDF), DrupalCon tickets make up a significant portion of the organizations' overall revenue, which goes to funding hugely important long-term projects like the Drupal.org redesign and Git migration, server upgrades, programs like the Community Cultivation Grants, as well as salaries for our staff to help run operations. While we are actively working on diversifying our revenue stream through initiatives like a revamped Drupal Marketplace and hosting listings, and adding numerous benefits to our membership program, the fact remains that in the meantime, DrupalCon ticket sales help to off-set significant costs for programs that help benefit the wider Drupal community, including those individuals who could never hope to attend a DrupalCon due to family/geographical/visa issues.
At the same time, we also recognize the wonderful diversity of people in our community. And for students, hobbyists, non-profits, evaluators, freelancers, and others, even the significantly off-set ticket prices (thanks to our generous DrupalCon sponsors) can make DrupalCon attendance prohibitive to the people we hope most can get there. And while we offer full-ride scholarships for a limited number of people in financial need, asking for one is often uncomfortable, especially by people who give a lot to Drupal already. In the past, we've done super-cheap "land grab" tickets (first 100 or so), but often those go to the people who don't need them: the major Drupal shops and others making ample money off Drupal who already know they'll be coming to DrupalCon, regardless of ticket cost.
This time around, we're doing something a little different. The Drupal Association has set aside a number of half-price tickets to students and non-profits, as well as FREE tickets to contributors. To snag one, you have to apply to lead a sprint on the final sprint day. These applications will get checked over by the same group who looks over the scholarship applications, and use similar criteria (involvement in community of the participant, impact of the sprint on larger project, etc.) to evaluate the submissions.
So, if you're someone who is driving important change in Drupal (or someone wants to!), please tell us about your plans and you could qualify for complimentary admission!
At the end of June I wrote up a list of things I'd been working on as part of Acquia's Office of the CTO. Here's another update for this quarter!
Last quarter was focused primarily on stabilization of Drupal core and incorporation of various processes to help ensure it stays stable. With that in hand, this quarter my focus shifted more towards accelerating Drupal 7 adoption.
I did a fresh installation of Drupal 8 this morning and came across a bit of ugliness: an ugly grey border on the home page, caused by an empty div being inserted into the page:
My last fresh install of Drupal 8 was about a week ago and didn't have this problem. I didn't relish the idea of going through all of the commits since then one-by-one to figure out where this bug was introduced.
Enter the git bisect command! The
git bisect command works by performing a "binary" search between one state of the code and the other in order to find, by process of elimination, where a given problem was introduced. It's quick, it's easy, and by golly it just works!
Here's how to use
git bisect, step-by-step!
Ever use Drupal or Drupal.org and come across some kind of minor, annoying issue... say a typo, or a code comment that could stand to be improved, or some other change that's only a couple of lines of code... and you think to yourself, "Self, this would take you about 5 minutes to fix, but your to-do list is 43.4 km long. Pass."
Well, the next time that happens, please pause for a moment, and file an issue for that minor problem, and tag it as "Novice".
Thanks to the efforts of brand-new contributor demarcoz, we rolled out a new Drupal.org improvement this week: a link to the queue of all Novice issues on the Dashboard! (which was itself a Novice issue: http://drupal.org/node/1266380 :))
The goal of the "Novice" tag is to help identify "low-hanging fruit" issues. This way, people who haven't been using Git and rolling patches since they were in diapers can have something bite-sized to chew on while they work their way up the learning curve of setting up a development environment, figuring out quirky git commands, and finding their way around Drupal coding standards and API peculiarities. This is a much nicer introduction to contributing than showing them an issue queue with 50,000 issues in it and saying "There ya go! Pick one that sounds interesting!" :)
And while it might take a new contributor a few days to solve something you could solve in a few minutes:
a) It's really fun to walk new people through this process and see what sorts of things trip new people up.
b) They're now equipped to tackle even harder issues in the queue, and they can eventually help you with your own 43.4 km long todo list.
c) They can also help improve documentation in places where they got stuck, and even help mentor other novices!
So the next time you find a small issue you could solve yourself in a few minutes, please don't! Instead, tag it as "Novice" and help to usher in a new crop of eager new contributors. :)