Changing or repealing the Logging Services bylaws

[Curt Arnold <ca...@apache.org>]

The current Logging Services bylaws effectively make the project an  
umbrella covering several self-governing subprojects (log4j,  
log4cxx, ...).  The current bylaws mandate a two-stage vote for many  
actions, an advisory vote at the subproject level followed by a  
binding vote at the PMC level.  For the log4j subproject, the two  
stage vote is a time-consuming annoyance as the PMC and log4j  
committers are very close to being the same set of people.  For  
log4cxx and log4net, reaching a quorum for the advisory vote can be  
at least an obstacle.  For chainsaw, it has resulted in a weird  
hybrid where chainsaw has its own project in the SVN and releases,  
but is part of the log4j project for quorum issues (and potentially  
other issues).  In addition, there are some definitions in the bylaws  
(IIRC some of the voting definitions) that conflict with other  
definitions in more authoritative Apache documents.

There have been previous discussions on bylaw changes to address  
these issues, for example on general@logging.apache.org on 2005-07-01  
(http://marc.theaimsgroup.com/?l=apache-logging- 
general&m=112024592311861&w=2) which referenced earlier discussion on  
the private pmc list, but there was no action taken.

The Board Resolution forming the LS PMC mandated the initial PMC  
create a set of bylaws for the project (http://logging.apache.org/ 
site/mission-statement.html).  The term "guidelines" appears to be  
currently preferred for project level statements to avoid the legal  
implications of bylaws.  For example, the ASF Bylaws (http:// 
www.apache.org/foundation/bylaws.html) are a legal document that  
governs the corporation and has to conform to corporate governance  
laws in the State of Delaware.

Section 6.3 of the ASF Bylaws (http://www.apache.org/foundation/ 
bylaws.html) places responsibility to establish rules and procedures  
on the PMC chair.

There was an discussion on general@incubator.apache.org on 2005-09-12  
that discussed the confusing state of ASF project bylaws (http:// 
thread.gmane.org/gmane.comp.apache.incubator.general/6144/focus=6147).

I thought that I recently saw a thread on  
general@incubator.apache.org that argued against projects having  
bylaws (or guidelines) of their own as the ASF bylaws and other  
documents were sufficient, but unfortunately I have not been able to  
find that thread.

I would like to take steps that result in:

The LS project to be a single project with any number of products.

The PMC being the only decision making body.

Either no project guideline document or one that heavily defers to,  
not duplicate or conflict with, http://www.apache.org documents.

A set of evolving process documents that describe best practices on  
the project.

I would appreciate comments and will try to work on a draft.  A board  
report is due for the Feb 21st meeting.  It would be great to get  
this and several other issues resolved in the next week or so in  
order to clear out some long pending issues.

Re: Changing or repealing the Logging Services bylaws

[Boris Unckel <bo...@gmx.net>]

Hi,

Curt Arnold wrote:

> > I would like to take steps that result in:
> >
> > The LS project to be a single project with any number of products.
> >
> > The PMC being the only decision making body.
> >
> > Either no project guideline document or one that heavily defers to, 
> > not duplicate or conflict with, http://www.apache.org documents.
> >
> > A set of evolving process documents that describe best practices on 
> > the project.
> >
> > I would appreciate comments and will try to work on a draft.  A board 
> > report is due for the Feb 21st meeting.  It would be great to get this 
> > and several other issues resolved in the next week or so in order to 
> > clear out some long pending issues.
> >
>   
+1
Keep it simple, reduce bureaucracy.

Regards
Boris

Re: Changing or repealing the Logging Services bylaws

[Curt Arnold <ca...@apache.org>]

On Feb 8, 2007, at 12:27 PM, Curt Arnold wrote:

>
> I thought that I recently saw a thread on  
> general@incubator.apache.org that argued against projects having  
> bylaws (or guidelines) of their own as the ASF bylaws and other  
> documents were sufficient, but unfortunately I have not been able  
> to find that thread.
>

Thilo Goetz provided this link to the vaguely remembered discussion  
on general@incubator: http://www.mail-archive.com/ 
general@incubator.apache.org/msg11758.html

Re: Changing or repealing the Logging Services bylaws

[Curt Arnold <ca...@apache.org>]

There does not appear to be sufficient interest to pursue discussion  
at this time (as has been the case other times the subject has been  
brought up).    I've proposed a "Uniform Project Policies" effort on  
general@incubator (http://mail-archives.apache.org/mod_mbox/incubator- 
general/200702.mbox/%3cFBC89A4F-07F2-4D32-A02C-3E3686500D79@apache.org 
%3e) that would create a base set of project policies that a project  
(existing or incubating) could (hopefully) adopt in whole or  
customize (if necessary).  If that project succeeds (huge if), then I  
would expect to request a vote for Logging Services to replace the  
current bylaws with the Uniform Project Policies.  Until then or some  
other significant change, I'm dropping the subject.

Re: Changing or repealing the Logging Services bylaws

[Curt Arnold <ca...@apache.org>]

On Feb 8, 2007, at 2:43 PM, Ceki Gülcü wrote:

>
> If I understand correctly, the idea is to circumvent the quorum
> requirement, i.e. collecting three +1 votes, so that the Logging TLP
> can vote instead of the people who are actually familiar with the
> work?


 From http://www.apache.org/foundation/voting.html
> Binding Votes:
>
> Who is permitted to vote is, to some extent, a community-specific  
> thing. However, the basic rule is that only PMC members have  
> binding votes, and all others are either discouraged from voting  
> (to keep the noise down) or else have their votes considered of an  
> indicative or advisory nature only.
>
> That's the general rule. In actual fact, things tend to be a little  
> looser, and procedural votes from developers and committers are  
> sometimes considered binding if the voter has acquired enough merit  
> and respect in the community. Only votes by PMC members are  
> considered binding on code-modification issues, however.
 From http://www.apache.org/foundation/how-it-works.html#structure

>
> The role of the PMC from a Foundation perspective is oversight. The  
> main role of the PMC is not code and not coding - but to ensure  
> that all legal issues are addressed, that procedure is followed,  
> and that each and every release is the product of the community as  
> a whole. That is key to our litigation protection mechanisms.

 From http://www.apache.org/dev/release.html

> Releases are, by definition, anything that is published beyond the  
> group that owns it. In our case, that means any publication outside  
> the group of people on the product dev list. If the general public  
> is being instructed to download a package, then that package has  
> been released. Each PMC must obey the ASF requirements on approving  
> any release. How you label the package is a secondary issue,  
> described below.


Each of those makes the PMC responsible for releases.  The PMC must  
vote on a release and while it definitely should take in to  
consideration any vote or opinion by non-PMC committers or community  
members, it can't delegate responsibility for ensuring that the  
release follows ASF requirements and licensing guidelines.  If a PMC  
member is not familiar with the work and have not checked it for  
sanity and legal issues, they should not vote on a release.   
Requiring a two-stage vote (once at the subproject level and once at  
the PMC level), either adds an almost identical vote (in log4j's case  
where the PMC and log4j committers are very close to the same set of  
people) or delays general PMC review of a release until 72 hours  
after the build has been proposed on a subproject where only a few  
PMC members are active.  Either situation can be addressed by either  
calling the PMC and project votes simultaneously or by PMC members  
joining a subproject vote, however those are ugly, but effective,  
hacks.  The two-stage vote in my opinion adds complexity without a  
corresponding benefit.


>
>>  For chainsaw, it has resulted in a weird
>> hybrid where chainsaw has its own project in the SVN and releases,
>> but is part of the log4j project for quorum issues (and potentially
>> other issues).
>
> That was by volition of Scott and Paul. At the time, I invited
> them to form a separate project and they declined. You should perhaps
> ask Scott and Paul whether they would like to become a separate
> sub-project.

Hopefully they are subscribed to this list and will participate in  
the thread.


>
>> In addition, there are some definitions in the bylaws
>> (IIRC some of the voting definitions) that conflict with other
>> definitions in more authoritative Apache documents.
>
> There ASF is based on delegation. Therefore, as long as the LS bylaws
> are in agreement with rules of the ASF, they are authoritative as far
> as the LS TLP is concerned.

The Foundation glossary defines "Lazy Approval" and "Lazy Consensus"  
as synonyms while the LS Bylaws has them as distinct terms with "Lazy  
Consensus" with a similar definition as "Consensus Approval".

http://www.apache.org/foundation/glossary.html#ConsensusApproval
http://www.apache.org/foundation/glossary.html#LazyConsensus

If the bylaws are modified, it would be good to change occurrences of  
"Lazy Consensus" to "Consensus Approval" to be consistent with other  
ASF projects.


>
>> There have been previous discussions on bylaw changes to address
>> these issues, for example on general@logging.apache.org on 2005-07-01
>> (http://marc.theaimsgroup.com/?l=apache-logging-  
>> general&m=112024592311861&w=2) which referenced earlier discussion on
>> the private pmc list, but there was no action taken.
>>
>> The Board Resolution forming the LS PMC mandated the initial PMC
>> create a set of bylaws for the project (http://logging.apache.org/  
>> site/mission-statement.html).  The term "guidelines" appears to be
>> currently preferred for project level statements to avoid the legal
>> implications of bylaws.  For example, the ASF Bylaws (http://  
>> www.apache.org/foundation/bylaws.html) are a legal document that
>> governs the corporation and has to conform to corporate governance
>> laws in the State of Delaware.
>
> The LS bylaws (see http://logging.apache.org/site/bylaws.html )
> mentions the word "guideline" once.

The point was that the term "bylaws" has specific legal connotations  
and recent board discussions had preferred using the term  
"guidelines" for PMC level documents and reserving the "bylaws" term  
for the ASF bylaws which is a legal document.


>
>> Section 6.3 of the ASF Bylaws (http://www.apache.org/foundation/  
>> bylaws.html) places responsibility to establish rules and procedures
>> on the PMC chair.
>
> The foundation bylaws mandates the project chairman to establish
> project bylaws. However, once the bylaws are established, they should
> not and cannot be changed at the whim of one person. We already have
> bylaws. They can be changed as long as there is a 2/3 majority of the
> active PMC members. The 2/3 rule is there precisely to prevent the
> chairman from making arbitrary changes.
>
> Are you suggesting that the chairman has the power to change the LS
> project bylawys without approval of the PMC?
>

This reference was provided for background material on project  
governance.  It was not a threat of unilateral action.


>
>> There was an discussion on general@incubator.apache.org on 2005-09-12
>> that discussed the confusing state of ASF project bylaws (http://  
>> thread.gmane.org/gmane.comp.apache.incubator.general/6144/ 
>> focus=6147).
>>
>> I thought that I recently saw a thread on
>> general@incubator.apache.org that argued against projects having
>> bylaws (or guidelines) of their own as the ASF bylaws and other
>> documents were sufficient, but unfortunately I have not been able to
>> find that thread.
>
> As an open group, people are welcome to argue for or against any
> topic. The existence of a con argument does not mean it should be
> adopted here.

I was trying to enumerate all the pertinent discussions that could  
inform our discussion.  Unfortunately, I was unable to find a  
reference, but thought a description of the thread might be enough  
for someone else to fill in the details.


>
>> I would like to take steps that result in:
>>
>> The LS project to be a single project with any number of products.
>>
>> The PMC being the only decision making body.
>>
>> Either no project guideline document or one that heavily defers to,
>> not duplicate or conflict with, http://www.apache.org documents.
>>
>> A set of evolving process documents that describe best practices on
>> the project.
>>
>> I would appreciate comments and will try to work on a draft.  A board
>> report is due for the Feb 21st meeting.  It would be great to get
>> this and several other issues resolved in the next week or so in
>> order to clear out some long pending issues.
>
> The idea behind the current structure is to delegate responsibility to
> the people actually doing the work. I still think that delegation is
> one of the core tenets of the ASF. Thus, after a given LS sub-project
> votes, and then makes a recommendation to the PMC, the PMC is very
> likely to endorse the recommendation. As far as I know, the LS PMC has
> always endorsed recommendations made by sub-projects.
>
> Instead of undoing the existing bylaws, I would suggest to expedite
> the PMC voting process. Moreover, nothing prevents a sub-project from
> granting committer access to an existing PMC member (hence mitigating
> the difficulty of reaching quorum.)

Thanks for your comments.

Re: Changing or repealing the Logging Services bylaws

[Ceki Gülcü <ce...@qos.ch>]

At 07:27 PM 2/8/2007, Curt Arnold wrote:
>The current Logging Services bylaws effectively make the project an
>umbrella covering several self-governing subprojects (log4j,
>log4cxx, ...).  The current bylaws mandate a two-stage vote for many
>actions, an advisory vote at the subproject level followed by a
>binding vote at the PMC level.  For the log4j subproject, the two
>stage vote is a time-consuming annoyance as the PMC and log4j
>committers are very close to being the same set of people.  For
>log4cxx and log4net, reaching a quorum for the advisory vote can be
>at least an obstacle.

If I understand correctly, the idea is to circumvent the quorum
requirement, i.e. collecting three +1 votes, so that the Logging TLP
can vote instead of the people who are actually familiar with the
work?

>  For chainsaw, it has resulted in a weird
>hybrid where chainsaw has its own project in the SVN and releases,
>but is part of the log4j project for quorum issues (and potentially
>other issues).

That was by volition of Scott and Paul. At the time, I invited
them to form a separate project and they declined. You should perhaps
ask Scott and Paul whether they would like to become a separate
sub-project.

>In addition, there are some definitions in the bylaws
>(IIRC some of the voting definitions) that conflict with other
>definitions in more authoritative Apache documents.

There ASF is based on delegation. Therefore, as long as the LS bylaws
are in agreement with rules of the ASF, they are authoritative as far
as the LS TLP is concerned.

>There have been previous discussions on bylaw changes to address
>these issues, for example on general@logging.apache.org on 2005-07-01
>(http://marc.theaimsgroup.com/?l=apache-logging- 
>general&m=112024592311861&w=2) which referenced earlier discussion on
>the private pmc list, but there was no action taken.
>
>The Board Resolution forming the LS PMC mandated the initial PMC
>create a set of bylaws for the project (http://logging.apache.org/ 
>site/mission-statement.html).  The term "guidelines" appears to be
>currently preferred for project level statements to avoid the legal
>implications of bylaws.  For example, the ASF Bylaws (http:// 
>www.apache.org/foundation/bylaws.html) are a legal document that
>governs the corporation and has to conform to corporate governance
>laws in the State of Delaware.

The LS bylaws (see http://logging.apache.org/site/bylaws.html )
mentions the word "guideline" once.

>Section 6.3 of the ASF Bylaws (http://www.apache.org/foundation/ 
>bylaws.html) places responsibility to establish rules and procedures
>on the PMC chair.

The foundation bylaws mandates the project chairman to establish
project bylaws. However, once the bylaws are established, they should
not and cannot be changed at the whim of one person. We already have
bylaws. They can be changed as long as there is a 2/3 majority of the
active PMC members. The 2/3 rule is there precisely to prevent the
chairman from making arbitrary changes.

Are you suggesting that the chairman has the power to change the LS
project bylawys without approval of the PMC?


>There was an discussion on general@incubator.apache.org on 2005-09-12
>that discussed the confusing state of ASF project bylaws (http:// 
>thread.gmane.org/gmane.comp.apache.incubator.general/6144/focus=6147).
>
>I thought that I recently saw a thread on
>general@incubator.apache.org that argued against projects having
>bylaws (or guidelines) of their own as the ASF bylaws and other
>documents were sufficient, but unfortunately I have not been able to
>find that thread.

As an open group, people are welcome to argue for or against any
topic. The existence of a con argument does not mean it should be
adopted here.

>I would like to take steps that result in:
>
>The LS project to be a single project with any number of products.
>
>The PMC being the only decision making body.
>
>Either no project guideline document or one that heavily defers to,
>not duplicate or conflict with, http://www.apache.org documents.
>
>A set of evolving process documents that describe best practices on
>the project.
>
>I would appreciate comments and will try to work on a draft.  A board
>report is due for the Feb 21st meeting.  It would be great to get
>this and several other issues resolved in the next week or so in
>order to clear out some long pending issues.

The idea behind the current structure is to delegate responsibility to
the people actually doing the work. I still think that delegation is
one of the core tenets of the ASF. Thus, after a given LS sub-project
votes, and then makes a recommendation to the PMC, the PMC is very
likely to endorse the recommendation. As far as I know, the LS PMC has
always endorsed recommendations made by sub-projects.

Instead of undoing the existing bylaws, I would suggest to expedite
the PMC voting process. Moreover, nothing prevents a sub-project from
granting committer access to an existing PMC member (hence mitigating
the difficulty of reaching quorum.)



-- 
Ceki Gülcü
Logback: The reliable, generic, fast and flexible logging framework for Java.
http://logback.qos.ch