What's your idea?
Force full project review for ALL projects, not one time only per user.
Today if a user gets a project approved to be a full project the user gets a role which can promote ANY project in the future without review.
This should be changed force reviewing ALL new projects, instead of giving this role to the user.
What are the benefits?
- All projects will get reviewed before being promoted to full projects
- Full projects will have improved quality, as many crap will not be promoted
- Avoids duplicated projects
- Avoids project fragmentation
- Helps enforcing coding standards
- Helps enforcing best practices and use of Drupals API correctly
- Helps enforcing code contains a minimum of handwritten code
- Making it one time only developers will have to review 3 other projects every time they want a review bonus - it will force developers to learn how to review in order to get it.
What are the risks?
- Slows down new good projects getting promoted.
- Increased obstacles to contribution mean a greatly increased likelihood that people will not contribute their code back to Drupal.org at all.
How can we measure the impact of this idea? (metrics)
Many many crap modules promoted or used by only 1 site (real modules, not to be confused with projects which are not modules, such as drush or dreditor).
Who directly benefits from / will use this improvement? (target audiences)
- Anyone who wants quality modules.
- People who uses the d.o modules search - by not having many crap there
- Site builders
- Developers
Having said that, if people stop contributing to drupal.org because of this then these target audiences either get fewer good modules as well, or they get fragmentation as people post their modules in random places over the net and you have to go find them.
Comments
I like the idea
I like the idea but PAR review is just not possible. It takes way too much time and effort and it is no fun at all if you have to read 1000 lines of code with no interest. Our PAR review team is doing their best. Now we even have PAR bot :). I think the realistic thing to do here is create a PAR bot gate for new project promotion which check for coding standards, directory structure and etc. No human can do full-project application review.
First automated, then manually
I agree in parts.
The automated review can be the first step of the verification. If it pass, than go to an human review, more focused in the module's usability and purpose.
Stephen Camilo
http://stephencamilo.com
"Needs work" list
Sounds good.
But we need to focus on not only approve or disaprove the module, more than this we need to make it happen.
In case the module doesn't pass the criterias, if the idea has potential of being helpful for the comunity, it could go for a "Needs work" list with some feedback.
Stephen Camilo
http://stephencamilo.com
Added a very significant
Added a very significant risk, which is that the more barriers you throw in front of contributors, the less likely they are to contribute. The very real risk is that we end up with fewer contributors and less open source Drupal code if we do this. Are we sure having fewer "crap" modules is worth this risk?
FWIW, I believe we should do the exact opposite: put decent quality metrics on projects and "filter on output, not on input," just like Drupal.
It depends on what are the metered points
The proposal you pointed is about user reviews only.
I agree metrics would be a better way to filter crap if these metrics are based on points like:
And maybe even more points. Having an "approved seal" to the projects that meet all these points.
Maybe making this "approved seal" optional and delivered to projects which are submitted to an quality review? (I'm feeling like changing the proposal)
The discussion in that
The discussion in that proposal is suggesting variations like that, yep. Go ahead and chime in with your thoughts.
Agreed. Our current review
Agreed. Our current review process, and the champions in there, are already having a mountain to climb. We don't need to make it even bigger.
Also, the current process is based on an educational and trust system. When the reviewers have found that applicants respect our guides and also are skilled enough to produce high quality code, then that shows the applicant have earned community trust.
In the rare cases someone would go rogue, then it can be dealt with and in worst case the permission be revoked. The extra work this would inflict is negligible compared to if every new project was to be reviewed.
--
/thomas
T: @tsvenson | S: tsvenson.com
I agree
I definitely agree.
I really don't think there is that much of an issue with low quality modules anyway.
It's not that common for me to go looking for a new module to do something only to find a module that really looks like it will be good but turns out to be a nightmare.
Usually the modules are good, or there are warning signs, like lack of maintenance and a very small user base.
I know there are broken and duplicate modules out there but if they are useful modules they are often fixed up by someone.
Also, the burden this would put on the reviewers would be insane I would think.
For me personally, after seeing some of the issues in the current review queue, I would probably not bother submitting modules if they had to be reviewed every time and I think a lot of people would be in the same boat. (by no means is this a jab at the reviewers, it's just a very frustrating process.)
While I don't want to end up in the same position as wordpress (either I'm looking wrong or there are a huge amount of bad wordpress plugins), I think less restriction is better than more.
I agree with the consistency
I agree with the consistency of this proposal. I disagree that we need a human moderation at all. IMHO removing moderation for the first project is the way to go.
Additional moderation can be achieved by automated tools and post-reviews (and it could be used only for objective criteria like security holes, license infringements, spam, etc).
In theory it works. In
In theory it works. In practice it won't. A project with 5 line .info file and 20 line .module file may still be a good project and can be promoted automatically. But what happen after that?
I think the spirit of
I think the spirit of requiring a thorough review of a new project is not to prevent entry to maintainership but to help mentor the submitter. This helps insure that they are aware of all of the resources for building a successful module and gets them connected to members of the community. The added bonus is that projects that are not ready to be published don't get published.
I opened a proposal for #1 in
I opened a proposal for #1 in the list at this link, but didn't get around to #2 through #5 ... If you re-brand this issue "Improve the Project Applications Process", then they would apply here.
https://drupal.org/node/2034437
The full proposal definition behind the meta issue can be found here:
https://groups.drupal.org/node/291343
Do this, and I'm done with
Do this, and I'm done with posting code to drupal.org.
No,Sorry for the blunt
No,
Sorry for the blunt starting point there but there are those of us here who run businesses and when we have time we contribute back modules that we have spent time and money developing and reviewing. Having to spend time reviewing other code to get these modules on Drupal.org is not going to be appropriate.
It would certainly discourage my business from contributing back to Drupal.org (Currently maintain 6 modules and 1 theme with no major issues on any project and all projects meet coding standards) and would increase fragmentation and I'm pretty convinced that other business contributors would take a similar view. Drupal has procedures to address poorly written or maintained modules - namely people don't use them and they eventually die. I'm not convinced that adding to the workload of project reviewing teams and complicating the workflow of people who may have been writing Drupal modules since Drupal 1, 2, 3 etc.
Sure, it could clean up Drupal.org but it's actually more likely to hurt in the long run, Drupal's advantage is that modules and themes are in one place not fragmented across the web. I'd rather keep that advantage, including the badly coded modules, than loose it and have Drupal end up resembling Wordpress with modules spread across various sites of widely varying code quality - that's not a Drupal I want to see.
There's enough work for module developers with coding and testing their modules without additional administrative overhead, if you want to make code quality better on Drupal.org - get involved, write issues, take maintainership of modules where the author won't fix problems instead of standing on the sidelines (that's an assumption on my part, some of the commenters in favour may be valued contributors but it doesn't seem evident in the tone of the original proposal) and lamenting the lack of 'decent' modules.