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."