[development] Wasting time and effort - Here's a productive suggestion instead

[Dan Morrison]

> From: Marcel Partap <mpartap at gmx.net>
>
>> PLEASE Look at that thread and you will see many others also against
>> *enforcement* ( = manpower & acrimony) but for a generally useful
>> community-based process.
> So enforcement of coding style and not breaking tests is too large of
> a price to pay, now i see.

Coding style reviews are good, and can even happen automatically.  
That's trivial.
There is even a process for running automated tests. Although you may  
find that almost no contrib modules HAVE tests. This is a non- 
automatable detail. Modules breaking tests is not an issue for users.

However, neither of these have anything to do with the very real issue  
of DUPLICATION and overlap.

>> Note, not a "core developer" gatekeeper team,
> Even after me going to lengths doing 20 or so postings to explain and
> reason what i have in mind, it's amazing people still misunderstand
> what i propose. Is it me or them.

The ONLY way to actually tell good code from bad code, and tell  
duplicates and redundancy is by informed developer review.
That is the manpower needed. And as noted earlier, it needs to be  
skilled devs, not just popular vote. Which leads us to back to  
requiring housekeeping work by some non-existent cadre.

>> but better visibility and feedback loop to resolve dupes.
> Frigging exactly what i proposed.

No. "Visibility" and feedback on proposed modules was was my  
suggestion last year.
What I saw you propose in [Date: Sun, 08 Mar 2009 16:30:29 +0100] was  
bureaucracy, enforcement, automation, restrictions, vetos, and the  
belief that better code could be automated by :
> what is possible is to come up with an algorithm that leads to
> a statistically significant improvement on the sustainability and
> correctness of decisions.

I just gotta disagree that good, or more importantly - useful and  
unique - code can be judged by an algorithm in a way that will address  
the problem at hand.
If you have such an algorithm handy, please suggest it as an addition  
to coder.module.

> Why does that make me wonder
> what sort of device would be required for making a human being to
> constructively try to understand someone else's perspective and
> subsequently reconsider their own position.

:-)

>
> btw abundant opposition happened before in history to non-messiah
> people which were more right than wrong.

And so you completely miss the point. o_O
Just because lots of experts disagree with you does NOT prove that you  
must be right.
There are a heck of a lot more folk who were told they were wrong -  
and were wrong. Citing an exception only proves the (general) rule.

Whether we are a meritocracy, a democracy, a timocracy or a  
dictatorship (benign or not), your campaign to make contributing to  
Drupal three times harder for everyone is just not getting any traction.
Vast numbers of people already find CVS and patches a heck of an  
obstacle. I've had dozens of probably-OK patches die in the water  
because it there wasn't enough motivation for even one other valid  
developer to help push it through. Requiring a quorum of *10* votes as  
you proposed means that nothing would happen ever.

If it was even conceivable that Drupal contrib became so draconic, it  
would force contributions into the "badlands" (see proposal http://drupal.org/node/307211) 
  and possibly be divisive enough to justify a totally parallel  
repository of 'unvetted but free' code on another site.
I (and many others) don't want to see that happen.

*sigh*
To end on another hopefully constructive suggestion, module voting and  
rating has ALWAYS been discussed and proposed, and is one of the key  
requested features the background of the d.o. redesign. If this comes  
though as providing a top list of recommended or even semi-official  
modules, that is a good thing. But such ranking or classification is  
NOT going to take the form of prohibiting people from contributing new  
innovation. You describe your elaborate voting system as one where not  
enough votes = no commit access. That may be what is turning everyone  
off. Voting for informational purposes, I think we could get behind.  
But making rules that will negatively affect the majority of  
developers and damage the community ... not popular.

It may be possible to rework your proposal in a more practical way -  
but only if it enables the community by shepherding input, not as a  
bully cop that bans input by default.

.dan.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.drupal.org/pipermail/development/attachments/20090310/ed2b8091/attachment.htm