On Thu, Dec 13, 2012 at 3:23 PM, Joe Brockmeier <j...@zonker.net> wrote: > On Wed, Dec 12, 2012 at 09:30:45PM -0500, Chip Childers wrote: >> Hi all, >> >> I'd like to start a conversation about our project bylaws. This is >> something that an Apache project doesn't absolutely require, but I >> believe that some of the larger TLP's have found it to be valuable. >> 1.3. CloudStack is typical of Apache projects in that it operates >> under a set of principles, known collectively as the "Apache Way". If >> you are new to Apache development, please refer to the Incubator >> project for more information on how Apache projects operate. > > I'd remove "is typical of Apache projects in that it" and simply say > "CloudStack operates under a set of principles..." > > The other way implies that some projects don't operate under the Apache > Way, which I don't believe to be the case. >
OK >> 2.1. Users >> >> The most important participants in the project are people who use our >> software. Users contribute to the Apache projects by providing >> feedback to developers in the form of bug reports and feature >> suggestions. > > OK > >> As well, users participate in the Apache community by >> helping other users on mailing lists and user support forums. > > I'd argue that users who participate in the community by assisting other > users in any medium are contributors, not merely users. (Which also is > reflected below.) > > Maybe add something like: > > "The majority of contributors start as users, and their experiences as > users guide their contributions and level of interest in the project. We > believe that a healthy community begins with keeping the user's > interests in mind." > That's good. Sebastian is suggesting we keep the user role, so perhaps that sentiment gets added to the user role description. >> 2.2. Contributors >> >> Contributors are all of the volunteers who are contributing time, >> code, documentation, or resources to the CloudStack Project. A >> Contributor that makes sustained, welcome contributions to the project >> may be invited to become a Committer, though the exact timing of such >> invitations depends on many factors. The form of contribution is not >> limited to code. It can also include code review, helping out users on >> the mailing lists, documentation, testing, etc. > > s/etc./and numerous other activities that help promote and improve the > Apache CloudStack project and community. > OK >> 2.3. Committers >> >> The project's Committers are responsible for the project's technical >> management. Committers have access to all project source control >> repositories. Committers may cast binding votes on any technical >> discussion regarding the project (or any sub-project). >> >> 2.3.1. Committer access is by invitation only and must be approved by >> a majority consensus of the active PMC members. A Committer is >> considered emeritus by their own declaration or by not contributing in >> any form to the project for over six months. An emeritus committer may >> request reinstatement of commit access from the PMC. Such >> reinstatement is subject to lazy consensus of active PMC members. > > Is this automatic? e.g., if someone doesn't contribute for six months > and comes back in July next year, do they have to request access, or is > this just a general guideline? > IMO, it would be a general guideline that the PMC would have to take action to execute. Does anyone else have on opinion on this? >> 2.4.3. The chair of the PMC is rotated annually. When the chair is >> rotated or if the current chair of the PMC resigns, the PMC votes to >> recommend a new chair using Single Transferable Vote (STV) voting. See >> http://wiki.apache.org/general/BoardVoting for specifics. The decision >> must be ratified by the Apache board. > > Is a chair eligible for consecutive terms if the PMC wants to re-appoint > the chair for a second term (and the chair is willing)? David suggested removing this, and I agree. It was an editing mistake from my initial pass modifying the Hadoop bylaws to work for CloudStack. Any objections to removing it? > >> Formal votes are open for a period of at least 72 hours to allow all >> active voters time to consider the vote. > > Do we wish to put any parameters around "72 hours" (e.g., > exclude/include holidays, weekends, etc.? Calling a vote, say, the day > before U.S. Thanksgiving may preclude reasonable participation. Yes, > that's a corner case, but I wanted to bring it up...) > "at least" seems to be enough for most projects to understand the importance of giving people enough time to voice their opinions. I'm hesitant to include specific exceptions, and would rather leave it up to the person that calls a vote to act in the best interests of the community. Does this work for others? > Best, > > jzb > -- > Joe Brockmeier > http://dissociatedpress.net/ > Twitter: @jzb >
