Mailing-List: contact general-help@logging.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Logging General" <general@logging.apache.org>
Received-SPF: neutral (herse.apache.org: local policy)
Mime-Version: 1.0 (Apple Message framework v752.3)
Content-Transfer-Encoding: 7bit
Message-Id: <7CE065D3-809C-44B1-A1E5-901A791491BB@apache.org>
Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed
To: Logging General <general@logging.apache.org>
From: Curt Arnold <carnold@apache.org>
Subject: Changing or repealing the Logging Services bylaws
Date: Thu, 8 Feb 2007 12:27:44 -0600

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.