incubator-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "robert burrell donkin" <robertburrelldon...@gmail.com>
Subject Re: Outside view on incubator policy to initial committer list
Date Sat, 07 Oct 2006 08:51:56 GMT
On 10/3/06, Martijn Dashorst <martijn.dashorst@gmail.com> 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: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org


Mime
View raw message