Leo Sutic wrote:
All,
let's have another go at it. I think all of us agree as to what a vote should be, and I think that there is consensus about 90%
of this.
Yep.
So, let's go through everything that's been put on the table,
see where we agree (90% of everything) and see if the remaining
10% are issues that can be resolved.
Sound good.
The following email is an evolution of the "free and easy" version that reduces soem problems through not address the problem fallback (see notes below for an explination of what I mean).-oOo- Reading through the proposals, I can only say that they describe the same process, although in different words. For the record, here are two of them: Leo Simons's: http://marc.theaimsgroup.com/?l=avalon-apps-dev&m=104213058521206&w=2
http://marc.theaimsgroup.com/?l=avalon-dev&m=104270697629068&w=2
The definative version from Steve's perspective is the currently adopted P&P -Stephen's: http://marc.theaimsgroup.com/?l=avalon-dev&m=103924111629118&w=2
http://jakarta.apache.org/avalon/pmc/PMC-VOTING-PROCEDURES.txt
Unfortunately I have not been able to find Berin's text at
marc.theaimsgroup.com. Berin, could you provide a link?
Also, I hop I have the latest versions of both
Basically, a vote is this, from a voter's perspective:
1. A thread marked [VOTE] pops up. I have seven days to cast my vote.
2. I cast the vote (+1, +0, -0, -1).
3. When the voting period is over, a thread marked [VOTE-RESULT] (or somesuch) will tell me how it went (accepted, rejected).
I think there is consensus on the above process.
Yes.
-oOo-
THE ISSUES
I see no issues other than the question of how the process is
described. For the purpose of being able to refer to them,
I'll refer to the approaches as "strict" or "layman", with Stephen's
being the strict version, and Leo's being the layman version. I
don't think anyone will be confused by the labels.
It's a safe bet. :-)
LAYMAN VERSION
The layman version emphasizes a "fast and loose" approach. Many
terms and concepts are not defined, instead it is assumed that
the reader/voter already understands them, and that the voter's
understanding of the terms are in line with - for want of a better
description - the collective mind of Avalon. The goal is that the
process should be easily and intuitively graspable by anyone,
and that one should not get bogged down in details.
STRICT VERSION
The strict version emphasizes correctness and precision. The goal is
that the voting process should be completely described, and that
a reader should not have to have access to the collective mind of
Avalon in order to understand how a vote happens. It is also designed
to handle the case where someone's understanding isn't in line
with Avalon - to put it simply, any disagreements on voting process
should be solved by reading the text, thus avoiding costly
arguments on how the vote should be done that often bloom into
somewhat unpleasant disagreements.
-oOo-
OK, so can these two be reconciled? I think so. But before I start
with that, I'd like to pose a few questions:
1. Do I have the latest documents referred to in the beginning?
The above links should provide a good starting point.
Not so much argument - more a questions of finding the right mix. My imprssions is that there are no rigid positions - its much more a case of being collectively confident that we are putting together the right thing.
2. Is my understanding that the actual process described by the
proposals are equivalent correct? That is, are we only arguing over how the process is written down, or is there any disagreement as to the process itself?
3. Am I correct in my description of the goal of the layman version?
I belive so.
4. Am I correct in my description of the goal of the strict version?
Especially, the assertion that the purpose of the strict-ness
is to be able to resolve disagreements by looking in the text?
Yes.
-oOo-Excellent.
Finally, a few notes:
If you let me, I intend to run this discussion as I ran the
"Context Consensus" thread(s). That means:
+ Regular summaries of all viewpoints
+ A long period where we keep this as a regular thread,
a while as a proposal, and finally a vote that should be nothing
more than a formality.
Here is my soapbox pitch - two main things I'm concerned about
(a) Both Leo's and Berin's text took the position that if anything was wrong with what we put in place - the auto fallback is ASF procedures - I see faults in this - firstly - there are no ASF fallback procedure - and secondly - the very notion of falling back implies a lack of confidence in our own procedures. At the end of the day the _only_ fallback is the board. Our responsibility is to get this right so that there is not need to consider a fallback - and to go beyond that a state as such - i.e. an Avalon PMC decision is definitive - subject only to a Board decision to overrule.
(b) The second concern is something more personal and I don't have immediate recommendations - but the issue is something I imagine is of concern to Pete just as it is to me. The issue is about "closure". Ok, a while back there was some flack between Pete and myself. There were accusations made and stuff thrown about - problem was (and remains) that the process was never closed. It's one of the reasons why I'm outwardly hostile relative to Pete (Pete has never withdrawn his accusation and no authority has recognized or endorsed my position) - so it doesn't matter what anyone says - the past is the present. Accusation have been made but have not been closed (positively or negatively) by the Jakarta PMC or the Board. I'm bringing this up because we need to make sure that we don't make the same mistakes within the scope of the Avalon PMC. If we are faced with a similar situation - we have a responsibility to close issues that are put before us. I recognize that this maybe something that needs to be dealt with after sorting out basic voting policies - but its something I consider to be very important and central to the notion of the PMC acting responsibly in the face of difficult situations.
In effect - this is the PMC taking responsibility for being responsible.
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]>
