This post was collaboratively authored with other Drupal core committers including quietone, pameeela, catch, effulgentsia, larowlan, lauriii, and Dries.
Drupal core
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 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.
We did something awesome at DrupalCon Denver: on code sprint Friday, we filled a room with between 75 and 100 new Drupal core contributors and helped them work on core issues for the first time.
Participants learned everything from the mechanics of triaging issues to how to write automated tests. Six of us (myself, Andrea Soper, Tim Plunkett, Lin Clark, Cameron Eagans, andKelly Bell) introduced and led the sprint, and several other experienced contributors (including David Rothstein, Kieran Lal, and Cathy Theys) stepped up to help mentor during the course of the sprint. Angie Byron even demonstrated for participants how she reviews and commits core patches, and committed one participant's first core patch in real time on the big screen.
It was delightful to watch the participants' enthusiasm and collaboration. The morning was hectic, but as the day went on, the sprint leads answered fewer and fewer questions because the sprint participants helped each other.
