Marcel, I don't know if you've noticed but you haven't managed to visibly convince anyone your solution is a good one. Well yes i do have noticed. Apart from 'don't like it' and 'messes with our ways' i have not heard any sound counter arguments though, but that might well be enough of an argument by itself in such a community project.
Especially not anyone who will bother to try and implement it. Well if we all wanted to, we could make it. Easily: it's just a matter of breaking habits, and not even that drastically. Btw it works for other projects (linux, wine).
On the contrary, you have a whole host of people saying it isn't a good idea and giving reasons why. Like 'nah dont like'. (Almost) noone even picked my arguments in favor of such a process, or tried to think up how it could be made to work, or even propose something entirely different.
These people (not me mind you) are the dedicated volunteers that do actually work hard to implement solutions to Drupals problems, and are each in their own way personally responsible for the current success of Drupal today. Well of course but i really missed some voices from those high-profile developers. BTW nothing would change for them, especially no increase in work-load.
They do understand the background and developer culture of the community, and the reasons behind Drupals success. So that implies i don't do that, which is wrong. But to truly achieve excellence, sometimes you have to trade in a bad habit (casual developers committing code to the central repository) for a bitter pill (having all code not from already proven drupal master minds undergo a transparent quality screening) for long term profit (cure the contrib). It's simply people not liking bitter pills until they suffer severely from their sickness.. totally human.
Don't take this personally Course not, but i would have hoped for some support. Without any community backing surely my idea does sound silly.
but your idea and justifications for it have an air of either ivory tower academia or heavyweight process driven enterprise thinking about them. Well it's not that my proposal is totally unrealistic. Only because no one is supporting it does it become so. Would Dries or Angela have proposed it, everybody and his dog would be up in flames of enthusiasm and surely consider it the right way to go.
Neither of which have a very good track record of actually getting things done in a volunteer driven open source community where inspiration and enthusiasm is the biggest driver behind doing anything. Who is trying to stop that. By preventing bull sh1t code from being committed to the official contrib? C'mon! We could easily set up a testing repository, set up a drupal-patches mailing list and nice up the issue tracker to facilitate more code centric work on stuff.
The rate of progress in both Drupal and the supporting infrastructure over that time has been staggering. Yes, true. So with all that gained, how are we possibly going to loose it through tighter quality management?
It's a tall order claiming that the environment or culture that achieved that success is broken - especially since people have come along and announced that plenty of times in the past. I didn't say it's broken, it just allows unlucky stuff to happen. Modifying it a bit could solve the problem for good. Not that this step is _required_, but maybe we as a *software* project would _profit_ from it.
Why should that claim be correct now, when it has been shown to be false in the past? A major core redesign is the best time to make these modifications. Why i proposed these changes i hope i have explained sufficiently.
Your proposal to have every D7 contrib commit vetted by some sort of vote would just drive away the very enthusiasm and inspiration that drew in all the newbie contrib developers that grew up into veteran developers and core contributers (and that would be the single best way to kill Drupal). Ahem, no. Why would anyone insist on committing every mind fart to the official drupal repository? Heck as stated above, how hard is it to have a staging branch? The main motivation to even waste my time in this discussion was to find a solution to the problems mentioned in the original posting: - modules spamming the watchdog table with E_ALL warnings - modules ignoring the style/documentation guide lines - applied insane programming(TM) techniques - undescriptive module names - duplication (partial feature overlap with existing modules). If anyone has a more viable solution at hand, i'm more than willing to surrender my effort to their proposal. Right now all i've heard is votes for natural selection. Surely that is one approach to it, but at least not my favorite. Also, almost every possible use case is covered by one or the other D6 module, making that 'no more innovation' argument really not that convincing. What is the point of producing D7 at all? Restructuring! How is that case invalid for non-core modules, simply don't see it. Furthermore, simply don't like the fact that individuals hold the keys to modules. The linux kernel f.e. handles this very differently: contributors get mentioned in the file header. Really, the linux approach of development is what i think drupal should hand pick some points from.
I certainly wouldn't bother releasing any Drupal 7 modules if that were the case. You must be kidding. And for a lot of modules (eg my own), they simply don't have a user base capable of evaluating the quality of the commit Code voting for developers only of course - sure all this needs implementing. Where's a will, there's a way.
In nearly all cases, the people doing the voting will know far less about coding or the internals of the module than the author. It won't change much in terms of code quality - it will just add frustration to everyones experience. Noone wants that, not even crazy me. But my belief still is: if we really want to find a way to improve the process, we can do it. If i stand alone, this is not a fight i'll waste my blood on.
BTW, i really wished i had the time to code all the stuff i'd like to, but obligations (you know.. school, work and stuff *g) shrink my visions to small compact pressed clumps that lay around. It would simply need some outside support to inflate them again, but convincing people to support something unknown nowadays doesn't seem to be too easy. Ah well.. back to work, the profane. regards -- "Obstacles are those frightful things you see when you take your eyes off your goal." -- Henry Ford (1863-1947) Change the world! Vote: http://hfopi.org/vote-future