avalon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Leo Simons <leosim...@apache.org>
Subject Re: [PMC:VOTE] PMC Voting Process
Date Fri, 10 Jan 2003 11:44:54 GMT
Stephen McConnell wrote:
>> In Greg's words: "Think about any other company on the planet. Do they 
>> codify their operations to [the level of the current process document 
>> as voted and accepted upon in december]? Nope. Not at all."
> 
> If your really interested I can give you several examples

yeah, I know...I've been involved with the UN for the past six months. 
Guess what: they don't get much done. People who like actually "doing 
stuff" often leave the UN and then sell them stuff.

> In practice it doesn't work unless (a) you like writing long documents, 
> or (b) your ok with impliciations being open to a variety of 
> interpritations.  If you make the assumption that these procedures will 
> be abused (and I am making that assumption) - you will move towards a 
> more structural framework - one that is abuse resistant.

AHAH! Drop that assumption _immediately_, will you!

You should make the assumption that all people that have to use our 
procedure trust each other and share the same spirit (ie the "apache 
way"). When that assumption fails the safety net we have is the ASF 
bylaws and the entities it defines. We do not need to lay down a safety 
net in the form of procedure. We just need to point at it.

Entities that could perhaps want to abuse procedure (which you're not 
required to trust) are outside people (ie the Evil Empire), but the 
point is that lawyers will then step right over the procedure and look 
at actual actions.

I do not want "abuse resistant" as an argument for setting in place 
formal policy. We're not the UN, we're an open source project based on 
trust and cooperation. I want "based on trust" as an argument for 
setting in place informal policy.

> Let's get something absolutely straight here - we are putting in place 
> the machinery under which people can be abused.

no. This is not machinery, it is guideline. There is an implicit 
assumption that people who will try and abuse guideline will be 
corrected by peers or "the next higher entity" like the chair, board, or 
the collective ASF members.

> if 
> your the subject of process abuse - your will spend time going over 
> policy and proceures and getting that stuff into your head in detail 
> (and you will not stop at Avalon PMC procedures - you will go through 
> entire Board minutes for the last couple of years).  The standing 
> policies and procedures in ASF and Jakarta are terrible when addressing 
> heavy-weight issue leading to the worst case scenario of a PMC that 
> connot act and connot close on an issue because it lacks the procedural 
> framework.

I couldn't disagree more. If things really go badly wrong, you should 
safely assume the ASF members will request (insist) that the ASF board 
takes action, who will likely delegate to the appropriate officer, who 
in the case of a disfunctional PMC would _not_ delegate to the PMC. If 
you trust this mechanism you do not need to define procedure, just policy.

This "standing ASF policy and procedure" might need more transparency, 
but otherwise it works real well.

> Whatever - let me know you think.

You're not trusting your peers and existing governing bodies to handle 
abuse or "policy failure", which is bad. You need to talk about that to 
one or more of the "ASF senior members", who are a lot better at 
explaining it than me.

I'm gonna end with an example:

Suppose you and I (2 PMC members) get so worked up about this (or any 
other) issue that I'm threathening to abuse "procedure" against you. It 
is unlikely that the other PMC peeps won't jump in to find a solution. 
If not though, it is highly unlikely that then the ASF officer will 
overrule all policy and procedure and do what he/she feels is right. In 
the unlikely event that goes wrong as well we will see the board step 
in. In the unlikely event that goes wrong as well we will see the 
collective ASF members step in. In the unlikely event that goes wrong as 
well the ASF has failed and there's a problem with the organisational 
system the ASF uses, and hence with the organisational system most 
not-for-profit organisations use.

You need to trust that all of the above is not likely to happen. We're 
not going to be in conflict up to the point where threats will be 
issued, and I won't abuse procedure, because I'm a proven nice guy who 
follows the "apache spirit".
Okay, so there's a remote possibility that this will indeed happen. But 
there's a multi-leveled elaborate safety net in place, and there's so 
many "highly unlikelies" in the examples that the net chance of things 
falling all the way through the safety net is zero.

Summary
-------
It is vital that you see that our "process" and "policy" are and should 
be based on *trust*, making their formality (and mostly actual 
application, too) 99% unneccessary. There's lots of Bad Evil Empires, 
but you must *trust* that they are external to the ASF. Even if they 
were to be internal, apache already has lots of safety mechanisms in 
place to deal with that, you should *trust* that those are effective. Us 
putting in place formal procedure is thus totally unneccessary. Since it 
also has detrimental side effects, we shouldn't.

keyword: *trust* as opposed to "abuse".

cheers,

- Leo



--
To unsubscribe, e-mail:   <mailto:avalon-dev-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:avalon-dev-help@jakarta.apache.org>


Mime
View raw message