Skip to main content

benjamin melançon

Drupal Contributor Community Survey, Drupal 8 look-back edition

4 min read

... with my answers.

How many hours per week do you spend contributing to the Drupal project, on average? * 1-4 hours

How did you contribute most to Drupal 8? * YES: I helped write code for Drupal core YES: I helped write code for a Drupal contributed module or theme NO: I helped with Drupal information architecture, design, and/or user experience YES: I helped write and/or edit Drupal documentation NO: I helped provide Drupal community support (project management, organizing sprints, and other events, training, mentoring, etc.) NO: I did not contribute to Drupal 8 in any way Other: Project Application Review

If you contributed to Drupal 8, how likely are you to contribute to future versions of Drupal based on your experience? (1 Not at all likely - 5 Very likely) 4

Do you feel like you experienced burn-out during the development of Drupal 8? No

Do you think you would have taken advantage of a formal non-technical support program if one had existed during the Drupal 8 development cycle?

My involvement during the release cycle was very minimal. And it is much more rewarding and easier to self-pace to be involved in the additions to point releases.

Do you feel that there are non-technical barriers to communication in the Drupal contributor community? * Yes

If you answered "Yes", what do you think those barriers to communication are?

Still not enough people empowered / motivated to approve things. Issues stay in Needs Review for long periods of time. There are perceived bottlenecks to various ways of contributing - something is implicitly or formally someone's turf, and the actual bottlenecks - only project maintainers can bring your change to others, only the core committers can get it into core, only the mysterious select group of privileged project application reviewers (i'm one) can give you the ability to share a full module with the world - reinforces the sense of lack of agency even if the bigger problem is getting earlier reviews that technically anyone can do. Or equally demotivating, it's not clear by whom or by what process changes are approved.

The other big, big thing is 'aggregating needs', so changes in fact desired by many, many low-resource organizations and individuals (i'm thinking Drupal's end-users here) can get the level of resources one large organization can put into their needs.

If you answered "Yes", what organizational changes do you think would improve the Drupal contributor experience?

Make clearer how both code and non-code decisions are made, regarding everything, and widen the group of people both actually and ... mentally? ... empowered to approve changes.

What is the number one non-technical change that you feel should be made to improve the Drupal contributor experience?

Whatever we do, we must treat new contributors substantially the same as existing contributors. This refers to the Project Application Review process. If no other contributors in this survey are talking about the Project Application Review process, that is the most damning evidence about how broken and ghetto-ized the process is for crucial new contributors.

We need a whole new system that treats old-timers the same way as newbies, or else whatever system we come up with will be inadequate and won't be fixed. If it affects everyone, it will be fixed.

The new system: Anyone who wants to promote a project to full project status needs one other person with two promoted projects to review and endorse the project. This person approves knowing that their reputation and permission to approve projects is on the line:

A related way to contribute with fewer gatekeepers is forking on d.o; your non-official module is namespaced to your username but it still has the full project name and can be referenced through composer. But this is a technical change.

c: 2016 June 3, Friday, 8:55 AM