On 10/3/06, Martijn Dashorst <[EMAIL PROTECTED]> wrote:
From the documents I have read on the policy for entering, being inside and graduating from the incubator there is a lot of talk on process, but not a lot of explanation on *why* the process is in place, nor on how things are done.
one of my aims in the documentation revision is to clearly separate policy and process from explanation and discussion. there's a lot of work still needed on the discursive documentation. the short answer is that the process has been created and policy defined by a series of votes.
The first 'gripe' is the uncertainty for existing open source projects that want to join the ASF that their current contributors will be allowed to work on the project at Apache. The documents clearly state that such karma needs to be earned based on merit. It never states that merit earned in the past for the project can and *WILL* be used. This can only be found in heated discussions on this list.
it's important to realise that the democractic nature of the process means that gaurantees are not possible. there is neither a judge nor a jury objectively testing an application against criteria. whilst the incubator retains it's democractic process, policy should not mandate how electors shall vote. but i hope and expect (given the electorate) that their votes would acknowledge existing karma.
The second gripe is the fact that only the Incubator PMC members of the PPMC have binding votes. I think I understand the reasoning for this, but it is not clear how the PMC members will excercise their binding votes. Will they affect the average day-to-day affairs within a community where the mentors have no direct affiliation with? Or is this only a guiding vote, for things such as: - withholding a release when the podling is not considered ready - not granting karma (with good backing reasoning) - not taking in external code bases without the correct grant - etc. The policy should make it clear that the PPMC chairs with the binding votes, only have that executive power to vote on such things regarding process.
apache has PMCs not from a love of bureaucracy but because official committees can take official decisions. apache believes that projects should have autonomy and in delegating decision making to self-organizing communities. if PPMCs are official committees (which IMO isn't too clear ATM) then all PPMCers can cast binding votes. if not then they can't. the stuff listed as process is pretty much the same as a list of stuff that should require an official vote. official decisions by the (P)PPMC should only be taken for matters that require an official decision. for most other things, discussion, lazy consensus or unofficial votes are better approaches. IMHO any project that counts binding official votes for day-to-day matters is most likely unhealthy. the (P)PMC isn't intended to be a oligarchy. i would expect incubator PMCers to start taking an active interest in any podling whose PPMC started acting as such. this probably isn't captured very well in the incubator documentation and need to be.
The third gripe is that graduation has two components: a measurable component (active community, diverse, all legal matters resolved, no violating code, etc) and a non-measurable component (mature enough to be an 'apache' project). Given the sometimes extreme views expressed here (a nice read though :-), it is for an existing project really hard to trust such a process when you already have a healthy community which is basically put on hold whilst incubating, if you follow the incubator policy (and some egos) to the letter.
any process can be subverted. apache trusts communities not process. decisions are taken in public before the court of public opinion. so, look at the people, not the process. the incubator PMC is almost entirely composed of apache members. the members elect the board and are the ultimate authority at apache. if a community does not trust the apache membership then it cannot trust apache and needs to create it's own organisation. members are elected by the existing membership and typically have many years of open source experience. i estimate that the incubator PMC collectively has well over 200 years of collective open source experience. if the process is getting in the way and results in a community having to put itself on hold, then it needs to be improved. if anyone has any specific ideas, pull together a proposal to change the process. <snip>
For existing projects it is a very hard decision to enter the incubator and the uncertain process until graduation. As the ASF you (we I should say) really have to put yourself into the shoes and clothes of the small community that is about to join a rollercoaster with unknown process, procedures, laws and above all, unwritten rules of conduct. It is quite something when a team has worked for 2 years two or three jobs worth of free time on a project and it 'hands it over to the incubator'. Scary poo indeed.
apache is a rollercoaster. delegation is scary. democracy is scary. if the incubator were to mandate rules of conduct and laws for podlings then it would be acting against it's own principles. when a project graduates it needs to be capable of both self-governance and acting in accordance with the principles of open development. in the vast majority of cases, this means change and growth. IMO the major problem is not lack of policy and rules but lack of documented guidelines. - robert --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
