Mailing-List: contact dev-help@community.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@community.apache.org
Received-SPF: pass (nike.apache.org: local policy)
Message-Id: <1392055524.8606.81644465.0F751D2A@webmail.messagingengine.com>
From: Upayavira <uv@odoko.co.uk>
To: dev@community.apache.org
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Type: text/plain
In-Reply-To: 
 <CALhtWkc7pT+SrrUuoZps0kg7GiMLLgkkJsWPbm5chCsoHXdD4A@mail.gmail.com>
References: <CF1E6B97.302C1%rvesse@dotnetrdf.org>
 <DC7867C7-8B23-4E66-8587-39C74B11B3B1@jaguNET.com>
 <CALhtWkc7pT+SrrUuoZps0kg7GiMLLgkkJsWPbm5chCsoHXdD4A@mail.gmail.com>
Subject: Re: How can we support a faster release cadence?
Date: Mon, 10 Feb 2014 18:05:24 +0000


On Mon, Feb 10, 2014, at 01:48 PM, Benson Margulies wrote:
> On Mon, Feb 10, 2014 at 8:36 AM, Jim Jagielski <jim@jagunet.com> wrote:
> >
> > On Feb 10, 2014, at 6:50 AM, Rob Vesse <rvesse@dotnetrdf.org> wrote:
> >> With a large enough PMC likely there will be enough active people to
> >> obtain the necessary +1's in the 12hr window regardless of a few people
> >> being unavailable
> >
> > A concern is that if the same person is RM, and the vote is always
> > done at the same time (and so the 12 hour window never shifts, time-
> > wise) then the vote will *always* favor those who are in the
> > timezone of that vote.
> >
> > One reason for the 72hour rule is to ensure that no PMC
> > member feels disenfranchised... not all PMC members are in
> > the same timezone and not all PMC members should be assumed
> > to be paid to work on the code (and thus available 24/7
> > as it were). Longer vote times handle those cases.
> >
> > PMCs are *inclusive*. The processes and procedures are
> > designed to maintain that inclusivity.
> >
> 
> A PMC will only adopt this procedure if it *inclusively* decides to
> adopt this procedure. if PMC members feel excluded from the release
> decision-making process, they can bring it to a halt at the process
> level. A project can adopt a policy rotating the RM role around the
> globe. Any PMC member can add any automated test that stops the
> process if his or her testing concerns are not met.
> 
> In other words, an automated process can still allow for completely
> inclusive participation.

What you are proposing is inclusive of current PMC members, but
potentially exclusive of future PMC members. It could create a
self-selecting system that quietly excludes folks who are unfortunate
enough to live in the wrong timezone, or work the wrong hours. Any
voting mechanism needs to be sufficiently flexible to suit current and
future PMC members, regardless of timezone/etc.

Upayavira