I think that this isn't a good idea. The main reason for a [php-src] > vs. [php-doc et al.] distinction is that the php-src guys will be the > ones maintaining the code. (At least from what I heard this is the > main point.)
I have more argument than that, maybe there are others also: - The core devs usually know the internal parts better than the others contributors, so they can weight the changes better on the technical parts (opening a can of worms...). - The core devs are usually the ones who have to maintain the code, after the happy RFC proposer disappears after having his/her feature included (phar would be a fine example as I heard). - The core devs are usually the "stakeholders" of the project, if it turns out, that it was a bad idea to add feature X, people won't check the wiki and blame the original RFC author, or the Yesmen, the will blame "PHP" and mostly the core devs. - The active core devs are usually contributing to the project since years or decades, I think that the average experience/"lifespan" of a core-dev is longer than for the other roles. This usually means two things: more experience, and higher chances that they will here to blame, when the shit hits the fan, so they tend to be somehow more conservative than the average people from other groups. So I think that being a core devs is somewhat bigger responsibility than the other roles (and I don't say that other roles are easier or less important) and I personally think that it would be a bad idea(and maybe even unfair) to put them into a situation where they would have the minority of the total votes. Just my two cents. -- Ferenc Kovács @Tyr43l - http://tyrael.hu
