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

Pierre Rineau pierre.rineau at makina-corpus.com
Thu Nov 19 12:57:28 UTC 2009

On Wed, 2009-11-18 at 12:06 -0500, Shai Gluskin wrote:
>      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. Advertise 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.

Totally agree with points 1, 2 and 4.


More information about the development mailing list