On 20-Apr-09, at 2:20 PM, Earl Miles wrote:
Angela Byron wrote:
On 20-Apr-09, at 2:04 PM, Earl Miles wrote:
Angela Byron wrote:
We have this kind of decentralized development model, where one or two people are solely responsible for code with basically zero peer review. It's called contrib. And it's notoriously filled with sub-standard, shoddily documented code that needs to be closely inspected by individual site maintainers before being deployed on any serious production sites.
I stop following your argument here. The only way this argument holds up is that if *all* of contrib is substandard crap. It is not. There is a level of contrib that is above that, and there is a reason those particular pieces of contrib are above that. Chew on that. And this level contrib is the kind that has enough users so that peer reviews occur naturally, or at the very least peer QA after the fact. As we've noted, peer review and peer QA is *not* happening with these core subsystems, which makes it a lot closer to the "darker, scarier" contrib. So I'm not sure what there is to chew on. :)
Perhaps you attribute more peer review and QA to some of these modules than is truly there. I don't think there is very much. There is peer review pretty much after the fact; that's the review that said "it's ok to use this module."
But the responsibility of the committer is what made that happen in the first place. I personally believe that anyone who is given the right to commit directly to Drupal core is going to think several times longer before committing something than he or she would to contrib. Obviously this varies based on personality, but the suggestion that adding more committers to core will turn core into contrib does not work for me.
I guess I view it as the following simple pseudo-query, assuming an active maintainer: $relative_project_quality = db_result(db_query('SELECT (number of active participants in issues, filtering out '+1 subscribe') FROM {the_issue_queue} WHERE project = %d', $project->nid)). On a project such as Views, with a very high number, $relative_project_quality will be very high. On a project such as any of mine ;) with a very low number, code quality will be much lower. This is not because I'm a horrible coder or that I'm not conscientious about my work or that I don't care about quality. It's because there's no body of diverse people chiming in to say "actually that will break my use case and here's why," or "I actually find that a bit hard to grasp; what if we did it this way instead?" There's no one looking over my shoulder for obvious brain-os that I miss in the height of my caffeine-powered coding rush. And furthermore, even if I *wanted* to bounce ideas off of more experienced developers or peers (which I do!), I quite simply can't; they don't have expertise in this space. So I do what most contributed module authors do, which is muddle through and try my best. Now, if you do the above query with project = 3060, you will get an extremely healthy project. And by having only a small number of committers, through whom *all* changes are run, this number holds true. However, If we move to a subsystem maintainer committing model, we need to change that query for the Drupal project so that it's WHERE project_component = %d. And if you do /that/, you do not get a rosy Views-esque picture of things like the menu system. You get a very worst-case scenario picture of webchick-maintained contributed modules. So my argument is quite simply that without building this number much higher for each of the underlying subsystems, I don't see what choice core has *but* to turn into the dark, scary kind of contrib by adding more committers to the mix. -Angie