incubator-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Roy T. Fielding" <field...@gbiv.com>
Subject Re: Apache project bylaws
Date Wed, 02 Oct 2013 18:11:16 GMT
On Oct 2, 2013, at 10:20 AM, Alex Harui wrote:
> On 10/2/13 10:09 AM, "Doug Cutting" <cutting@apache.org> wrote:
> 
>> On Wed, Oct 2, 2013 at 9:49 AM, Alex Harui <aharui@adobe.com> wrote:
>>> To me, agreeing on "the norm" is not the same as policy, especially
>>> policy
>>> that does not allow for exceptions.
>> 
>> I agree.  Establishing whether there is a norm is a useful first step.
>> That's what I'm trying to take.  Thus far I've seen noone disagree
>> that consensus is most common for committer additions at Apache.  I've
>> also seen folks suggest that they prefer having norms than having
>> explicit bylaws for their projects.  I don't anticipate any policy
>> being established as a result of this discussion, except perhaps
>> better documenting what the assumed default is for projects that don't
>> choose to have explicit bylaws.
>> 
>>> And again, to me, "consensus != unanimity".
>> 
>> This might be another case where better documentation would help.  In
>> my experience at Apache, consensus is equated with unanimity.
> In my tour of the internet since my last post and your reply, it does
> appear that most Apache-related information indicates that committer
> voting uses consensus and thus the Voting document [1] is out of date.

It isn't out of date.  It is just plain wrong.  It does not reflect any
of our projects, but rather presents an incomplete summary based on
someone's personal experience.  It is difficult to do better than that
without having a universal set of project bylaws.

Apache doesn't have a single set of project bylaws/guidelines because
we want projects to be self-governing.  Inherent in that notion of
self-governing is that projects need to have the freedom to do some
things differently based on the nature of the project or the particular
set of individuals involved.  By some things, I mean things that are
not necessarily constrained by the ASF need to maintain corporate oversight
(which is almost entirely encompassed by release votes and the procedure
for naming someone to the PMC).

Hence, we don't have a single policy for how or when to make someone
a committer.  That is supposed to be defined by the project.

Most people just assume that there exists a magic set of bylaws that
are adopted if a given project just doesn't care (like most don't care,
until the shit hits the fan and it is too late).  For those projects,
we typically assume that they have adopted the HTTP Server Project
Guidelines, since those were the originals:

http://httpd.apache.org/dev/guidelines.html

> I found this link as well [2].  I'd be tempted to replace the Voting
> document [1] with this [2], although I'm not sure I understand the
> difference between "consensus" and "unanimous consensus".  Your thoughts?

Consensus is that everyone who shares an opinion agrees to a common
resolution (even if they do not personally prefer that resolution).
Unanimity means that everyone present agrees (for a PMC discussing
things in email, that means everyone listed on the roster must
affirmatively agree).

Hence, consensus decisions can be vetoed, as is clearly stated in
the HTTP Server Project Guidelines, unless the project has decided
to adopt some other set of bylaws.

....Roy

> [1] http://www.apache.org/foundation/voting.html
> [2] http://www.oss-watch.ac.uk/resources/meritocraticGovernanceVoting
> 
> -Alex

---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org


Mime
View raw message