+1 (non-binding)
These is a pretty clear codification of what I've seen as the actual
behaviour of this group.
Christian.
On May 27, 2010, at 1:56 PM, Ulrich Stärk wrote:
I believe that it is a good idea to give us some guidelines,
document how we work, what roles there are in our community and
generally make some things more transparent that were formerly only
known as hearsay or documented in different places.
The document attached below is the result we came up with. If the
vote is successful, the Tapestry project will give itself the
following bylaws. Concensus vote to run for 72 hours.
Ulrich Stärk: +1 (non-binding)
Introduction
The Tapestry Project Management Committee is the governing body of
the Apache Tapestry project. The PMC as a whole controls the project
by being responsible for the direction and the success of the
project. The chairperson of the PMC is also a Vice President of the
Apache Software Foundation and serves as an interface between the
Board of Directors and the project. The current chairman is Howard
Lewis Ship. A list of the current PMC members and committers can be
found [here].
Roles
Everybody can help, regardless of their role. We differentiate roles
inside the Tapestry community by how committed people are to the
project, how much they have contributed and how well they have
proven to be able to collaborate with the rest of the community.
Long term community members with a backlog of valuable contributions
may obtain the right to commit to the source code repository and vote.
Users
This group is by far the largest and most important one. Users are
the actual users of the Tapestry framework. Without the users there
would be no Tapestry project. Users use our product, ask and answer
questions on the mailing lists and submit bug reports and feature
requests.
Contributors
Contributors are users that contribute to the project in the form of
patches and documentation. They are also participating in
discussions on the developer mailing list and are providing
suggestions and criticism.
Committers
If a contributor contributes frequently to the project he may be
granted write access to the source code repository. In order for a
contributor to become a committer, any other committer may nominate
him or the contributor himself may ask for it, resulting in a vote.
If there are at least 3 binding positive votes and no binding
negative vote (concensus vote), the contributor is converted into a
committer. If a committer doesn't participate in the project anymore
and shows so by not posting to the mailing lists for 6 months or
more, his write access to the source code repository will be
revoked. It may be re-requested at any point in the future by
writing an email to the developer mailing list.
PMC Members
A committer that has proven to be truely committed to the project
and has proven to be able to work well together with the rest of the
developer community, especially in conflict situations, may be
invited to become part of the Project Management Committee. Every
PMC member may nominate a committer to become a PMC member. The
nominee has to be approved by a concensus vote (i.e. at least 3
binding +1 votes, no binding vetos). A PMC member may resign from
his position at any time, maintaining his status as a committer. PMC
members may also be removed from the PMC by a 3/4 concensus vote
(i.e. at least 3 binding +1 votes and at least 3/4 of all binding
votes, no binding vetos). If a PMC member doesn't participate in the
project anymore and shows so by not posting to the mailing lists for
6 months or more, his status is converted to that of a committer.
PMC Chair
The chairperson of the PMC serves as a liaison to the Board of
Directors of the ASF. The PMC chair is elected with a 3/4 concensus
vote and may resign from his position at any time, maintaining his
status as a PMC member.
Decision Making
Decisions are made by voting. Votes are expressed as numbers with +1
meaning 'yes', 0 meaning 'I don't agree but I also won't veto it' or
'I don't have an opinion' and -1 meaning 'no' and in some cases
representing a veto. We differentiate two kinds of votes and three
kinds of voting styles.
Votes: Binding votes are votes cast by members of the PMC. They are
the ones that count since it is the PMC that governs the project and
answers to the Board of Directors. Votes by committers and
contributors are non-binding and are indicative or advisory.
Voting styles:
Majority vote: There are at least 3 binding +1 votes and more +1
than -1 votes.
Concensus vote: There are at least 3 binding +1 votes and no binding
veto (-1). If a veto is cast, the person casting it has to
immediately explain the reason for his veto. An unexplained veto is
invalid. A veto cannot be overruled.
Lazy concensus: If there are no objections against a decision within
a given period, the decision counts as accepted
Votes may be changed during the voting period.
When to vote with what voting style
A change to the codebase or the documentation, i.e. a commit message
or a wiki diff message on the developer mailing list automatically
triggers a lazy consensus vote. If there are no objections within 72
hours, the change counts as agreed on.
Changes to the codebase affecting backwards compatibility or
altering the current expected behaviour of the product should be
discussed on the developer mailing list first and should be voted on
with a majority vote. The same holds for major changes to the
codebase that don't affect the user.
Committers and PMC members will be voted in as explained above.
A release always requires a concensus vote.
Changes to this document need a 3/4 concensus vote (i.e. at least 3
binding +1 votes and at least 3/4 of all binding votes, no binding
vetos).
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
