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

[Shai Gluskin]

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>


On Wed, Nov 18, 2009 at 10:10 AM, Scott Reynen
<scott at makedatamakesense.com>wrote:

> On Nov 18, 2009, at 6:59 AM, Ashraf Amayreh wrote:
>
>  With 5000+ modules it would be impossible for the core team to keep up.
>>
>
> A similar bottleneck exists with the current system.  Seems like we could
> use a larger community contributing to the review process.
>
>
>  Any option to evaluate modules after they've been submitted isn't
>> practical at all.
>>
>
> That's an awfully broad rejection.  We already evaluate modules after
> they've been submitted; we just don't collect those evaluations explicitly
> anywhere.  But we do collect them implicitly via usage stats, issue queues,
> and several blogs dedicated to module reviews.
>
> Further, many other code repositories manage to pull off the task of
> reviewing code after it is submitted, e.g. github (forking), Google code
> (external), SourceForge (vote up or down).  We could probably learn
> something from those experiences.
>
>
>  The only alternative is to catch projects before they are even created by
>> requiring permission per project rather than a CVS account that can create
>> an unlimited number of projects/modules. Not to mention the added benefit of
>> introducing the module on the dev list to everyone which is a huge
>> advantage.
>>
>
> If we eventually move to distributed version control (as Dries suggested
> here: http://buytaert.net/8-steps-for-drupal-8 ), managing contribution
> via access to version control will become impossible.  We'll then need some
> way to accept and reject modules after they already exist in a repository,
> even if it's not the primary repository.  And that sounds a lot like many of
> the suggestions here.
>
>
>  A comment period would help with this.
>>
>> I disagree to this. When CVS owners find they won't be able to upload
>> their modules without getting an administrator's approval they will lean
>> towards introducing the module before writing code which would save on a lot
>> of coding work.
>>
>
> That assumes people realize Drupal CVS isn't open to all contributions
> before they write the code.  Because Drupal is relatively rare in evaluating
> projects before any actual code, it seems entirely reasonable for people to
> misunderstand this process.  And that's exactly what started this
> discussion.
>
> --
> Scott Reynen
> MakeDataMakeSense.com
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.drupal.org/pipermail/development/attachments/20091118/bc1c8a07/attachment.html