Hallo, i agree very much to all your posting in the last days (did not check older ones ;-) ) i suggested in the attached mail to change the decision making process in the drupal community. Some people agreed and i want to start a group (if it not exists) that creates a proposal for the decision making process. Are you willing to join such a group on groups.drupal.org? Best Thomas Zahreddin Am Mittwoch, den 11.03.2009, 11:12 +0100 schrieb Marcel Partap:
Except that those high-profile developers would need to troll through contrib to vote on stuff. Would not. On the contrary, all people writing Drupal code could handle all Drupal non-core code as a collective.
Perhaps the lack of community backing is a sign that the idea really is silly? Well my professor for the lecture 'quality management' came up with several examples where there was absolutely no support for ordered quality assurance procedures until something bad happened, at which point someone from the institute went in for counseling and after leaving everybody at the company highly supported the introduction of a structured approach to quality management on the process. It may seem to increase the amount of work needed at first, but really in the end it does the opposite. So no - i still don't think the idea is silly, as i understand it. However many times my points have been misinterpreted so maybe i just didn't make myself clear in the first place. Shame on me.
If you want a "crowdsourced" approach to module maintenance, well, the crowd is right now voting against your idea in droves. That should tell you something. Yeah, but nothing about the viability of the idea of a different approach to non-core code. And opinions change with the tides..
You can already get email notifications of every single post to the issue queue if you want them. Yet another mailing list for that would be a big step backward. Well maybe all the supporting infrastructure already in place just isn't the best it could be. Furthermore personally i still see huge benefit in a single drupal-patches mailing list that would allow me to take part in deciding where the code goes in a different way than filing reports - why let wrong code get in the first place.
Really, the linux approach of development is what i think drupal should hand pick some points from. Once again, as others have pointed out, you're mapping to the Linux module, um, wrong. Drupal core is to Linux kernel as Views is to KDE. How can you tell me the analogy i chose is wrong? The point is not the different layers of software but the development process. You could also compare the SLOC of codes, or the amount of code contributors, or the average color of the project's bike shed.
Does KDE not get to commit something unless kernel devs sign off on it? Of course not, that would be insane. That point is so totally void.
But it would get rid of that pesky "Do I use Gnome or KDE?" question. Duplication is just wasted effort, right? Like i'm getting myself involved in another flame war, nice try.
The vast majority of contrib modules have exactly one person who knows the code at all Which is a *problem* that a different development model would address.
, much less well enough to be able to vet and vote intelligently on a patch. So it would fall to those "high level" devs to pick up the slack so that things could even get committed. We're kinda busy already. :-) As long as you don't _really try to imagine_ how it could work you're not going to understand it anyways.
I think it should be apparent by now that you do stand alone on this issue. Well it is apparent to me that noone brought up any compelling arguments against it (besides 'dont like'). Some people however voiced their annoyance about the current situation - especially with module duplication - which has not been addressed adequately by anyone. Also up to now, the only approach to tackle the other existing real problem of overloaded, unresponsive and uncooperative module maintainers which hold the sole keys is mine. No alternative concept (except the new project queue idea, which has been already mentioned to not catch many of the cases) has been proposed. Yet if nothing is done, shit will just again hit the fan.
Once again, the fact that no one else supports this proposal should tell you something about it. Yes, that it isn't supported, which basically cancels it. That does not imply however it would not work, nor that it would not improve overall code quality, avoid module duplication and on the long run prove to be a scalable development process.
The people i'd really like to have heard an opinion of are people like Dries, Angela and the maintainers of overly complex modules (CCK and Views mainly) however. But now the jury has made up their mind it is too late for the idea anyways. regards, marcel.