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]
