Unplugging the On-Ramp

TL;DR: A proposal for changes to the scope of the ‘git vetted user’ permission on Drupal.org, and the related project packaging and release capabilities associated with it; changes which would affect not only Drupal’s “new project application” process, but all contrib module authors.

Background

Much has been said about Drupal’s Project Application process as of late. Whether you are for or against it, there is one thing that everyone can agree on … we simply do not have enough volunteers to effectively manage the queue, and the resulting wait times can be somewhat frustrating for new contributors.

Over the last year and a half, we have made a number of tweaks to the process, with items such as the 'Review Bonus' program significantly increasing the number of people providing preliminary structure and code style reviews. Unfortunately, this progress has been offset by a sharp drop in participation by our more experienced reviewers and git administrators. As a result, applications are quickly moving up to RTBC instead of waiting weeks for an initial review ... only to stall out at the 'final approval' step for weeks at a time (or even months, in some cases). The truth is that the changes have not addressed the fundamental issue: it takes a significant investment of time to provide a review detailed enough to meet the standard of quality being enforced in the queue, and the current volunteer-to-applicant ratio is nowhere near what it needs to be to efficiently process applications in a timely manner.

But enough people (myself included) have shared their thoughts regarding ‘what’s wrong’ with the process today … and as the “project apps venting threads” exploded with activity again this winter, I found myself silently wishing we could get past the complaints, and back to focusing on solutions.

Well, simply wishing something does not make it happen. Without a defined end goal in mind, we find ourselves hampered by the ‘inertia of the status quo’, and thus restricted to minor, one-off, incremental changes which i) are small enough in scope to be pulled off by single individuals, and ii) do not significantly change the underlying process.

Looking back at my original proposal from 18 months ago, if fell apart on two fronts. First, while 'automation' is a noble goal, the proposal lacked definition around the 'next steps' or implementation details needed to achieve that goal. Secondly, discussions on this particular topic tend to go in circles, waiting for someone to say "Yes! Let's do this!" ... but with no obvious 'owner' of the process, that perceived validation/justification never comes.

While evolving governance discussions should help us to address this second concern, we still need to come up with a new model definition ... one which addresses potential concerns around security, code quality, and module duplication; while at the same time eliminating the enormous barrier of entry that the ProjectApps process has created for new contrib module authors.

With this in mind, I would like to propose a fundamental change to the scope of the ‘git vetted user’ permission on Drupal.org, and the related project packaging and release capabilities associated with it. Yes, it's long, but please read on ... this affects all contrib module authors, not just new applicants.

The Proposal

Step 1: Expose the 'project shortname' field on all sandbox projects

This field stores the proposed 'project shortname' for a given project. For sandboxes, the field would be editable by the project owner, but read-only to all other users. Validation logic on this field would ensure that the shortname does not conflict with any previously established projects. Validation could also go so far as to warn users about namespace conflicts with other sandbox projects, while still allowing the field to be saved.

Step 2: Write code, commit to repository, and run automated reviews

As soon as the sandbox is created, the project owner may begin committing code to the repository. Each code commit would trigger two automated reviews ... one to validate the repository structure, and one to validate the code style of the included code, using Drupal CodeSniffer. (Automation of these tasks has already been implemented within the Project Applications queue, through the ventral.org PAReview tool ... under this proposal, the same functionality would be ported over onto Drupal's automated testing infrastructure.)

The most recent results from both of these reviews would be collected and displayed within the sandbox administration page for the project, along with a mechanism to re-trigger the reviews (to clear any infrastructure-related failure conditions). In any cases where the reviews fail due to detection of a false positive, an 'override' checkbox would be made available to administrators, which could be used to indicate a manual override of the failed result (triggered via a request to the projectapps or webmasters queue).

Step 3: Promote out of sandbox

As long as both the 'Git Health Check' and 'Code Style' tests are passing (or overriden), the project namespace has been approved, and a valid release tag exists in the repository, a 'promote out of sandbox' link would be made available available to the project owner. This link would basically have the same effect as today's 'promote to full project' link (with one restriction) ... it would move the project over to the final project namespace and enable the creation and packaging of -dev, -alpha, -beta, and -rc releases.

Step 4: 'Non-vetted git user' restrictions

If the project owner is not yet a 'vetted git user':

• The packaging system would allow the creation of -dev, -alpha, -beta, and -rc releases, but no 'final/stable' releases
• A prominent warning notice would be added to the project page, stating that
  1. The module has been contributed by an author who has not yet run through Drupal's one-time peer review process,
  2. It is recommended that the code not be deployed on production sites without a full and thorough code and security review, and
  3. Users installing the code do so at their own risk.

Users wishing to remove this warning from their project pages would need to obtain 'git vetted user' status, which would follow the existing 'project applications' process as it exists today. Given that projects had to pass both a repository health check and code style review before moving out of the 'sandbox' state, they would be entering the process in a much more 'polished' state. In addition, as any stalling at this stage only prevents creation of a 'stable' release, reviewers can enforce a high standard of acceptance; and applicants should be much more tolerant of delays in the review process if the queue does happen to get backed up.

Step 5: 'Stable Release' notifications

As an added incentive for maintainers to produce 'stable' releases (and for non-vetted users to pursue 'git vetted' status), any projects which do not have a supported 'stable' release would receive another prominent warning notice on their project page:

"This project does not have a stable release on a supported major branch, and thus is thus not subject to release of Security Advisories by the Drupal Security Team. Note that the presence of a stable branch does not guarantee that the code is secure, only that the security team will consider the generation of a security advisory in response to any reported security issues."

This means that non-'git vetted' users will have two warnings displayed on their project pages by default, as they would be prevented from producing stable releases.

Projects which do have a 'full' or 'stable' release would receive a much less prominent notice, stating something along the lines of:

"Only the supported major version branches ([list of branches for the project]) will be considered for Security Advisories in case of any security issues brought forward to the Drupal Security team. Note that the presence of a stable branch does not guarantee that the code is secure, only that the security team will consider generating a security advisory in response to any reported security issues."

The exact contents, location, and formatting of these warnings on the project page would be subject to further debate, but the point would be that the first two are intrusive enough to incent project owners to create stable releases.

I'm throwing this out there for community opinion, feedback, and debate.

I do not have the bandwidth to implement all of the above myself ... but if, after community discussion, the above proposal is perceived to be viable, I will volunteer to take the next step of mapping out an implementation plan. This plan would identify a complete task list, broken down into a series of manageable bite-sized pieces, ready to be tackled by anyone in the community. I will also make myself available as a mentor for anyone who attempts to take on any of the identified tasks, whether it be helping them get set up within the drupal.org development environment, understanding of the project* module data structures, assistance in understanding the required testbot integration pieces (which I will prime), or scheduling meetings and/or sprints as required.

This process is one of the main on-ramps for new Drupal contributors entering our community ... and we have neglected it for far too long. Please take a minute to provide your honest opinions, feedback, and suggestions for improvement related to this proposal ... or maybe even propose an alternative solution of your own. And if you can spare it, spend an hour or so over in the Project Applications issue queue ... because the truth is that no major overhauls are going to happen overnight, and in the meantime, there are a number of poor souls sitting patiently in that queue; waiting for someone to come along, look at their code, and welcome them as they make that crucial next step from Drupal 'user' to Drupal 'contributor'.