You are viewing a plain text version of this content. The canonical link for it is here.
Posted to general@jakarta.apache.org by Hans Bergsten <ha...@gefionsoftware.com> on 2001/01/18 23:56:46 UTC
Release voting rules
Before we get to the point where a Tomcat 3.3 release proposal is
put up for a vote, I like to make sure we all agree about what the
voting rules are for this. At the PMC meeting, clearifying the
voting rules in general was given to James as an action item. I
therefore cross-post this to the PMC list, but I suggest that all
follow-ups are sent to the general list.
My take on the current rules is that the rules for voting on the
actual release are already clearly defined in our guidelines,
<http://jakarta.apache.org/site/decisions.html>):
Release Testing
After a new release is built, it must be tested before being released
to the public. Majority approval is required before the release can be
made.
Majority approval is defined in the same document as:
An action requiring majority approval must receive at least 3
binding +1 votes and more +1 votes than -1 votes.
A "binding vote" is a vote by a Committer, as opposed to a Developer.
What's not crystal clear is how to deal with votes on the release
proposal. The closest thing I can find is this:
Release Plan
A release plan is used to keep all Developers aware of when a release
is desired, who will be the release manager, when the repository will
be frozen to create a release, and other assorted information to keep
Developers from tripping over each other. Lazy majority decides each
issue in a release plan.
In the section describing the different types of votes, it says this
about "lazy approval": "All other action items are considered to have lazy
approval until somebody votes -1, after which point they are decided by
either consensus or majority vote, depending on the type of action item."
I take this to mean that each item in the release plan can be get a -1
vote. If the item can not be changed in such a way that the -1 voter
is willing to drop his/her -1, or can not be convinced to do so without
change, the issue must be resolved by consensus or majority vote.
The term "lazy majority" seem to imply that this calls for a majority
vote, but I'd like to see this confirmed and/or clarified.
I also take it, based on the existing guidelines, that a +1 on the
release plan implies a commitment to actively help with the implementation,
and a +1 on the release proposal implies a commitment to actively
support the released product (fix bugs, answer user questions, etc.).
Comments?
Hans
--
Hans Bergsten hans@gefionsoftware.com
Gefion Software http://www.gefionsoftware.com
Author of JavaServer Pages (O'Reilly), http://TheJSPBook.com
Re: Release voting rules
Posted by Glenn Nielsen <gl...@voyager.apg.more.net>.
Ted Husted wrote:
>
> A related issue is whether someone who became a committer for their
> contributions to one project can cast a binding vote or veto in some
> other subpproject.
>
> Right now, I * believe * the logins are "flat", and any Jakarta
> Committer has write access to any subproject repositories.
>
> The current guidelines, at least, do not make any distiction, and a
> Committer is apparently a Committer.
>
Jakarta commit privileges are delegated for each jakarta project
separately.
> *********** REPLY SEPARATOR ***********
>
> On 1/19/2001 at 11:14 PM Glenn Nielsen wrote:
>
> Ted Husted wrote:
> >
> > The lists of Committers is usually not current, so it can be
> difficult
> > for an observer to tell who the Committers are.
> >
>
> It would be nice for someone who has jakarta web site commit privileges
> to have a script which gets the jakarta committers from
> /home/cvs/CVSROOT/avail,
> then gets their real names from /etc/passwd. This is used to build a
> list
> of all jakarta committers, then a list of committers for each sub
> project,
> which is then published to the main jakarta site, or each project.
>
> Regards,
>
> Glenn
>
> -- Ted Husted, Husted dot Com, Fairport NY USA.
> -- Custom Software ~ Technical Services.
> -- Tel 716 425-0252; Fax 716 223-2506.
> -- http://www.husted.com/about/struts/
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: general-help@jakarta.apache.org
--
----------------------------------------------------------------------
Glenn Nielsen glenn@more.net | /* Spelin donut madder |
MOREnet System Programming | * if iz ina coment. |
Missouri Research and Education Network | */ |
----------------------------------------------------------------------
Re: Release voting rules
Posted by Ted Husted <ne...@husted.com>.
A related issue is whether someone who became a committer for their
contributions to one project can cast a binding vote or veto in some
other subpproject.
Right now, I * believe * the logins are "flat", and any Jakarta
Committer has write access to any subproject repositories.
The current guidelines, at least, do not make any distiction, and a
Committer is apparently a Committer.
*********** REPLY SEPARATOR ***********
On 1/19/2001 at 11:14 PM Glenn Nielsen wrote:
Ted Husted wrote:
>
> The lists of Committers is usually not current, so it can be
difficult
> for an observer to tell who the Committers are.
>
It would be nice for someone who has jakarta web site commit privileges
to have a script which gets the jakarta committers from
/home/cvs/CVSROOT/avail,
then gets their real names from /etc/passwd. This is used to build a
list
of all jakarta committers, then a list of committers for each sub
project,
which is then published to the main jakarta site, or each project.
Regards,
Glenn
-- Ted Husted, Husted dot Com, Fairport NY USA.
-- Custom Software ~ Technical Services.
-- Tel 716 425-0252; Fax 716 223-2506.
-- http://www.husted.com/about/struts/
Re: Release voting rules
Posted by Jon Stevens <jo...@latchkey.com>.
on 1/19/01 9:14 PM, "Glenn Nielsen" <gl...@voyager.apg.more.net> wrote:
> It would be nice for someone who has jakarta web site commit privileges
> to have a script which gets the jakarta committers from
> /home/cvs/CVSROOT/avail,
> then gets their real names from /etc/passwd. This is used to build a list
> of all jakarta committers, then a list of committers for each sub project,
> which is then published to the main jakarta site, or each project.
>
> Regards,
>
> Glenn
Thanks for volunteering! Write me a perl script to do this.
-jon
Re: Release voting rules
Posted by Glenn Nielsen <gl...@voyager.apg.more.net>.
Ted Husted wrote:
>
> The lists of Committers is usually not current, so it can be difficult
> for an observer to tell who the Committers are.
>
It would be nice for someone who has jakarta web site commit privileges
to have a script which gets the jakarta committers from /home/cvs/CVSROOT/avail,
then gets their real names from /etc/passwd. This is used to build a list
of all jakarta committers, then a list of committers for each sub project,
which is then published to the main jakarta site, or each project.
Regards,
Glenn
----------------------------------------------------------------------
Glenn Nielsen glenn@more.net | /* Spelin donut madder |
MOREnet System Programming | * if iz ina coment. |
Missouri Research and Education Network | */ |
----------------------------------------------------------------------
Re: Release voting rules
Posted by Ted Husted <ne...@husted.com>.
>That's another thing that's not clearly defined; what type of approval
do we need for changes to the guidelines?
The guideline itself just says "This is a living document. Changes can
be made by the Project Management Committee."
The only other thing said about PMC voting is that subprojects are
created, and committee members dismissed, by a 3/4 majority vote
>> All votes by Committers should include the word "binding" next to
their vote.
>> When tendering a -1 vote on a Consensus item, a Committer should
include the phrase "binding veto" next to their Vote, to make
theirintent clear.
>I don't see the need for this.
The lists of Committers is usually not current, so it can be difficult
for an observer to tell who the Committers are.
Since Developers are invited to vote, it may eliminate controversy if
we distinguish the two categories (binding from non-biding).
Secondary reasons is remind Committers of the importance of a binding
vote, and to be sure everyone understands when a -1 is also a veto.
It would be interesting to see if the protocol can be so clear and
simple that even a machine could tally the votes ;0)
But reducing overhead is also a good arguement!
> Do we need this distinction? Why not [PROPOSAL] for Short/Long Term
Plans as well?
I'm not sure. I was thinking of a proposal as the preliminary to a
vote, and that there might be short and long term plans that would not
lead to a vote. But I suppose that if, in practice, anything we might
announce as a short or long term plan would lead to a vote, then we
don't need both.
>We need to define "lazy majority"
>We need to define "lazy consensus" as well.
At < http://husted.com/about/jakarta/index.html#decisions/voting >, I
did this:
Note: "Lazy" means the action item has immediate tactic approval, and
that is not necessary to tally the vote until a -1 reply is posted.
Once a -1 reply is posted, the vote must be tallied and reported before
the action item is considered approved. All action-item votes are lazy
except for a public release vote.
Does that sound alright?
>><strike>If the vote is about a change to the source code or
documentation and the primary author is a Developer and not a
Committer, the primary author of what is being changed may also cast a
binding vote on that issue.</strike>
> Hmmm... My take on this paragraph is that it's there to make sure
that even a person who is not a Committer has a say about his
contribution. It has nothing to do with ASF membership.
I'm not sure what it is suppose to mean. I guess the situation would be
about a "Product Change", which is one of the two consensus votes, so
we may be giving the "primary author" the opportunity to veto changes
to their own work. Sounds like ego-bait to me. Then again, the
guidelines says a "Committer's" -1 is a veto, so maybe we are not. The
whole clause is murky, and perhaps unnecessary.
> Also, we need to define the Release Manager role in the "Roles and
Responsibilities" document.
Noted.
Geir>Can they already, or was it simply discussed? If they can
already, is there any formalized appeals process? One concern there
would be to ask any PMC member that is a participant in the vote being
appealed to abstain from participation in the appeals process.
The published guidelines do not include a formal appeals process.
Though, one approach might be for the Chairman to appoint a a
three-member PMC subcomittee to arbitrate the matter.
Craig>My question is, really, is it OK for the committers on a
particular subproject to agree to operate in a manner different from
the guidelines, even when they are spelled
out in detail (such as the voting rules, to take the particular case we
are currently discussing)? Either extreme answer does not seem
appropriate, but mechanisms to navigate the middle ground would need to
be discussed.
Personally, I would say that a project may offer their own superset of
guidelines, so long as it does not conflict with core guidelines. Much
the same way that (in America) if a state law conflicts with a federal
law, the federal law wins. The guidelines should be a constitution that
applies equally to all subprojects, who may in turn adopt more specific
guidelines, if they choose.
-- Ted Husted, Husted dot Com, Fairport NY USA.
-- Custom Software ~ Technical Services.
-- Tel 716 425-0252; Fax 716 223-2506.
-- http://www.husted.com/about/struts/
Re: Release voting rules
Posted by Ted Husted <ne...@husted.com>.
>I might suggest that the PMC ask the Committers to ratify this
overhaul before voting on it itself, since the changes are substantial.
But I
don't know if I would "lower the bar" on changing the guidelines.
Or, turn that around and have each subproject ratify the changes (as a
consensus vote), after the changes have passed a 3/4 vote by the PMC.
-T.
-- Ted Husted, Husted dot Com, Fairport NY USA.
-- Custom Software ~ Technical Services.
-- Tel 716 425-0252; Fax 716 223-2506.
-- http://www.husted.com/about/struts/
Re: Release voting rules
Posted by Ted Husted <ne...@husted.com>.
Sam>"+1" is part of our culture and lexicon. Have you ever caught
yourself typing "+1" to someone outside of our group in casual
conversation?
Personally, I would think because of this it is important to emphasize
that a +1 on an action item is not a casual matter, and should have the
precise meaning that "Yes, I will help."
Sam>In many ways, by distinguishing between the two we are making it a
point to indicate that votes by "mere" contributors are of less value
than votes by
contributors.
Coming from the outside, I would suggest that the idea of "mere"
contributors might be more of an issue in Apache circles, but less of
an issue with a Jakarta subproject, where the Committer status bar
seems lower.
Hans> But a +1/-1 vote by a Committer is always binding, even without
this indication.
I'm (-0) on that myself, but have reworked the text to reflect that all
votes by a subproject's Committer are binding, and that including the
word "binding" with their vote is helpful. We could then see if people
actually start to do it or not, and let the culture decide.
Of course, getting that script to keep the Committer lists updated
would also be helpful. (Which I personally do not have the skill to
write.)
Sam>It is worth mentioning that not all votes are for releases. In
voting to include a new commiter, for example, a +1 is simply a "I
support this nomination"
I simplified the "flavors" of voting for action item, to stress
participation, and then added another section about voting on other
matters.
Each vote on an * action item * can be made in one of three flavors:
+1 = "The action should be performed, and I will help."��
+/-0 = "Abstain," or "I can't help with this now".
-1 = "The action should not be performed and I will offer an
explanation or alternative."
<later/>
Voting on other matters
There are other matters upon which members will vote that do not
involve action items. The same general voting structure is used in
these cases, except that the "flavors" are taken to mean
+1 = "Yes," "Agree,"
+/-0 = "Abstain," "No opinion"
-1 = "No," "Disagree."
Hans>I'll intend to put up for a vote to the PMC that we change it so
that Major approval of Committers is what's needed.
I'm not a Committee member, but personally, I think the guidelines are
really very important, and changes should be reserved to a 3/4's vote
by the PMC.
I might suggest that the PMC ask the Committers to ratify this overhaul
before voting on it itself, since the changes are substantial. But I
don't know if I would "lower the bar" on changing the guidelines.
-T.
-- Ted Husted, Husted dot Com, Fairport NY USA.
-- Custom Software ~ Technical Services.
-- Tel 716 425-0252; Fax 716 223-2506.
-- http://www.husted.com/about/struts/
Re: Release voting rules
Posted by Ted Husted <ne...@husted.com>.
On 1/22/2001 at 1:20 PM Craig R. McClanahan wrote:
>Proposed on GENERAL@JAKARTA.APACHE.ORG, and voted by the entire
community of interest. PMC has the responsibility to ensure that no
changes in policies and procedures violate the ASF Board charter that
created the project, but does not otherwise participate directly as a
unit. Each individual PMC member that is a committer, of course, has
the right to participate individually.
On 1/22/2001 at 1:58 PM Hans Bergsten wrote:
> "This is a living document. Changes can be made by <insert> a 3/4's
vote of the </insert>the Project Management Committee<insert>. A
suggested change must be posted to the general@jakarta.apache.org list
for input from the community before it's put up for a formal vote, and
anyone in the community can initiate a suggestion for a change on the
same list. Even though a change is vote on by PMC members only, the
whole community can thereby influence the decision by voicing their
opinion on this list.
Maybe we should just let the original text stand for now "This is a
living document. Changes can be made by the Project Management
Committee." -- and the PMC could resolve to make this set of changes
following open discussion on the General List, and set a non-binding
precedent.
Which could boil down an announcement that says:
"Several clarifications have been proposed to the Jakarta Project
Guidelines, which are (will be) available for review and comment at <
http://jakarta.apache.org/proposal.html >. Discussion regarding this
proposal is welcome on the General list. When it appears that a
consensus has been reached, James will ask for a majority vote of the
Commiters. The PMC can then make the changes official at its next
regular meeting."
-T.
Re: Release voting rules
Posted by Hans Bergsten <ha...@gefionsoftware.com>.
Ted Husted wrote:
> [...]
> So, the working copy of the General list's proposal, now at <
> http://husted.com/about/jakarta > is being moved to the Jakarta site,
> where the drafting process will continue. When this happens, I imagine
> we will want to announce this initiative to all the lists, to be sure
> everyone is in the loop.
>
> Before anything like an official draft is announced, I'd suggest that
> anyone actively following this thread read over the current draft for
> any obvious oversights. It has been my intention for this document to
> include everything that was suggested and at least "seconded" in some
> way here.
I will read the draft and comment if I see things I feel needs to be
addressed. But before we go through all areas, I'd like to focus on
the things we need clarified for a Release Proposal decision. I'll
address this in a separate mail.
> For the record, here are two suggestions that were not included since
> there did not seem to be a consensus. If no one has an positive
> response, then I would just let these "die in committee".
>
> --
>
> [ guidelines.html ]
>
> "This is a living document. Changes can be made by <insert> a 3/4's
> vote of the </insert>the Project Management Committee<insert>,
> confirmed by a majority vote of the Committers (one Committer, one
> vote)</insert>."
I've been thinking a bit more about this over the weekend, and I agree
with you and Sam that we may not want to "lower the bar" on changes to
the policy. I'm almost happy with what you have above, but I'd change
it slightly:
"This is a living document. Changes can be made by <insert> a 3/4's
vote of the </insert>the Project Management Committee<insert>. A
suggested change must be posted to the general@jakarta.apache.org
list for input from the community before it's put up for a formal
vote, and anyone in the community can initiate a suggestion for a change
on the same list. Even though a change is vote on by PMC members only,
the whole community can thereby influence the decision by voicing their
opinion on this list.
> This one's a bit more radical ;-)
>
> [ management.html ]
>
> Subproject Advisory Council
> [...]
I don't like this, for the same reasons expressed by Sam and Craig. We
don't need this extra level of bureaucracy. Ideally, the guidelines should
be on a level where they can apply to all subprojects, without a need
for specialized guidelines per subproject. One thing we should do, however,
is to make sure the PMC has representation from all subprojects. I'm
also in favor of letting the Committers in all subprojects elect PMC
members.
Hans
--
Hans Bergsten hans@gefionsoftware.com
Gefion Software http://www.gefionsoftware.com
Author of JavaServer Pages (O'Reilly), http://TheJSPBook.com
Re: Release voting rules
Posted by "Craig R. McClanahan" <Cr...@eng.sun.com>.
Ted Husted wrote:
>
> This one's a bit more radical ;-)
>
> [ management.html ]
>
> Subproject Advisory Council
>
> <note>
> Practical Upshot:
> + SAC members are appointed by the subproject Committers.
> + The SAC acts like the PMC's "sergeant at arms".
> + A member may not serve on the PMC and SAC simultaneously.
> + The current SAC chairman is a non-voting member of the PMC.
> </note>
>
> Role
> The Subproject Advisory Council (SAC) is charged by the Project
> Management Committee with the following responsibilities:
>
-0. I don't see a lot of value in adding a layer of bureaucracy. After all,
the community of interest here is all committers on all Jakarta subprojects.
Just like all committers on a particular subproject have a direct vote, so
should all committers across all subprojects should have a direct vote on
cross-subproject issues. (IMHO, We are nowhere near the community size where
"representative democracy" seems necessary).
In order to address the specific responsibilities you have described, here's my
opinions on how they should be handled:
>
> Proposing changes to the Project guidelines as needed;
Proposed on GENERAL@JAKARTA.APACHE.ORG, and voted by the entire community of
interest. PMC has the responsibility to ensure that no changes in policies and
procedures violate the ASF Board charter that created the project, but does not
otherwise participate directly as a unit. Each individual PMC member that is a
committer, of course, has the right to participate individually.
>
> Determing whether a project is inactive and should be retired;
Sounds like a community-wide decision would be more appropriate. The publicity
surrounding a proposal to remove a project is more likely to cause someone to
volunteer to take responsibility for an old project than any committee action
would.
>
> Determing whether a Committer is inactive, and if their account should
> be disabled;
This should be addressed on a per-subproject basis. I might decide to get
involved in a different Jakarta subproject and "abandon" an old one (by whatever
criteria are appropriate) -- my account is still active, but my commit rights to
the old subproject might well be revoked.
Committers who abandon all subprojects would eventually have commit rights on
none of them, at which time it would be appropriate to retire their login.
NOTE: Policy guidance (in the Guidelines) on how to identify inactive
committers would be a good idea, but that's really a per-subproject thing to
enforce.
>
> Determining, upon request, whether the reason for a binding veto is
> valid;
First recourse -- subproject community (i.e. committers on the DEV list) should
attempt to resolve this themselves, based on the published Guidelines.
Last recourse -- PMC. The need to do this should be very rare, so it's
certainly not a burdensome thing to deal with. Most disputes here will be over
technical disagreements anyway, and we really want the involved committers to
resolve it.
>
> Determining, upon request, whether a Committer has failed and refused
> to follow Project guidelines, and whether their access and privledges
> should be revoked.
>
First recourse -- subproject community (i.e. committers on the DEV list) should
attempt to resolve this themselves, based on the published Guidelines.
Last recourse -- PMC. As above, this should happen rarely -- if it happens
often, then the likely culprits are unclear guidelines, or too-quick granting of
committer status without the new committer understanding what the
responsibilities are.
>
> All votes are by a 3/4 majority of the SAC members. Actions of the SAC
> must be approved by the PMC Chairman to be binding. At its option, the
> PMC may also directly discharge any responsibility delegated to the SAC
> by its own 3/4 majority vote.
>
Here's where the low value-add of the SAC shows up most clearly. If the SAC
cannot do anything binding, what's the point of the exercise?
>
> Membership
> Each subproject shall appoint one of its Committers to serve on the
> Subproject Advisory Council. The list of current SAC members can be
> found in our Project Credits. A member may not be appointed to the SAC
> by more than one subproject at the same time (one member, one vote).
> Members serve an indefinite term by lazy consensus of the subproject
> which appointed them. SAC members may resign at any time. A member may
> not simultaneously serve on the Subproject Advisory Council and also as
> a voting member of the Project Management Committee. A member must
> maintain active Committer status with a subproject.
>
> Chairman
> The SAC is answerable to the Project Management Committee with its
> Chairman serving as primary liaison. The SAC shall elect a Chairman
> from it's current membership in the same manner the PMC Chairman is
> elected. The term of the Chairman is one year, running from February
> through January. If the member serving as Chairman is removed by his or
> her subproject, an interim Chairman must be elected from the current
> SAC membership. The SAC Chairman may attend all PMC meetings and
> subscribe to the PMC mailing list as a non-voting member for the
> duration of his or her term. A Chairman may be re-elected to a
> subsequent term. The exiting Chairman maintains membership status in
> the council. The Chairman may resign as Chairman at any time without
> resigning membership to the SAC.
>
> Meetings
> Most SAC business is conducted via the General mailing list. The SAC
> has an annual meeting at which time a new Chairman is elected. Meetings
> may take place online, via teleconference, or via other means deemed
> effective by the SAC. The Chairman must post a status report to the
> General mailing list by the 15th of each calendar month summarizing the
> SAC's activities and current status.
>
> -T.
>
Craig McClanahan
Re: Release voting rules
Posted by Ted Husted <ne...@husted.com>.
On 1/23/2001 at 10:22 AM James Duncan Davidson wrote:
>I'd rather see that the PMC is composed of at least one person from
each subproject.
+1
-- Ted Husted, Husted dot Com, Fairport NY USA.
-- Custom Software ~ Technical Services.
-- Tel 716 425-0252; Fax 716 223-2506.
-- http://www.husted.com/about/struts/
Re: Release voting rules
Posted by James Duncan Davidson <du...@x180.net>.
On 1/22/01 12:32 PM, "Ted Husted" <ne...@husted.com> wrote:
> Subproject Advisory Council
I'd rather see that the PMC is composed of at least one person from each
subproject. I don't think we need a senate and a house.
--
James Duncan Davidson duncan@x180.net
!try; do()
Re: Release voting rules
Posted by Ted Husted <ne...@husted.com>.
So, the working copy of the General list's proposal, now at <
http://husted.com/about/jakarta > is being moved to the Jakarta site,
where the drafting process will continue. When this happens, I imagine
we will want to announce this initiative to all the lists, to be sure
everyone is in the loop.
Before anything like an official draft is announced, I'd suggest that
anyone actively following this thread read over the current draft for
any obvious oversights. It has been my intention for this document to
include everything that was suggested and at least "seconded" in some
way here.
For the record, here are two suggestions that were not included since
there did not seem to be a consensus. If no one has an positive
response, then I would just let these "die in committee".
--
[ guidelines.html ]
"This is a living document. Changes can be made by <insert> a 3/4's
vote of the </insert>the Project Management Committee<insert>,
confirmed by a majority vote of the Committers (one Committer, one
vote)</insert>."
---
This one's a bit more radical ;-)
[ management.html ]
Subproject Advisory Council
<note>
Practical Upshot:
+ SAC members are appointed by the subproject Committers.
+ The SAC acts like the PMC's "sergeant at arms".
+ A member may not serve on the PMC and SAC simultaneously.
+ The current SAC chairman is a non-voting member of the PMC.
</note>
Role�
The Subproject Advisory Council (SAC) is charged by the Project
Management Committee with the following responsibilities:
Proposing changes to the Project guidelines as needed;
Determing whether a project is inactive and should be retired;
Determing whether a Committer is inactive, and if their account should
be disabled;
Determining, upon request, whether the reason for a binding veto is
valid;
Determining, upon request, whether a Committer has failed and refused
to follow Project guidelines, and whether their access and privledges
should be revoked.
All votes are by a 3/4 majority of the SAC members. Actions of the SAC
must be approved by the PMC Chairman to be binding. At its option, the
PMC may also directly discharge any responsibility delegated to the SAC
by its own 3/4 majority vote.
Membership
Each subproject shall appoint one of its Committers to serve on the
Subproject Advisory Council. The list of current SAC members can be
found in our Project Credits. A member may not be appointed to the SAC
by more than one subproject at the same time (one member, one vote).
Members serve an indefinite term by lazy consensus of the subproject
which appointed them. SAC members may resign at any time. A member may
not simultaneously serve on the Subproject Advisory Council and also as
a voting member of the Project Management Committee. A member must
maintain active Committer status with a subproject.
Chairman
The SAC is answerable to the Project Management Committee with its
Chairman serving as primary liaison. The SAC shall elect a Chairman
from it's current membership in the same manner the PMC Chairman is
elected. The term of the Chairman is one year, running from February
through January. If the member serving as Chairman is removed by his or
her subproject, an interim Chairman must be elected from the current
SAC membership. The SAC Chairman may attend all PMC meetings and
subscribe to the PMC mailing list as a non-voting member for the
duration of his or her term. A Chairman may be re-elected to a
subsequent term. The exiting Chairman maintains membership status in
the council. The Chairman may resign as Chairman at any time without
resigning membership to the SAC.
Meetings
Most SAC business is conducted via the General mailing list. The SAC
has an annual meeting at which time a new Chairman is elected. Meetings
may take place online, via teleconference, or via other means deemed
effective by the SAC. The Chairman must post a status report to the
General mailing list by the 15th of each calendar month summarizing the
SAC's activities and current status.
-T.
Re: Release voting rules
Posted by James Duncan Davidson <du...@x180.net>.
On 1/21/01 4:41 PM, "Craig R. McClanahan" <Cr...@eng.sun.com>
wrote:
>>> +1 = Yes, I can help.
>
> I would prefer +1 to mean "Yes, and I *will* help".
Oh definitely. Good point.
--
James Duncan Davidson duncan@x180.net
!try; do()
Re: Release voting rules
Posted by "Craig R. McClanahan" <Cr...@eng.sun.com>.
Hans Bergsten wrote:
> Ted Husted wrote:
> >
> > Following this phrase
> >
> > "The act of voting carries certain obligations. Voting members are not
> > only stating their opinion, they are also agreeing to help do the
> > work."
> >
> > I was wondering if this sounded appropriate, at least in the context of
> > voting:
> >
> > +1 = Yes, I can help.
>
I would prefer +1 to mean "Yes, and I *will* help".
> >
> > +0 = I can't help, but do believe the action should be performed.
> >
> > -0 = I have my doubts, but will not oppose the action.
> >
> > -1 = No. The action should not be perfomed because: [reason].
> >
> > -1 binding = Absolutely not. The action must not be performed because:
> > [reason].
> >
> > + binding = Absolutely yes. I can help and would be available for a
> > leadership role.
>
> I still don't think we need more than the current +1/+0/-0/-1 choices,
> with the +1/-1 votes roughly matching your "binding" descriptions; we
> don't want to make it too complicated.
>
I agree -- IMHO the "binding" versus "non-binding" stuff is really about whether
a -1 is a veto or not (i.e. whether the decision being made requires consensus
rather than majority). It's not about whether there are two flavors of -1.
>
> I don't see a need for the additional "binding" attribute. I do agree,
> however, with what you said earlier that it's a good idea to include
> the word "binding" in a vote to indicate that its a vote from a Committer.
> But a +1/-1 vote by a Committer is always binding, even without this
> indication. The word "binding" would only serve to make it easier for
> people monitoring the list to understand that the vote is valid.
>
> Hans
>
Craig
> --
> Hans Bergsten hans@gefionsoftware.com
> Gefion Software http://www.gefionsoftware.com
> Author of JavaServer Pages (O'Reilly), http://TheJSPBook.com
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: general-help@jakarta.apache.org
Re: Release voting rules
Posted by James Duncan Davidson <du...@x180.net>.
On 1/20/01 11:02 AM, "Hans Bergsten" <ha...@gefionsoftware.com> wrote:
> I still don't think we need more than the current +1/+0/-0/-1 choices,
> with the +1/-1 votes roughly matching your "binding" descriptions; we
> don't want to make it too complicated.
+1 :)
--
James Duncan Davidson duncan@x180.net
!try; do()
Re: Release voting rules
Posted by Hans Bergsten <ha...@gefionsoftware.com>.
Ted Husted wrote:
>
> Following this phrase
>
> "The act of voting carries certain obligations. Voting members are not
> only stating their opinion, they are also agreeing to help do the
> work."
>
> I was wondering if this sounded appropriate, at least in the context of
> voting:
>
> +1 = Yes, I can help.
>
> +0 = I can't help, but do believe the action should be performed.
>
> -0 = I have my doubts, but will not oppose the action.
>
> -1 = No. The action should not be perfomed because: [reason].
>
> -1 binding = Absolutely not. The action must not be performed because:
> [reason].
>
> + binding = Absolutely yes. I can help and would be available for a
> leadership role.
I still don't think we need more than the current +1/+0/-0/-1 choices,
with the +1/-1 votes roughly matching your "binding" descriptions; we
don't want to make it too complicated.
I don't see a need for the additional "binding" attribute. I do agree,
however, with what you said earlier that it's a good idea to include
the word "binding" in a vote to indicate that its a vote from a Committer.
But a +1/-1 vote by a Committer is always binding, even without this
indication. The word "binding" would only serve to make it easier for
people monitoring the list to understand that the vote is valid.
Hans
--
Hans Bergsten hans@gefionsoftware.com
Gefion Software http://www.gefionsoftware.com
Author of JavaServer Pages (O'Reilly), http://TheJSPBook.com
Re: Release voting rules
Posted by Ted Husted <ne...@husted.com>.
Following this phrase
"The act of voting carries certain obligations. Voting members are not
only stating their opinion, they are also agreeing to help do the
work."
I was wondering if this sounded appropriate, at least in the context of
voting:
+1 = Yes, I can help.
+0 = I can't help, but do believe the action should be performed.
-0 = I have my doubts, but will not oppose the action.
-1 = No. The action should not be perfomed because: [reason].
-1 binding = Absolutely not. The action must not be performed because:
[reason].
+ binding = Absolutely yes. I can help and would be available for a
leadership role.
-T.
-- Ted Husted, Husted dot Com, Fairport NY USA.
-- Custom Software ~ Technical Services.
-- Tel 716 425-0252; Fax 716 223-2506.
-- http://www.husted.com/about/struts/
Re: Release voting rules
Posted by Ted Husted <ne...@husted.com>.
I "refactored" the voting section a bit, to make it more
process-orientated.
In doing this, I came upon this idea:
"Committers also have the option to make their vote binding. This
signifies that the individual will contribute to performing the action
item, or actively support a public release. To indicate this,
Committers should include the word "binding" next to their vote (+1
binding)."
This may help promote the idea that we need 3 committers to sign-on and
* actively * perform the action.
I realize that we have the +0/-0 shades of meaning, but it might be
helpful to emphasize the importance of having three "bound" committers.
< http://husted.com/about/jakarta/ >
-T.
-- Ted Husted, Husted dot Com, Fairport NY USA.
-- Custom Software ~ Technical Services.
-- Tel 716 425-0252; Fax 716 223-2506.
-- http://www.husted.com/about/struts/
Re: Release voting rules
Posted by Hans Bergsten <ha...@gefionsoftware.com>.
"Craig R. McClanahan" wrote:
>
> Hans Bergsten wrote:
> [...]
> > I don't like "rules" in general, since it's almost impossible to cover
> > every single scenario in this type of document anyway (unless we let a
> > bunch of lawyers loose, and then spend a lot of time trying to figure
> > out what they mean ;-) I prefer guidelines, with the intent to cover the
> > most common cases in detail, but leave it up to interpretation (by PMC)
> > in the rare case that there's a conflict regarding something that's not
> > covered.
> >
>
> I agree with your general philosophy on rules versus guidelines.
>
> My question is, really, is it OK for the committers on a particular subproject to
> agree to operate in a manner different from the guidelines, even when they are spelled
> out in detail (such as the voting rules, to take the particular case we are currently
> discussing)? Either extreme answer does not seem appropriate, but mechanisms to
> navigate the middle ground would need to be discussed.
My take on this is that all subprojects must follow what's described
in the guidelines. If there are important things missing for a subproject,
I suggest the Committers bring a proposal to fix it to this list. Sure,
there will be cases where it's hard to describe in detail what applies
to different subprojects. In these cases the guidelines can be written
so that subprojects get a bit more leeway.
In general, I don't think we should create too much of a "law book" here,
or get into too much detail in the guidelines; if the guidelines take
too much time to read and understand, no one will follow them. It's better
to keep it simple, and be prepared to resolve issues now and then instead.
Hans
--
Hans Bergsten hans@gefionsoftware.com
Gefion Software http://www.gefionsoftware.com
Author of JavaServer Pages (O'Reilly), http://TheJSPBook.com
Re: Release voting rules
Posted by "Craig R. McClanahan" <Cr...@eng.sun.com>.
Hans Bergsten wrote:
> "Craig R. McClanahan" wrote:
> >
> > Hans Bergsten wrote:
> > [...]
> > > Hmm... That's another thing that's not clearly defined; what type of
> > > approval do we need for changes to the guidelines?
> >
> > Sounds like another clarification needing to be added :-).
> >
> > More seriously, though, there is a couple of additional questions that should be
> > discussed and addressed. Comments in square brackets represent my understanding
> > of the current state of the world.
> >
> > * What is the "voting community" for changes to guidelines
> > such as the ones we are discussing here? [because they
> > are cross-subproject, GENERAL@JAKARTA.APACHE.ORG
> > seems like the right forum -- but are binding voters those with
> > commit access on any subproject?]
>
> I feel that it should be the Committers in all Jakarta subprojects.
>
I agree.
>
> > * Are these things "guidelines" (that can be adopted by subprojects,
> > or used as a starting point and then customized) or "rules" (subprojects
> > under Jakarta *must* abide by them)? [A little fuzzy, but more on the
> > "guidelines" end of the scale]
>
> I don't like "rules" in general, since it's almost impossible to cover
> every single scenario in this type of document anyway (unless we let a
> bunch of lawyers loose, and then spend a lot of time trying to figure
> out what they mean ;-) I prefer guidelines, with the intent to cover the
> most common cases in detail, but leave it up to interpretation (by PMC)
> in the rare case that there's a conflict regarding something that's not
> covered.
>
I agree with your general philosophy on rules versus guidelines.
My question is, really, is it OK for the committers on a particular subproject to
agree to operate in a manner different from the guidelines, even when they are spelled
out in detail (such as the voting rules, to take the particular case we are currently
discussing)? Either extreme answer does not seem appropriate, but mechanisms to
navigate the middle ground would need to be discussed.
>
> > > My suggestion is
> > > that it requires Majority Approval.
> > >
> >
> > Makes sense to me, once we clarify who the voting community is.
> >
> > >
> > > Hans
> > >
> >
> > Craig McClanahan
>
> Hans
Craig
Re: Release voting rules
Posted by Hans Bergsten <ha...@gefionsoftware.com>.
"Craig R. McClanahan" wrote:
>
> Hans Bergsten wrote:
> [...]
> > Hmm... That's another thing that's not clearly defined; what type of
> > approval do we need for changes to the guidelines?
>
> Sounds like another clarification needing to be added :-).
>
> More seriously, though, there is a couple of additional questions that should be
> discussed and addressed. Comments in square brackets represent my understanding
> of the current state of the world.
>
> * What is the "voting community" for changes to guidelines
> such as the ones we are discussing here? [because they
> are cross-subproject, GENERAL@JAKARTA.APACHE.ORG
> seems like the right forum -- but are binding voters those with
> commit access on any subproject?]
I feel that it should be the Committers in all Jakarta subprojects.
> * Are these things "guidelines" (that can be adopted by subprojects,
> or used as a starting point and then customized) or "rules" (subprojects
> under Jakarta *must* abide by them)? [A little fuzzy, but more on the
> "guidelines" end of the scale]
I don't like "rules" in general, since it's almost impossible to cover
every single scenario in this type of document anyway (unless we let a
bunch of lawyers loose, and then spend a lot of time trying to figure
out what they mean ;-) I prefer guidelines, with the intent to cover the
most common cases in detail, but leave it up to interpretation (by PMC)
in the rare case that there's a conflict regarding something that's not
covered.
> > My suggestion is
> > that it requires Majority Approval.
> >
>
> Makes sense to me, once we clarify who the voting community is.
>
> >
> > Hans
> >
>
> Craig McClanahan
Hans
--
Hans Bergsten hans@gefionsoftware.com
Gefion Software http://www.gefionsoftware.com
Author of JavaServer Pages (O'Reilly), http://TheJSPBook.com
Re: Release voting rules
Posted by "Craig R. McClanahan" <Cr...@eng.sun.com>.
Hans Bergsten wrote:
> Ted Husted wrote:
> > [...]
> > In case anyone finds it useful, I set up a working draft of the
> > Guidelines at < http://husted.com/about/jakarta/ >. Of course, these
> > are simply my personal notes.
> >
> > I would be happy to continue to track any suggested changes to the
> > rules, if that would be helpful.
>
> Great, I really appreciate this. When it seems like we have reached
> consensus on this list, we can put your document up for a vote.
> Hmm... That's another thing that's not clearly defined; what type of
> approval do we need for changes to the guidelines?
Sounds like another clarification needing to be added :-).
More seriously, though, there is a couple of additional questions that should be
discussed and addressed. Comments in square brackets represent my understanding
of the current state of the world.
* What is the "voting community" for changes to guidelines
such as the ones we are discussing here? [because they
are cross-subproject, GENERAL@JAKARTA.APACHE.ORG
seems like the right forum -- but are binding voters those with
commit access on any subproject?]
* Are these things "guidelines" (that can be adopted by subprojects,
or used as a starting point and then customized) or "rules" (subprojects
under Jakarta *must* abide by them)? [A little fuzzy, but more on the
"guidelines" end of the scale]
> My suggestion is
> that it requires Majority Approval.
>
Makes sense to me, once we clarify who the voting community is.
>
> Hans
>
Craig McClanahan
Re: Release voting rules
Posted by Hans Bergsten <ha...@gefionsoftware.com>.
Ted Husted wrote:
> [...]
> In case anyone finds it useful, I set up a working draft of the
> Guidelines at < http://husted.com/about/jakarta/ >. Of course, these
> are simply my personal notes.
>
> I would be happy to continue to track any suggested changes to the
> rules, if that would be helpful.
Great, I really appreciate this. When it seems like we have reached
consensus on this list, we can put your document up for a vote.
Hmm... That's another thing that's not clearly defined; what type of
approval do we need for changes to the guidelines? My suggestion is
that it requires Majority Approval.
Hans
--
Hans Bergsten hans@gefionsoftware.com
Gefion Software http://www.gefionsoftware.com
Author of JavaServer Pages (O'Reilly), http://TheJSPBook.com
Re: Release voting rules
Posted by Ted Husted <ne...@husted.com>.
On 1/18/2001 at 2:56 PM Hans Bergsten wrote:
> In the section describing the different types of votes, it says this
about "lazy approval": "All other action items are considered to have
lazy
approval until somebody votes -1, after which point they are decided by
either consensus or majority vote, depending on the type of action
item."
> I take this to mean that each item in the release plan can be get a
-1 vote. If the item can not be changed in such a way that the -1 voter
is willing to drop his/her -1, or can not be convinced to do so without
change, the issue must be resolved by consensus or majority vote.
The term "lazy majority" seem to imply that this calls for a majority
vote, but I'd like to see this confirmed and/or clarified.
I would suggest that as soon as any (-1) reply is made to any Vote,
that it is no longer "lazy", whether someone later converts their (-1)
or not.
Any (-1) signifies that there is some type of dispute, and that we must
then be careful it is resolved to everyone's satisfaction. Once a (-1)
circulates, I would suggest that the person who tendered the vote must
summarize the result before proceeding further.
In case anyone finds it useful, I set up a working draft of the
Guidelines at < http://husted.com/about/jakarta/ >. Of course, these
are simply my personal notes.
I would be happy to continue to track any suggested changes to the
rules, if that would be helpful.
-Ted.
Re: Release voting rules
Posted by Hans Bergsten <ha...@gefionsoftware.com>.
"Geir Magnusson Jr." wrote:
>
> Hans Bergsten wrote:
> >
> > Ted Husted wrote:
>
> > > All Votes receiving only +1 or
> > > +/-0 replies are subject to lazy approval. Any question regarding the
> > > outcome of a Vote may be refrerred by a Committer to the PMC for
> > > arbitration.
> >
> > Sounds fine to me. The fact that PMC can break a veto (as the last resort)
> > was also discussed in the meeting.
>
> Can they already, or was it simply discussed? If they can already, is
> there any formalized appeals process?
>
> One concern there would be to ask any PMC member that is a participant
> in the vote being appealed to abstain from participation in the appeals
> process.
It was discussed, and all guidelines and bylaws must be updated (and
voted on) before any of this takes effect, IMHO. It seems reasonable
that the updates are discussed here for a while until we go for a vote.
Hans
--
Hans Bergsten hans@gefionsoftware.com
Gefion Software http://www.gefionsoftware.com
Author of JavaServer Pages (O'Reilly), http://TheJSPBook.com
Re: Release voting rules
Posted by "Geir Magnusson Jr." <ge...@optonline.net>.
Hans Bergsten wrote:
>
> Ted Husted wrote:
> > All Votes receiving only +1 or
> > +/-0 replies are subject to lazy approval. Any question regarding the
> > outcome of a Vote may be refrerred by a Committer to the PMC for
> > arbitration.
>
> Sounds fine to me. The fact that PMC can break a veto (as the last resort)
> was also discussed in the meeting.
Can they already, or was it simply discussed? If they can already, is
there any formalized appeals process?
One concern there would be to ask any PMC member that is a participant
in the vote being appealed to abstain from participation in the appeals
process.
geir
--
Geir Magnusson Jr. geirm@optonline.com
Velocity : it's not just a good idea. It should be the law.
http://jakarta.apache.org/velocity
Re: Release voting rules
Posted by Hans Bergsten <ha...@gefionsoftware.com>.
Ted Husted wrote:
> [...]
> Although I probably don't understand all the nuances of the "Apache
> Culture", as a Jakarta Committer, here is a draft "patch" that I would
> suggest to decisions.html (mostly parity-checks):
>
> --
>
> Voting
>
> Any Developer or Committer may call for a Vote on the Developer mailing
> list. It is preferred that a Vote be preceded by a formal proposal
> offered for discussion purposes. A call for a formal Vote must contain
> the legend "[VOTE-action item]" in its subject line, where "action
> item" is Release Plan, Public Release, Showstopper, or Product Change.
> A * Public Release * Vote is not binding until the individual who
> tendered the Vote posts a followup message with the legend
> "[VOTE-RESULT]" summaring the replies. Any other Vote that receives any
> binding -1 reply (later withdrawn or not) must also post a
> "[VOTE-RESULT]" message to be binding.
I assume you mean that the [VOTE-RESULT] will be presented after all
-1 votes have been reversed (or deemed invalid). We discussed at the PMC
meeting what's needed for a -1 vote to be valid, and said that it must
be combined with an explanation. If a explanation is not presented, it's
invalid (so far, this is what's in the existing rules). If someone challenges
the reason, another person with voting rights must come forward and defend
the reason (it doesn't mean he/she have to agree with the veto, just that
it's a valid reason).
> All Votes receiving only +1 or
> +/-0 replies are subject to lazy approval. Any question regarding the
> outcome of a Vote may be refrerred by a Committer to the PMC for
> arbitration.
Sounds fine to me. The fact that PMC can break a veto (as the last resort)
was also discussed in the meeting.
> All votes by Committers should include the word "binding" next to their
> vote.
I don't see the need for this. According to the existing rules, any +1
vote from a Committer is binding. If a Committer approves of the action
but can not promise to spend time helping to implement it, it should be
a +0 vote instead. The wording of this may need to be clarified, but that's
what I read into the existing rules.
> When tendering a -1 vote on a Consensus item, a Committer should
> include the phrase "binding veto" next to their Vote, to make their
> intent clear.
Again, I don't think this is needed. A -1 means a veto (for the type
of votes that can be vetoed, consensus and items that are otherwise
handled by lazy approval).
> Persons wishing to discuss a Vote before replying, may open a
> "[VOTE-ISSUES]" thread, to help eliminate premature vetos.
Okay.
> Other Action Items
>
> When announcing their Short Term Plans or Long Term Plans, developers
> should include the legend "[ANN-action item]" in the subject line of
> their message to the Developers list.
>
> Proposals are not a formal Action Item, but should be labeled
> "[PROPOSAL]" in their subject line.
Do we need this distinction? Why not [PROPOSAL] for Short/Long Term
Plans as well?
> Action Item Voting Types
>
> Note "Lazy" means that is not required to tally the votes, unless a -1
> reply is posted. All votes are lazy except for a public Release vote.
>
> Long Term Plans - No vote required.
> Short Term Plans - No vote required.
> Release Plan - Lazy Majority vote on each issue.
We need to define "lazy majority" if we use it here. Why not require a
Majority Approval on the Release Plan? It is a major decision, since
it will set the path for the project for some time, and it's important
to see that there are enough Committers that promise to help implement
it.
> Release Testing - Consensus vote before public Release.
> Showstoppers - Lazy consensus until resolved and removed from status
> file.
> Product Change - Lazy consensus.
We need to define "lazy consensus" as well.
> >If the vote is about a change to the source code or documentation and
> the primary author is a Developer and not a Commiter, the primary
> author of what is being changed may also cast a binding vote on that
> issue.
>
> I would consider striking this phase, as I believe Committer status on
> Jakarta may be easier to get than on Apache, and there is less of a
> need for this exception.
Hmmm... My take on this paragraph is that it's there to make sure that
even a person who is not a Committer has a say about his contribution.
It has nothing to do with ASF membership.
> Another nit is that the all-important public release is not listed as
> an Action Item, although it is implied by the description of Release
> Plan and Showstoppers.
Agree. This should be fixed. Also, we need to define the Release Manager
role in the "Roles and Responsibilities" document.
Hans
--
Hans Bergsten hans@gefionsoftware.com
Gefion Software http://www.gefionsoftware.com
Author of JavaServer Pages (O'Reilly), http://TheJSPBook.com
Re: Release voting rules
Posted by Ted Husted <ne...@husted.com>.
[ I'm cross-posting this from the Tomcat-Dev list, per Hans Bergsten's
suggestion ]
On 1/17/2001 at 11:17 PM Craig R. McClanahan wrote:
> Many of those rules and conventions are documented (such as the rules
on voting), but some are not. One of the things I took away from the
PMC meeting yesterday is the need to better articulate those rules.
As a new committer to another Jakarata project, I personally think that
would be very helpful.
There seem to be many deep conventions in play here that I cannot find
in a reading of the ASF by-laws or the project guidelines. So far, the
only documentation I've found is <
http://jakarta.apache.org/site/guidelines.html > and <
http://www.apache.org/foundation/bylaws.html >. Apparently, there is
also a "Rules for Revolutionaries" document, but I haven't been able to
find it. (URL?)
Although I probably don't understand all the nuances of the "Apache
Culture", as a Jakarta Committer, here is a draft "patch" that I would
suggest to decisions.html (mostly parity-checks):
--
Voting
Any Developer or Committer may call for a Vote on the Developer mailing
list. It is preferred that a Vote be preceded by a formal proposal
offered for discussion purposes. A call for a formal Vote must contain
the legend "[VOTE-action item]" in its subject line, where "action
item" is Release Plan, Public Release, Showstopper, or Product Change.
A * Public Release * Vote is not binding until the individual who
tendered the Vote posts a followup message with the legend
"[VOTE-RESULT]" summaring the replies. Any other Vote that receives any
binding -1 reply (later withdrawn or not) must also post a
"[VOTE-RESULT]" message to be binding. All Votes receiving only +1 or
+/-0 replies are subject to lazy approval. Any question regarding the
outcome of a Vote may be refrerred by a Committer to the PMC for
arbitration.
All votes by Committers should include the word "binding" next to their
vote. When tendering a -1 vote on a Consensus item, a Committer should
include the phrase "binding veto" next to their Vote, to make their
intent clear.
Persons wishing to discuss a Vote before replying, may open a
"[VOTE-ISSUES]" thread, to help eliminate premature vetos.
Other Action Items
When announcing their Short Term Plans or Long Term Plans, developers
should include the legend "[ANN-action item]" in the subject line of
their message to the Developers list.
Proposals are not a formal Action Item, but should be labeled
"[PROPOSAL]" in their subject line.
Action Item Voting Types
Note "Lazy" means that is not required to tally the votes, unless a -1
reply is posted. All votes are lazy except for a public Release vote.
Long Term Plans - No vote required.
Short Term Plans - No vote required.
Release Plan - Lazy Majority vote on each issue.
Release Testing - Consensus vote before public Release.
Showstoppers - Lazy consensus until resolved and removed from status
file.
Product Change - Lazy consensus.
>If the vote is about a change to the source code or documentation and
the primary author is a Developer and not a Commiter, the primary
author of what is being changed may also cast a binding vote on that
issue.
I would consider striking this phase, as I believe Committer status on
Jakarta may be easier to get than on Apache, and there is less of a
need for this exception.
--
> that I will *not* veto a release plan for 3.3 that meets my concerns
about support)
Here's another place where it gets confusing. Technically, it seems
that we can't "veto" a Release Plan, since it is a Majority Vote.
(Though, you might be able to veto a specific issue, if it involved a
Product Change.) Someone could ultimately veto a public "Release" since
that is a Consensus Vote.
The cultural idea being, I guess, that this is a meritocracy, and
nothing can be binding until we have the actual code in front of us.
Another nit is that the all-important public release is not listed as
an Action Item, although it is implied by the description of Release
Plan and Showstoppers.
-- Ted Husted, Husted dot Com, Fairport NY USA.
-- Custom Software ~ Technical Services.
-- Tel 716 425-0252; Fax 716 223-2506.
-- http://www.husted.com/