Leo Simons wrote:
Stephen McConnell wrote:Leo Simons wrote:I hereby propose we adopt the text below as a our voting guidelines, add these guidelines to the avalon project documentation, to completely replace the current (invalid) procedures and policies which were voted upon under the thread "[VOTE] PMC Voting Policies and Procedures" on the avalon pmc list.
I believe the proposal lays down in clear simple wording the actual de-facto practices followed.
I volunteer to administer the vote, add up the results and notify the community, and put the document up on the website if it is accepted (ie do as described in the proposed text).
Note that although this is a PMC vote everyone is welcome to comment.
PMC members, please cast your votes (on the avalon development list).
here's mine: +1.And here is my -1 :-)
I forgot to mention for people wondering: this counts as a "qualified majority vote", ie 2/3s of votes should be +1. Steve's -1 is not a veto. (And he has the option to change it for at least a week!)
We have voted on something that describes a set of procedures. The vote has passed and has established the framework for how we modify those procedures. Sure you can propose a replacement of those procedures (as opposed to moving forward to address a couple of points raised at the end of last year). What is import to remember is that the procedures that we have adopted are very explicit about what we think things are (right or wrong - they correctly represented what we thought was right). Through that process and explicit description Greg picked up on our missrenterpritation of the defintion of the chair. He also picked up an issue concerning an apparent missinterpritation of the chairs rights - which in fact turn out to be an issue to do with the Board minutes - identifiable because both out procedures and the board procedures are using wording that is specific about terms.
All true.Yes - placing a set of procedures into natural langue makes it easier to ready on a Sunday afternoon with a class a Chablis - but when something becomes a point of issue (forget about legal - just think about us and Avalon when we an order of magnitude bigger than today) then your will be really grateful for text that is explict about definitions and processes.
I think the text I propose is perfectly explicit about "processes". If you do not, could you be more specific?
Sure - but I'll respond to a couple of your points first.
While that text may be less explicit about "definitions", it is hence also not in conflict with definitions made elsewhere. I am questioning our ability to provide "conflictless explicit definitions", in fact I doubt it is possible at all.
This is something I disgree with - there are two aspects here - one is to ensure consitency with framework within thich the PMC has been established - the second it to establish the set of procudures that give us a fair, representative, a autitable framework for project supervision.
The first aspect of consitency can be achieved through collectively becomming more familiar and wizer about the framework we are established under, while leverage the knowledge and expertise of those already familiar (e.g Greg, Sam, ...). The second aspect is something concerning us as community - establishing and putting in place the process we want that reflect our idears of what we want. These at not defined by ASF - they are the result of our deliberation, our conclusion, our priorities.
Key points:
* getting Greg to jump on the wording of something is positive stuff
because
- it shows that there is someone on the board that is
watching over out shoulder
- it provides all of us with more insite to what are dealing
with and what the roles and responsibilities are
* don't be afraid of doing something different
- ASF through the Board has established the Avalon PMC
with a mandate to put in place the policies it needs
- ASF does not provide the operation framework that we
are addressing .. i.e. there is not a ASF fallback
position .. our procedures are not specilizations
of something in ASF - they are create by the members,
for our community
I am also sincerely questioning the need for explicit definition of both definition and process.
And this is something we can work on. I also think that current version can be improved in terms of readability. I also think that it must maintain its structural integrity. To be frank, I quite like your text (some parts more than others) - I'll less comfortable with Berin's revision but I havn't actually put my finger on the specific difference aside from the impression that Berin's version appears to me to be generalizing beyond the PMC voting process. But anyway - what I would prefer is something more structured that what your proposing, and something easier to work with that what we have currently.
Here's my reasoning: what we need is clarity and transparency with regard to our process (to avoid conflict or be able to resolve it and to explain to outsiders/newcomers), and I really do believe simply worded prose is more effective in that regard than formally worded legalese, simply because formal wording confuses many people, thus removing clarity and transparency, replacing it with confusion.
I agreee and disagreee ( sorry for being difficult ) - I think it is fair to say that this is a double edged sword. Both approach have their benefits (even here) which is why I was very much in favour of seeing the two as part of the procedures documentation - the formal facilitated by a narative of how it works. I still think that this is the best target and within that scope I would much prefer that we enhance and improve the structural version as described above and back this up with a good natative description.
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 (and I also confident that Greg and I have different backgrounds as well - reflecting my involvement in several organizations that make what we doing look simplistic in comparisom). :-) What is in place is not dissimilar in style to to other policy and procedure documents that are publically available. I'm not suggesting this validates what we have - just saying that what we have is within "normal" scope relative to my own experience.
This does not negate the need and utility of supporting explanitory text - but the latter is not equivalent to the former.
I believe it should be exactly the same. Why do you not?
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.
Wording such as "invalid" is missleading - heck, based on this guideline the last board meeting of ASF is invalid - should be conssider that to be null and void as well ?
I believe the proper thing to do is to replace or redo the vital points of that board meeting so that the argument becomes irrelevant,
Agreed.
ie to provide a rectification.
Yep.
I believe that is the board's plan, it's mine too.
No quite - in the case of the board - they will correct the point in question.
Your introducing a replacement which does not address all of the same points - but this isn't immediately clear. If you take a step back and look at what your proposing you will find about 60% is very similar. About 20% is familiar and about 10% is new. Now, if your keeping a running total here you will have noticed that about 10% is missing. The benefit of the structural approach is that you are forced to be much more diligent about what it is your changing and why those changes are being proposed. I may happen to agree with the 10% elimination - but I won't agree on the basic on replace "Chapter X" with "Chaper Y". It much better to talk about "defintion X" or "article Y" because these things are small and concrete.
Not very important for the discussion though.
But it is - the board with address the specific issue - they will not rewite the entire minutes.
And I do not need to know because I'm not on the board :D
However, I'll happily take back my use of the word "invalid" as it doesn't matter that much...I'd like to hereby rectify something: my use of the word "invalid" in my previous e-mail on this subject was invalid and it should be disregarded.
Hang on - does "invalidity of an invalidity" constitute a double nagative? :-)
I don't think so. If you wnat make changes - an yes, some changes are needed - then I would like suggest that we work within the scope of what has been established both in context and process.
I think the proposed text is perfectly in scope of what has been established in context and process, so I think I'm following up with your suggestion.
The prime reason you gave previously was the legal argument, which I took for granted (IANAL), but one thing I understood from Greg's answers to some of my questions is that that argument is most likely moot. Based on that I re-evaluated the need for formalism, and came to the conclusion that
a) it is totally unneeded and has negative side effects (see above);
Let's get something absolutely straight here - we are putting in place the machinery under which people can be abused. The words we use will be very important - I don't give two bits about Greg option on this - 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 am going to make absolute sure that nobody will be subject to that kind of scenario in Avalon. That negative-side-effect of process abuse is much more real and the negativity of being responsible and facing the implications of worst case scenario. Addressing this means being rigerouse in our definitions - our responsibilities as PMC members, our responsibilities to the community and committers, and the limitation and scoping of the privaliges we grant to ourselves.
b) making some changes to the text I whipped up earlier while drafting the original proposal, and then proposing that as a replacement was easier than making changes to the formal thing (for me and I suspect the majority of people), and has added positive benefit.
I'm not suprised - and I like your text - but if the shit-hits-the-fan (please excuse the appropriate but vulgur expression) - well, in that context I like the text we have a whole lot better.
Steve, it's got nothing to do with our differing taste in wine,
What! Your don't like a crisp Chabli while sitting on deck chair on a warm summer afternoon!
but I think you like formalism and process to much for your own or the common good :)
I don't like saying this - but you underestimating the downside.
Zutt - it's the end of the email and I don't want to end on a tone like that.
Take all of this email as a reminder that things can get into friction - that PMC members are going to presented with dificult scenarios. The choices that the PMC will have, the legal protection afforded (withing and outside of ASF), the framework for defintative closure on issues, and the protection the PMC provides to the members of our community will be directly related to the procedures we put in place.
I recognize that I'm probably the end-point of one extreme - and my objective here is to bring you a closer to understanding and appreciating the full implications of our decisions.
Whatever - let me know you think.
:-)
Cheers, Steve.
--
Stephen J. McConnell
mailto:[EMAIL PROTECTED]
http://www.osm.net
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
