On Monday 09 March 2009 5:22:02 pm Marcel Partap wrote:
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.
Except that those high-profile developers would need to troll through contrib to vote on stuff.
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.
Perhaps the lack of community backing is a sign that the idea really is silly? 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.
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.
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.
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.
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. Does KDE not get to commit something unless kernel devs sign off on it? Of course not, that would be insane. But it would get rid of that pesky "Do I use Gnome or KDE?" question. Duplication is just wasted effort, right?
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.
The vast majority of contrib modules have exactly one person who knows the code at all, 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. :-)
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.
I think it should be apparent by now that you do stand alone on this issue.
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
Convincing people to support something unknown shouldn't be easy. It should have to prove itself. It can happen, but it takes time and generally only happens if the idea really does have merit. The development process for D7 core has changed considerably, for the better, because we only made process changes that made sense to those involved and that reduced workload rather than increasing it. Once again, the fact that no one else supports this proposal should tell you something about it. -- Larry Garfield larry@garfieldtech.com