[development] CVS Approval Policy: was Re: new features in D6 core?

[Antonio P. P. Almeida]

Getting a proper balance between a topdown vs. a bottom up approach is
never easy. There's surely an issue with the current proliferation of
modules on d.o. But the problem is not the numbers per se, but rather
that each project page has very sparse information about the module
quality.

I agree with Shai, more stats is better. It will help people make a
better decision about which module to choose when there are several
proposing a solution to a given problem. Let the market forces act and
all the distributed knowledge contribute to a better d.o and drupal
ecosystem.

One idea that could improve code quality in contrib would be to have a
code evaluation bot so that when you upload a module it runs it
through Coder Though Love http://drupal.org/project/coder_tough_love
and only after passing the test will be available as a new
release in the project page.

That's for syntax and code style. For the logic let the community sort
it out through their usage of the modules. Better stats and a good UX
will catalyze the process of separating the wheat from the chaff.

--- appa


On 18 Nov 2009 17h06 WET, shai at content2zero.com wrote:

> I agree Pierre, Scott, Greg and others who do *not* want to tighten
> the module contribution process. I support other ways to deal with
> the issue of module duplication. Some points that have not been
> raised:
>
> 1. *Issue queue, issue queue, issue queue**. The issue queue is the
> window into a module*. By studying the issue queue for less than 5
> minutes (sometimes 20 seconds) you can determine the quality of
> maintenance and the level of current activity in terms of new
> features and future development. *We need to be more explicit in our
> docs about teaching new people just how to study the issue queue to
> make these evaluations*.
> 2. *A**dvertise the module feed**: We need to better advertise the module
> feed* (http://drupal.org/taxonomy/term/14/0/feed). Why isn't it on the
> module pages at d.o.? Getting more people to subscribe will help nip
> problems early if there is clear overlap. It also helps people get people
> interested in modules and can help develop collaborations etc.
> 3. *Move dev list to g.d.o.* The dev list is important. And people should
> be encouraged, but not required, to run ideas by this list. But I've got
> problems with this list. *Why hasn't this list been replaced by a group
> at groups.drupal.org?* Try doing a Google search and limiting your
> results to: http://lists.drupal.org/pipermail/development/. It's
> pathetic. I don't know what the problem is. But I don't think it is worth
> fixing other than migrating to g.d.o. I don't think this list should be a
> requirement for anything. We aren't eating our own dog food on this list.
> 4. *More stats:* The relatively new usage stats at d.o. are awesome. They
> provide a nice resource for people evaluating modules. Lets develop some
> other stats as well. Here is one that I've thought about: Output a percent
> which is the number of posts and commits in a queue by maintainers divided
> by the total number of posts on the queue within the last year. It could
> give a quick sense to folks about the level of participation of the
> maintainer(s). A stat like that couldn't be used alone to make an
> evaluation, but in conjunction with other information, it could help. I
> think there is a lot of data that is sitting on d.o. that we are not
> leveraging. I'm in favor of developing more stats, which maintain
> themselves, rather than having some "core group" make evaluations.
>
> Shai
>
> Shai Gluskin
> Owner
> Content2zero Web Development <http://content2zero.com>