Re: [PMC:VOTE] PMC Voting Process
Leo Simons <[email protected]> Fri, 10 Jan 2003 12:44:54 +0100
| Newsgroups | gmane.comp.jakarta.avalon.apps.devel,gmane.comp.jakarta.avalon.devel |
|---|---|
| Message-ID | <[email protected]> |
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