Roy T. Fielding wrote: ...
The ability to make ASF decisions starts with the board and is delegated to officers and their associated committees. Anyone casting binding votes (meaning votes that are counted toward making a decision) must be listed as a member of the committee on which they are voting, even if their votes are limited to a subcommittee. Therefore, my preference is for a fluid structure of incubating subprojects wherein every voter is listed as being in one or more core groups and the entire set of voters is listed as the incubator pmc.
Having had basically all opinions about this in the past years, and having been on diverse projects, I have come to the conclusion that I basically agree.
In particular, the Incubator PMC has been since the start an "umbrella PMC", similar to what Jakarta and XML, mainly because it cannot easily be made in a different way. This has made me see the shortcoming of the approach in clearer detail.
These months of incubations have showed us in clear evidence some basic facts that cannot be forgotten. The funny thing is that it's what we all know, but applied to the incubator it was hard to understand.
1 - oversight must be done by the as many people as possible, just
like more eyes see more bugs -> more mentors
2 - the "management" of a project must be done by those that run
the project day by day -> PMC==committers
3 - it's ok to create "subprojects" in a project as long as the
project remains united as one in decision making -> core groupsLet's make for example Cocoon, which can IMHO take advantage right now of this way of doing things.
Cocoon has already a set of committers that are all on the PMC.
There are two projects with close ties to Cocoon, that are Forrest and Lenya, Forrest under XML and Lenya in Incubation. Let's assume that Forrest goes under Cocoon and that Lenya exits incubation.
Cocoon as a project could as well consist of all long-stating committers of these codebases, and take all decisions together. This is already in part a fact, as the Cocoon PMC has started to vote a Lenya release as they feel part of the project, and Cocoon committers have access to Forrest.
Then there would be three core groups, one for Cocoon, one for Lenya and one for Forrest. There would this be a single project, a single PMC, and just a partitioning of competence on parts of code.
There is only one thing that would *really* change and that has not been done till now.
Committers could be given commit access long before having project member status, and would thus be able to commit but not vote. This makes it possible to keep a high bar for membership of the project but a lower bar for committing.
Is this possible/wanted?
I am aware that this would mean incubating projects would be able to vote themselves out of incubation. I think that if such a project had their shit together to the extent that they could run such a vote and get it past the majority of incubator members, then they no longer need to be incubated.
This is a possibility, that is ok for me.
Another possibility would be to define in the rules that the incubating project cannot voe itself out.
--
Nicola Ken Barozzi [EMAIL PROTECTED]
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
------------------------------------------------------------------------------------------------------------------------------------------ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
