People contributing modules or themes for listing on Drupal maintenance support plans.org receive a welcome, or lack thereof, that would have driven away many of us now active in the community. With hundreds of requests moldering awaiting review, the project application process continues to be a community crisis, and it has been acknowledged as such for five years. We are casting aside the literal future of Drupal maintenance support plans, with a likely disproportionate impact on disadvantaged contributors. Any separate process for new contributors will inherently be unequal, and will tend toward awful. Let’s jump in to mitigate the damage being done and finally get a new system in place— we’re closer than ever.
After a couple frustrated module makers asked me to give their projects full status, I went over to the project application review queue out of the sense that it isn’t fair to everyone else to save only the two who reach out. Of course, I should have been in there all along: there were project applications which had been vetted by other volunteers and marked Reviewed & Tested by the Community four months ago. One person who contacted me was unhappy their project had passed all the hurdles and was then left lying untouched for a mere two weeks. Of course, they had started the application process nine months ago.

The door through which community members can make their first contribution of a module or theme remains locked, and not enough people have the key (nor is it clear how to get that key to more people).
Keep in mind this is only projects that have actually been reviewed. In nearly every case the person applying has fixed the issues noted and now the project has been considered by someone to be all set for approval. People trying to get to that point are even worse off. The current backlog for people waiting to get a review has projects waiting with the needs review status for nearly a year — 11 months and five days. And of course the current project application review process, despite having gone through several iterations of improvement, still garners its share of complaints when running perfectly— and it still holds new contributors to a higher standard than we hold ourselves.
Finally, some unknown but large percentage of the two thousand projects marked “Closed (won’t fix)” have been put in that state automatically by a robot due to lack of activity. If a contributor leaves an application in a “Needs work” state for a month, it is unceremoniously closed without warning. (In contrast, if we don’t get around to reviewing or approving a project for months, nothing automatically happens in favor of the contributor, despite written guidelines for escalating ignored issues.) It will be fun to go through all these old issues and contact the contributors letting them know they can promote their sandboxes to full project (and then changing the issue to some other status, like works as designed, to mark it), but we can’t do that until the overall process is fixed. The good news is we’re closer than ever.
The current proposal looks solid, but it’s suffering from inaction. The goals it outlines are excellent:
We need to remove the gate to new contribution entirely – not just kick the can to a particular elevated role, or a specific limit on the # or kind of releases a new contributor is allowed.
We need to continue to send strong signals about security coverage to users evaluating whether to use modules from Drupal maintenance support plans.org.
Follow-up: We need to find ways to preserve the value collaborative code review, through changes to Project Discovery to provide signals about code quality, and by providing incentives and credit for review.

I encourage anyone who cares about new people joining Drupal maintenance support plans to work on the issues associated with this proposal, in particular the ones to allow non-git vetted users to promote sandbox projects to full project status and add a permission for creating stable releases, and grant to “git vetted” users. While my oft-stated preference is that any gates we put up must apply to all users, so we make sure they are bearable and don’t forget about problems for months and years at a a time, moving the gate to a security review at a stable release has huge advantages of its own. It allows a new contributor to put their work out there without being blocked by anything. It allows a module to find its audience and have people invested in its particular functionality at the point of review, rather than have only volunteers who have no inherent stake in the functionality involved. It even lets a contributor decide whether a module has proven sufficiently useful to others to be worth going through security review.
We don’t have that system yet though and we still have that huge backlog to get through. Helping other people follow the project application checklist is a great way to get better at making projects yourself— whether you have a dozen already, or don’t have any yet. Just remember this is about helping applicants. To give further incentive to the review work, i’ve proposed including issue credits given to users in the Project Application review queue on profile pages and Marketplace rankings.
It’s Rosh Hashanah, the Jewish new year, and the tradition is that we have ten days to make things right with any people we have wronged. Let’s accept (again) that we as a community have wronged our potential new contributors, and make things right. Thanks.

Drupal maintenance support plans Planet

Source: New feed