[development] RFC: Candidate 'premium' modules

[Earl Miles]

Karthik wrote:
> Premium modules are those that are:
> 
> a) release-critical - A new version of Drupal cannot be released
> unless these are up-to-date.
> b) quality controlled - these will be 'core modules' in all but name.
> c) well maintained - HEAD, current release and previous release should
> all be maintained preferably by a number of maintainers.

I actually talked this over with chx in the IRC, and said I'd send my thoughts 
on it to the list, and then didn't do that part. Mea culpa.

Here's my theory:

Scratch a). Can't call them release critical, because you can't have someone 
falling asleep at the wheel hold up things for everyone else. That said, b and c 
are important. But it's more than just b and c.

So here's my version of the proposal.

Drupal High Profile Modules
===========================

1) People close to Drupal, which is a rapidly evolving group of people that will 
likely have members leave and join but will generally be readily identifiable 
will take responsibility for code reviewing these modules, particularly in terms 
of security and ensuring that they are safe to run with Drupal.

2) These modules will be readily identifiable on drupal.org as these modules, 
and users can download them with an extra level of comfort knowing that a 
central part of the community has tested these modules.

3) These modules will serve as examples for other contrib modules to emulate.

4) The security team will treat security reports against these modules 
seriously, and will be willing to patch these modules and write security 
announcements when these modules are found to have security defects.

This doesn't require much code, really; it does require a process wherein people 
who are trusted do code reviews against the candidate modules, and that the 
results of those reviews are taken seriously. It requires that commits against 
these modules are followed by Drupal developers, looking for mistakes. And it 
requires that the Drupal project module have a better release process so that 
these modules can have real versioned releases, like Drupal itself has.

Modules will be chosen to be in this category based upon quality of code and a 
general sense of widespread use. A good indicator of whether a module should be 
considered for this role is the number of downloads / searches on the module. 
This indicates a level of interest. But it is only one factor; bad code won't 
fix itself, and this proposal doesn't require any of the Drupal developers to go 
fix other people's modules, except for security issues. And even then, the 
security team's role may be to remove the module from the list and say "This 
module is dangerous, we can no longer recommend its use."