Drupal Community Governance, Transparency, and Sustainability

I applaud the Drupal community for its quick and overwhelming response to another instance of intolerance in our community. “Treat each other with dignity and respect” is one of our core values & principles, and upholding those values is the work of the whole community.

While we’ve achieved short-term success in the departure of a board member who does not share our values, I encourage us to continue understanding how such a person got there in the first place. Based on conversations in Drupal Slack, the DA Committees page is out of date and the minutes for the offending member’s nomination are vague. What logic led to this appointment in the first place?

Community members have flagged concerning social media posts from before his nomination to the Drupal Association board, but how deep into candidates’ public personas is reasonable for nominators to go? We need transparency to understand how DA Board members are vetted by the Nominating Committee. How are business goals and personal values weighed in the nominating process?

Issues have also been brought up by prior board members expressing frustration with the committee’s slate-based nomination process. If individuals on a slate are in question, we need to ensure that all Board members (appointed and community alike) are both able and empowered to raise those questions. What recourse do board members have to question a single member of the nominated slate?

In over 15+ years in the community, I’ve seen this process unfold time and again. Business development, infrastructure improvements, and “Drupal drama” all take time and effort to manage. The Drupal Association is small and scrappy and moves mountains to keep Drupal going, but it often seems to be strained in trying to be “everything for everyone”. How can we create a governance and funding model that “helps Drupal flourish” (the current work of the Board), “keeps Drupal alive” (the current work of the DA staff), and does it all sustainably?

Finally, hate and intolerance still plague our community. Let’s keep the momentum from this quick community action, build on it with the questions above, and continue to put pressure on our other leaders who refuse to stop hosting hate.

Composer alias vs composer replace for downgrading/removing drush

I was wrestling with composer yesterday to try to get Drush 10 out of a project where I wasn’t ready for it (because while Aegir is amazing, drush 9+ support is still a WIP).

My first instinct was to use “alias”:

composer require drush/drush:"8.4.6 as 10.3.6" --update-with-all-dependencies

That worked, but I don’t actually need drush to be installed in my prod encironment at all, but it is in require in a dependency. That’s when Andrii told me about “replace”:

    "replace": {
        "drush/drush": "^10"

In… a fun loophole/feature, if you use replace but don’t specify a replacement, it acts like ignore.


I had a wonderful #OpenSource moment yesterday...

Our team at YMCA of the USA was midway through pushing updates to 150 sites on our Drupal PaaS offering when another Open Y partner agency’s team shared in Slack that they’d discovered a major issue with the code we were in the middle of deploying! ๐Ÿ™€ Even worse, when I started looking at the issue, it turned out to be a bug that I’d helped to introduce into the codebase. ๐Ÿ™€๐Ÿ™€

Over the course of yesterday, teams from around the world collaborated to push not one, but four fixes that we’d discovered. This was all made possible because the Open Y community has decided to work collectively, even as agencies competing for the same customers, in order to extend the YMCA mission into digital spaces.

Thanks to everyone who helped make these fixes possible. Our sites are better together!

When is a number not `input type='number'`?

When it “only consist[s] of numbers but isn’t strictly speaking a number”. See Why the GOV.UK Design System team changed the input type for numbers for more details.

While Drupal supports #pattern on FormAPI elements, there’s no top-level property for #inputmode. That can be added via #attributes, like:

$form['textfield'] = array(
  '#type' => 'textfield',
  '#title' => 'Any number of digits',
  '#pattern' => '[0-9]*',
  '#attributes' => [
    'inputmode' => 'numeric',