[development] An alternative to common thinking in 5-> 6migration

[David Metzler]

On Mar 11, 2009, at 5:45 AM, Marcel Partap wrote:

>> Previous posters brought up arguments, but you obviously did not  
>> understand
>> them.
> ???
> Where are those? Despite
> - it would place all load upon a small load of developers who are  
> already overloaded (not true)
> - would stiffle innovation (hardly true - restriction only on repo  
> commits)
> - don't like it because it messes with my ways (can't argue with that)
> there was no argument i am aware of, and none of those strike me as  
> real compelling evidence quality restriction would be a bad idea.
>>
To All:
Sounds like there's two threads here, one about avoiding unnecessary  
module duplication and another about improving quality of code that  
does get committed.  We've mostly been talking about the former.  But  
I sort of feel like commit time is way to late to be talking about  
strategies for eliminating module duplication anyway, so.....

The current documentation on drupal.org basically suggests you should:

     * to produce your contribution.
     * to apply for contributor privileges.

In the interest of moving this forward/closing this.  I've opened an  
issue at:

http://drupal.org/node/396946

Which discusses adding guidelines for vetting your module idea. If we  
have a process.  Now there is already the Joining Forces With others  
doc at http://drupal.org/node/23789.  Which describes the desire to  
communicate, but if there's a recommended protocol, perhaps we should  
include it in the basic process description?

To Marcel:
The stifle innovation argument is valid although you've called it  
invalid several times.

You have proposed that 10 (not high profile) developer reviews would  
be required in order to commit code. Assuming you mean what you say  
and the overloaded developers (high profile) don't have an increased  
workload, then that means i need 10 reviews to get my code committed.  
I maintain a non-duplicative module that plays an important role in  
universities that are doing single sign on with drupal.  I have  
struggled with getting ONE person to review my patches, but my code  
does get reviewed at my place of work, outside of the drupal  
commmunity.  This project would likely not be viable on drupal.org  
under the solution you describe.

There are several ways for you to get involved in patch reviews:

1. Play Contrib patch Bingo
2. Filter the project issue queue by Feature Requests that are Ready  
for Review
3. Subscribe to the issue queues of projects you're interested in  
helping with.

I would add my voice to the voice of other that suggest that there  
are more effective ways for us all to spend time improving quality of  
contrib code, the biggest of which could be joining the developer  
documentation effort.