Drupal is an Open Source project originally built by a community of hobbyists. Today, its code is publicly visible, publicly maintained, and publicly built. Do you find the documentation to be unclear? Anyone can fix it! Do you find the user interface for Drupal unintuitive? Anyone can fix that, too!
With Drupal’s popularity and the number of Drupal developers out there, surely most Drupal developers have contributed something, right? Not quite. According to Dries' blog post titled "Who Sponsors Drupal Development (2016-2017 edition): "the top 30 contributors (the top 0.4%) account for over 17% of the total credits, " Note: That quote only factors in counts code contributions; this article discusses both code and documentation contributions.
30 developers accounting for over 17% of all contributions in a calendar year would not happen if half of the users of Drupal were contributing something, even something relatively minor, when using Drupal. Why isn’t that happening?
Contributing to Drupal for the first time is not easy. Users attempting to contribute to drupal.org for the first time experience some so much friction. How much are usability issues when contributing code or documentation costing the community in terms of lost contributions?
One study showed that a badly designed checkout experience cost a single company upwards of 300 million dollars in revenue per year. That refers to lost sales after the user already selected the product and decided to pay for it. The site's password reset functionality on their log in form caused over 300 million dollars of purchases to be aborted in one year.
Compare that situation to contributing to Drupal. In that situation, the user already selected the product, would have received something tangible that they chose, and their only ‘hurdle’ was overcoming a standard login form with a reset password link.
When contributing code to Drupal, you must:
-
For code contributions:
-
Register & Log in to Drupal.org
-
Get your account confirmed (either post periodically for months, or create an issue and wait for someone to approve your account)
-
Skim the 1-100 comments on the issue(s) you’d like to help with
-
Clone a specific project’s repository on your machine using git
-
Follow the ‘how to submit a patch’ steps
-
Submit your patch
-
Wait X days/months/years for someone to review the patch
-
Correct any issues that were reported. Repeat f & g until no issues remain
-
Wait X days/months/years, or indefinitely, for a maintainer to merge your commit
-
-
For drupal.org documentation contributions:
-
Register & Log in to Drupal.org
-
Get your account confirmed (either post periodically for months, or create an issue and wait for someone to approve your account)
-
I’ve heard that even verified accounts can’t edit documentation right away.. Is there a time period they must wait? I know talented technical writers who have abandoned editing documentation on drupal.org due to a lack of permission
-
Edit the documentation
-
Item 2 in each of those lists is likely to kill the motivation of a first-time contributor looking to edit documentation. They want to edit the documentation now. They don't want to make a request to edit the documentation in the future. I know this is true because I have seen it happen.
How many times have people started contributing a patch or documentation, only to give up?
How much better would Drupal be today if that barrier were much lower?
What can we do better?
Implementing UX improvements on Drupal.org is the ultimate goal, but that will be quite an undertaking. In the meantime, we will be testing "Barrier-Free Contribution Sprints".
A barrier-free contribution sprint is a live event featuring the following:
- Clutter-free, detailed, concise issue summaries
- This can be done in the drupal.org issue queue, requires time investment to prepare each issue
- Ability to submit their contributions as soon as they're ready
- For example, in a shared Google doc open to the public. Changes can be saved here initially, and when they're ready, someone can go through the steps to formally submit the edits on drupal.org
At Debug Academy, we’re starting locally (in the Greater Washington DC area) by hosting regular drupal.org Documentation & Contrib module/theme sprints specifically geared towards beginner contributors. The first one is planned for March 11th ( https://www.eventbrite.com/e/barrier-free-drupal-sprint-great-for-new-contributors-tickets-43245622822 ).
To simplify contributing, we will provide fully summarized issues with clear instructions. We will target 2 main areas: Documentation on Drupal.org (such as improving the Form API documentation for D8) and a contrib theme (or module) which we are maintainers of. We will remove all barriers to contribution by using our own task management system before and during the sprint, and then we will update the corresponding issues on Drupal.org after the work has been contributed.
We will ensure all attendees are properly credited for their work on drupal.org, and that the drupal.org issue statuses reflect the latest work complete. Ultimately, we want the contributions to be easy to create and easy to submit. That’s it. That is how we will maximize the number of people contributing to Drupal. After the contributions are received, we will deal with the red tape on drupal.org ourselves, because expecting that of a first-time contributor may result in never receiving their contribution at all.