People contributing modules or themes for listing on Drupal.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, 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.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 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.
Comments
2016 October 05
Cameron Eagans
> The current backlog for
> 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
Note that this number is somewhat artificially deflated. The only reason that the queue doesn't have older items in it is because I went through the entire thing last year and cleared it out (https://twitter.com/cweagans/status/621776271329107968) at NYCcamp. I'm not here to brag. During that process, I reviewed a project that was nearly 2 years old. It really sucks that I had to do that. I spent a good part of the day doing it, and that time could have been better spent on many other things.
2016 October 05
develCuy
We need a new process
Three things we could do (from hard to radical):
2016 October 06
David
As someone that has tried to
As someone that has tried to get through this process 3 times and currently has one of those projects listed, as well as several sandbox projects that people are actually using on their sites, I agree. If Drupal wasn't basically my full time job I would've given up after attempt 1. Which also took too long. As it stands this is the sole reason I don't even join the Drupal association anymore. I do still attend Drupalcon though.
2016 October 06
Binu Varghese
[D8] Bootstrap Mint
Thanks for this write-up..!
My D8 theme contribution is still in needs review for more than 2 months now.. its really discouraging.. all the initial euphoria of contributing more themes to Drupal is now fading away.. to say the least..
Bootstrap Mint - https://www.drupal.org/node/2757097
Hope this deadlock is resolved soon..!
2016 October 06
H Kern
Problem exists for project issues and core fixes
Many users of contrib modules find problems fix them, then find out that others already did the same, but the patches don't make it into the module.... Same for core. So, what's the point of figuring it out, preparing a patch, and submitting it?
The ability to submit pull-requests might move some of this activity through the system.
These are all part of the same problem, which is the closed-ness of the system. Somehow, github keeps a completely open system and it works.
2016 October 07
mlncn
Wow
Thank you Cameron. And there's a small set of volunteers, notably gisle and klausi but a lot of other repeat reviewers also, who are spending a huge amount of time on it. We just tried to force a culture of peer review on our newest members before we inculcated that in all contributors to contrib. And it didn't work. Now to finally fix that with no more delays. So yeah. Maybe prioritize fixing over reviewing— but whatever someone feels they can do, but knowing their effort won't mean we're in the same place in a year.
2016 October 14
Suzanne Aldrich
This will be the death knell of Drupal
Long time Drupal site builder here (10+ years on drupal.org). I've actually never contributed any of my themes or modules because the "system" to do so is very antiquated and gatekeepered. Patch files? Really? The rest of the world moved onto pull requests years ago. Meanwhile, to hear of the languishing of new D8 based projects is very disheartening. This is a really bad sign. Locking out new contributors is a sure way to kill Drupal. It certainly isn't helping with uptake. It's very depressing to get emails on 5+ year old issues still open because the patches get so old they have to be re-rolled and re-submitted, and only a few people have access to merge them. There are several contrib modules I use where all active development is taking place on Github. I raised this issue at DrupalCon New Orleans during the keynote QA and Dries seemed a little more open this year to changing the way we contribute to Drupal. I think this serious problem needs to be escalated, or we will risk the slow petering out death of Drupal. Who are you really protecting when you take so long to incorporate input?
As a final note I want to quote some paragraphs from a recent eulogy written by an acquaintance of mine, which really struck me as relevant to this pressing issue with Drupal contrib:
Pieter Hintjens’ Last Hack
Add new comment