Drupal Planet

This post was collaboratively authored with other Drupal core committers including quietone, pameeela, catch, effulgentsia, larowlan, lauriii, and Dries.

My role on the committer team is that of a release manager. We're the folks who actually create the Drupal core releases that you can install on your site.

Back in 2013, I led the core contribution mentoring day at DrupalCon Sydney. I'd already flown from the US to Europe three times at that point (first for Drupal Developer Days Barcelona, then for DrupalCon Munich and the Paris VDC sprint, and finally for a whirlwind 72 hours in London to sprint on VDC and CMI). None of that prior international travel prepared me in the slightest for the over 24 hours of nonstop air travel/physical torture that it takes to get from Wisconsin to Australia. 

Florida Drupalcamp 2017 is less than a week away, February 17-19, in vibrant Orlando. Not only is the camp schedule packed with great sessions and trainings, but there's also a contribution sprint that both helps Drupal 8 core maintainers, and gives you a chance to contribute and learn about Drupal 8.

To join the sprint, you should already be familiar with Drupal... and that's it! You don't need to be an expert. You don't need to be a coder. You don't even need to know much about Drupal 8, although a little knowledge helps. This particular sprint is a great fit for:

On April 20, five months after the launch of Drupal 8.0.0, we released Drupal 8.1.0, the first scheduled minor update. Drupal 8.1.0 comes with both new features and bug fixes that were not eligible for monthly patch releases. Now is a great time to try Drupal 8 if you haven't yet!

Drupal 8.1.0 is production-ready, but (like most software) still has known bugs that can cause issues for some modules or sites. Although we fixed hundreds of critical bugs during Drupal 8's development, and although only a handful of critical issues have been discovered since Drupal 8.0.0, there are still hundreds of less severe bug reports marked with "major" priority.

Drupal 8 developers, as a whole, are a bit gushy about PhpStorm. I use it; it's useful. But a decade and a half of my programmer muscle memory is Emacs keybindings, so when I use a different tool than Emacs, I feel like I'm trying to cut vegetables with a mallet, or write with a wad of chewed gum. And yes, PhpStorm ships with an Emacs keymap, but it's just not the same. It's not only a matter of the PhpStorm Emacs keymap being less cared for than its Vim cousin. It's that PhpStorm does not support M-x butterfly.

The DrupalCon Los Angeles extended sprints start this Saturday, May 9, and the main sprint day on Friday, May 15 is just a little over a week away. I'll be leading a Drupal 8 Critical Burndown sprint to help get D8 done, and kgoel and cilefen will be leading a sprint to triage Drupal 8 majors. And we need your help! Sign up for the sprints now, or read on for more information on what we'll be doing and why.

The most recent issue of Drupal Watchdog includes an article on software freedom and social change in Drupal. While this article raises a number of thoughtful questions about the social implications of the Drupal community's evolution, it includes some misinformation (both because it misrepresents the data that are easily available and because it lacks data that are not easily available). In the first part of this post, I look at the specific information presented in the article and provide some more depth, including some first-hand information about Acquia, since I work in Acquia's Office of the CTO. In the second part, I explore how we can mitigate some of the concerns the article raises.

Working on any software project can be frustrating. You inevitably encounter things that are confusing, buggy, poorly documented, over-architected, under-architected, and so on. In an open source project, this frustration is compounded when uncertain resources and volunteer contributions lead to inconsistent quality or completeness. Working on the development version of the software adds additional challenges, as you have to learn new systems and development paradigms that may not yet be very refined.

Think twice, though, before publicly venting your frustrations about how awful that current pebble in your shoe is. In a project like Drupal, chances are, someone you're talking to worked really hard on some component of the thing that's frustrating you. They probably donated their time. They did the best they could with the resources they had.

Negativity is contagious. Even if you have good intentions, and the person you're talking to has good intentions, disparaging remarks will quickly take your discussion off track and make both of you less interested in solving the actual problem.

If you disagree with something in Drupal, first, take a deep breath, and remember that the thing frustrating you is the work of real people. Then, take the time to file an issue that neutrally states the change you suggest and the reasons for it. Be constructive. Bonus if you provide a patch to get the issue started. The same feedback that started an argument when you threw in a couple hyperbolic adjectives may be received with enthusiasm if you phrase it professionally.

Be nice. Sometimes it's hard, but it's worth it.