I agree Pierre, Scott, Greg and others who do <b>not</b> 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:<br><ol><li>
<b>Issue queue, issue queue, issue queue</b><i>. The issue queue is the window into a module</i>. 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. <i>We need to be more explicit in our docs about teaching new people just how to study the issue queue to make these evaluations</i>.</li>
<li><b>A</b><b>dvertise the module feed</b><i>: We need to better advertise the module feed</i> (<a href="http://drupal.org/taxonomy/term/14/0/feed" target="_blank">http://drupal.org/taxonomy/term/14/0/feed</a>). 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.</li>
<li><b>Move dev list to g.d.o.</b> 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. <i>Why hasn't this list been replaced by a group at <a href="http://groups.drupal.org">groups.drupal.org</a>?</i> Try doing a Google search and limiting your results to: <a href="http://lists.drupal.org/pipermail/development/">http://lists.drupal.org/pipermail/development/</a>. 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.</li>
<li><b>More stats:</b> 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.</li>
</ol>Shai<br><br>Shai Gluskin<br>Owner<br><a href="http://content2zero.com">Content2zero Web Development</a><br><br><br><div class="gmail_quote">On Wed, Nov 18, 2009 at 10:10 AM, Scott Reynen <span dir="ltr"><<a href="mailto:scott@makedatamakesense.com">scott@makedatamakesense.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><div class="im">On Nov 18, 2009, at 6:59 AM, Ashraf Amayreh wrote:<br>
<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
With 5000+ modules it would be impossible for the core team to keep up.<br>
</blockquote>
<br></div>
A similar bottleneck exists with the current system. Seems like we could use a larger community contributing to the review process.<div class="im"><br>
<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
Any option to evaluate modules after they've been submitted isn't practical at all.<br>
</blockquote>
<br></div>
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.<br>
<br>
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.<div class="im">
<br>
<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
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.<br>
</blockquote>
<br></div>
If we eventually move to distributed version control (as Dries suggested here: <a href="http://buytaert.net/8-steps-for-drupal-8" target="_blank">http://buytaert.net/8-steps-for-drupal-8</a> ), 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.<div class="im">
<br>
<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
A comment period would help with this.<br>
<br>
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.<br>
</blockquote>
<br></div>
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.<br>
<font color="#888888">
<br>
--<br>
Scott Reynen<br>
MakeDataMakeSense.com<br>
<br>
<br>
</font></blockquote></div><br>