You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@avalon.apache.org by Leo Sutic <le...@inspireinfrastructure.com> on 2003/01/17 22:03:07 UTC
PMC Voting Process
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.
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.
-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
Stephen's:
http://marc.theaimsgroup.com/?l=avalon-dev&m=103924111629118&w=2
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.
-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.
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?
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?
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?
-oOo-
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.
/LS
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: PMC Voting Process
Posted by Leo Simons <le...@apache.org>.
gstein@apache.org wrote:
<snip/>
> Get past this. Move on and work with the code. If and when a problem comes
> up, then it can be solved. There isn't a need to worry about it right now.
> There is *nothing* that is unsolvable, and having "rules" ahead of time
> will probably not change things one way or another.
<snip/>
> "rules" are simply a description of existing behavior rather than a
> proscription of future behavior.
Leo,
I totally agree with what Greg says here (and with the other stuff too,
but the above captures the essence for me). What bothers me is that we
should indeed not attempt to "proscribe future behavior". To me, the
strict version carries such a 'tone', probably as much due to recent
discussion as due to the actual text.
cheers,
- LSD
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: PMC Voting Process
Posted by gs...@apache.org.
In article <3E...@apache.org>, "Stephen McConnell"
<mc...@apache.org> wrote:
>...
> (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.
There is no fallback. The PMC Chair is an officer of the corporation. The
PMC is a group of people to assist in the work of the ASF, nominally under
the direction of the Chair. If the PMC (and more precisely, the Chair)
makes a decision, then it is DONE. The Chair has full authority to act on
behalf of the ASF within the guidelines that the Board has provided to
that person.
If the Chair does something, then it sticks. There are only two ways
"out": one is if it can be shown they are not acting within the capacity
the Board outlined for that officer. For example, the Chair goes and
deletes the jakarta-commons archive. That is out of scope. Deleting the
avalon archive? In scope. Bad, but in scope.
The second out is for the Board to make changes.
I think you guys are misunderstanding the role of the Chair and the PMC
here. The "rules" that you set up are simply a mechanism that the Chair
sets up to define how the PMC will get the work done. But it doesn't have
any real binding as far as the ASF is concerned. They are very internal.
And the Chair is quite a bit "larger" than you're thinking about. The
rules could simply be "give me input, and I'll decide everything." Sort of
a benevolent dictator. Of course, the ASF community and the Board would
prefer a consensus-based approach, but that is only set up in the manner
prescribed by the Chair.
I've said it before, and I'll try to reiterate. The formalism at the ASF
mostly exists at the Board level and between it and the ASF officers (the
PMC chairs, primarily). Most of the formality that we have to deal with is
simply because we are a non-profit, public charity and have to obey
certain rules. At the PMC level and below, informality is perfectly fine.
The need for "voting rules" exist simply as an easy way to gauge the
consensus, when it isn't readily apparent.
> (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,
Don't look to the Board for closure. I might even say that the PMC doesn't
have to deal with closure.
What *is* important, is the prevention of further problems. Part of the
reason that Avalon was voted in as a PMC is to provide a better and
"closer" structure to the problem, than the Jakarta PMC was able to
provide. The Avalon PMC can watch over the community and can step in when
problems arise.
>...
> 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.
Why is a "voting policy" so hard? Copy
httpd.apache.org/dev/guidelines.html or the Jakarta guidelines or
something, and leave it at that. What more is needed here?
Get past this. Move on and work with the code. If and when a problem comes
up, then it can be solved. There isn't a need to worry about it right now.
There is *nothing* that is unsolvable, and having "rules" ahead of time
will probably not change things one way or another. It isn't like people
sit around coding with the rules stuck to their monitor. Or that they
consult them before posting to the list. Or that they read the minutae
before committing. For the most part, they should be a completely
invisible item that new committers should read a few times until they are
familiar with them. But usually, the new committer will probably just go
"yah yah" because she's been living within the community for a long while
already, and implicitly understands what the rules are trying to describe
[about how the community operates].
"rules" are simply a description of existing behavior rather than a
proscription of future behavior.
Cheers,
-g
--
gstein@apache.org ... ASF Chairman ... http://www.apache.org/
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: PMC Voting Process
Posted by Berin Loritsch <bl...@citi-us.com>.
> From: Stephen McConnell [mailto:mcconnell@apache.org]
<snip/>
> 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.
I saw the comment and I liked it. The point is this: we live
as a sub project of the greater Apache community. If the ASF
board addresses something in our charter/guidelines that is
contradictory to declared procedure or a board resolution,
we need to make it clear that the ASF position wins.
Should we correct the text as quickly as possible? Sure.
However, in the short term where there might be some confusion,
we have already stated that we recognize the ASF board as
a greater authority. That is all.
> (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.
I understand the concern. However our current understanding of
the PMC voting procedures do not allow the past to repeat itself.
I understand that the wounds are still sore, but also keep in mind
that if we ever have to deal with a similar issue again in the
future we have an overseeing group now with Avalon's good in mind.
We all hope we will never come across this type of problem again.
None of the proposed documents have anything that would allow for
the same issue to come up again as relating to the PMC.
> In effect - this is the PMC taking responsibility for being
> responsible.
There is a lot to sort out. Patience is imperitive. To encourage
you, the tone of this posting was much improved over the ones
earlier. If you keep communicating in this thoughtful and
provocative manner then we can get through it that much quicker.
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: PMC Voting Process
Posted by Stephen McConnell <mc...@apache.org>.
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.
> -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
>
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).
http://marc.theaimsgroup.com/?l=avalon-dev&m=104270697629068&w=2
>
> Stephen's:
> http://marc.theaimsgroup.com/?l=avalon-dev&m=103924111629118&w=2
>
The definative version from Steve's perspective is the currently adopted
P&P -
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.
>
>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?
>
>
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.
>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-
>
>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.
>
>
Excellent.
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:mcconnell@apache.org
http://www.osm.net
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: PMC Voting Process
Posted by Leo Simons <le...@apache.org>.
Leo Sutic wrote:
> THE ISSUES
>
> I see no issues other than the question of how the process is
> described.
we also discussed the issue of providing the procedure as an additional
"safety net" in case of problems, vs placing trust in the existing
safety net, and each other. I feel real strongly about that one :D
> 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?
Like Steve said, he has a "patch" to the layman version.
> 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?
the "how" of process description can affect community dynamics, can
affect how you look to the outside world, can affect how different
people take part. So not only the process, but also the "how" is important.
> 3. Am I correct in my description of the goal of the layman version?
yes.
> 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.
> 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.
sounds good to me.
cheers,
- Leo
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: PMC Voting Process
Posted by Berin Loritsch <bl...@citi-us.com>.
> -----Original Message-----
> From: Leo Sutic [mailto:leo.sutic@inspireinfrastructure.com]
> Sent: Friday, January 17, 2003 4:03 PM
> To: Avalon Developer's List
> Subject: PMC Voting Process
>
>
> 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.
>
> 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.
>
> -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
>
> Stephen's:
> http://marc.theaimsgroup.com/?l=avalon-dev&m=103924111629118&w=2
>
> Unfortunately I have not been able to find Berin's text at
> marc.theaimsgroup.com. Berin, could you provide a link?
Here:
http://nagoya.apache.org/wiki/apachewiki.cgi?AvalonPMCVotingProcedures
and
I could have swarn I sent the contents of the page (the WIKI source)
to the list--but I can't find the reference either.....
> 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.
Right.
> -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.
>
>
> 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.
Considering that we are getting back in line with what the mind of
Apache is (I am assuming you meant to type Apache), we could do this.
> 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.
Handling all disagreements can *usually* be handled discretely without
need of arbitration. The disagreements that can't should be escalated
through the PMC and ultimately to the board. Nevertheless we should
try to assume trust until proven otherwise (by actions).
> -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?
I believe so.
> 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?
I think so as well.
> 3. Am I correct in my description of the goal of the layman version?
>
> 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?
And again, to 3 & 4, I beleive so.
> -oOo-
>
> 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.
Right.
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>