Introduction
The Java Apache Project is a volunteer effort to provide open source Java software. The
project is a container for other subprojects and allows everybody to contribute with any
kind of useful resources. This document provides the constitution, the guidelines
to ease the management of the human resources in a highly democratic and meritocratic way.
Unlike other open source projects where an individual rules the project as a benevolent
dictator, the Java Apache Project form is government is based on merit: everyone who
deserves it get the right to vote and everyone who is able to vote partecipates in the
ruling of the project. This kind of government helps in maintaining the project going even
when core individuals leave the project or don't have enough time. The project itself is
like the ancient Greek Agora idea, where everybody helps and who deserves it decide. This
meritocracy allows the project to be very flexible toward people presence and allows fast
and safe changes in the core group since who decides is always who is more involved and
cares the most. This document itself is somehow a starting point and will be progressively
refined to become a successful model of management engineering.
Categories
Even if the Java Apache Project is highly democratic and allows everybody to subscribe
and join the mail lists, we identify several contribution categories, each of them of
equal importance, but different powers. The categories are identifies by their members:
- passive users only listen on the mail lists to learn without
stepping in the way. We invite every passive user to become an active one after feeling
ready for it.
- active users listen and respond. Learn from others and teach
others something they know (problems they had and how to work around them, bug reports,
feature requests and so on). This category doesn't contribute any code but is equally
important for finding bugs and to keep the project with feet on the ground. By committing
code patches, active users become developers..
- developers write code patches or contribute to the project in
some other ways (documentation, scripts, other resources). Either if your contribution is
accepted as it is or it's improved by others, you get credits for your work if you deserve
it.
- active developers are those developers who give more than one
significant contribution or show enough interest in continuing the development of some
part of the project and ask to become one. At this time, your request is taken into
consideration and voted by the others active developers, if nobody is against it, you will
be given write access to the CVS repository and you will be able to vote and rule the
project.
- passive developers are those active developers who left the
project or did not contribute code, votes, mails or any other resource for at least half a
year. Passive developers are considered out of the project but they CVS access is never
restricted unless the person asks for it or no active developer is against this in a
formal voting.
Voting
Like the ancient agora, every active member who deserves it has the right to vote. Each
vote can be made in one of three flavors (following Apache style):
- +1 Yes, agree, or the action should be performed. On
some issues, this vote is only binding if the voter has tested the action on their own
system(s).
- ±0 Abstain, no opinion, or I am happy to let the
other group members decide this issue. An abstention may have detrimental effects if too
many people abstain.
- -1 No. On issues where consensus is required, this
vote counts as a veto. All vetoes must include an explanation of why the veto is
appropriate. A veto with no explanation is void. No veto can be overruled. If you disagree
with the veto, you should lobby the person who cast the veto. Voters intending to veto an
action item should make their opinions known to the group immediately, so that the problem
can be remedied as early as possible.
An action item requiring consensus approval must receive at least 3 binding +1
votes and no vetoes. An action item requiring majority approval must receive at least 3
binding +1 votes and more +1 votes than -1 votes (i.e., a majority with a minimum
quorum of three positive votes). All other action items are considered to have lazy
approval until someone votes -1, after which point they are decided by either consensus or
a majority vote, depending upon the type of action item.
The act of voting carries certain obligations because voting members are not only
stating their opinion, they are agreeing to help on the voted issue. Since we are all
volunteers, members often become inactive for periods of time in order to take care of
their "real jobs" or devote more time to other projects. It is therefore
unlikely that the entire group membership will vote on every issue. To account for this,
all voting decisions are based on a minimum quorum.
Every active developer may request a voting on an issue sending a message with a Subject
beginning with [VOTE]
Types of Action Items
- Long Term Plans
- Long term plans are simply announcements that group members are working on particular
issues related to the Apache software. These are not voted on, but group members who do
not agree with a particular plan, or think an alternate plan would be better, are
obligated to inform the group of their feelings. In general, it is always better to hear
about alternate plans prior to spending time on less adequate solutions.
- Short Term Plans
- Short term plans are announcements that a developer is working on a particular set of
documentation or code files, with the implication that other developers should avoid them
or try to coordinate their changes. This is a good way to proactively avoid conflict and
possible duplication of work.
- Release Plan
- A release plan is used to keep all the developers aware of when a release is desired,
who will be the release manager, when the repository will be frozen in order to create the
release, and assorted other trivia to keep us from tripping over ourselves during the
final moments. Lazy majority decides each issue in the release plan.
- Release Testing
- After a new release is built, colloquially termed a tarball/zipball, it must be tested
before being released to the public. Majority approval is required before the
tarball/zipball can be publicly released.
- Showstoppers
- Showstoppers are issues that require a fix be in place before the next public release.
An issue becomes a showstopper when it is considered such by an active developer and
remains so by lazy consensus.
- Product Changes
- All changes, including code and documentation, will appear as action items under several
categories corresponding to the change status:
- concept/plan An idea or plan for a change. Votes are being requested
early so as to uncover conflicts before too much work is done.
- proposed patch A specific set of changes to the current product in the
form of input to the patch command (a diff output).
- committed change A one-line summary of a change that has been committed
to the repository since the last public release.
All product changes to the currently active repository are subject to lazy consensus.
All product changes to a prior-branch (old version) repository require consensus before
the change is committed.
Committing
Ideas must be reviewed-then-committed; patches can be committed-then-reviewed. With a
commit-then-review process, we trust that the developer doing the commit has a high degree
of confidence in the change. Doubtful changes, new features, and large-scale overhauls
need to be discussed before being committed to a repository. Any change that affects the
semantics of arguments to configurable directives, significantly adds to the runtime size
of the program, or changes the semantics of an existing API function must receive
consensus approval on the mailing list before being committed.
Each developer is responsible for notifying the appropriate mail list when they have an
idea for a new feature or major change to propose for the product. The distributed nature
of the Java Apache Project requires an advance notice of 48 hours in order to properly
review a major change -- consensus approval of either the concept or a specific patch is
required before the change can be committed. Note that a member might veto the concept
(with an adequate explanation), but later rescind that veto if a specific patch satisfies
their objections. No advance notice is required to commit singular bug fixes.
Related changes should be committed as a group, or very closely together.
Half-completed projects should not be committed unless doing so is necessary to pass the
baton to another developer who has agreed to complete the project in short order. All code
changes must be successfully compiled on the developer's platform before being committed.
The current source code tree should be capable of complete compilation at all times.
However, it is sometimes impossible for a developer on one platform to avoid breaking some
other platform when a change is committed, particularly when completing the change
requires access to a special development tool on that other platform. If it is anticipated
that a given change will break some other platform, the committer must indicate that in
the commit log.
The committer is responsible for the quality of any third-party code or documentation
they commit to the repository. All software committed to the repository must be covered by
the LICENSE specific for that project or contain a copyright and license that allows
redistribution under the same conditions.
A committed change must be reversed if it is vetoed by one of the voting members and
the veto conditions cannot be immediately satisfied by the equivalent of a "bug
fix" commit. The veto must be rescinded before the change can be included in any
public release.
Patches
When a specific change to the software is proposed for discussion or voting on the mail
list, it should be presented in the form of input to the patch command. When sent to a
mail list, the message should contain a Subject beginning with [PATCH] and a
distinctive one-line summary corresponding to the action item for that patch along with
the names of the contributors.
The patch should be created by using the diff -u command from the original
software file(s) to the modified software file(s). E.g.,
diff -u JServ.java.orig JServ.java >> patchfile.txt
or
cvs diff -u JServ.java >> patchfile.txt
All patches necessary to address an action item should be concatenated within a single
patch message. If later modification of the patch proves necessary, the entire new patch
should be posted and not just the difference between two patches. The completed patchfile
should produce no errors or prompts when the command,
patch -s < patchfile.txt
is issued in the target repository. For this reason patches are accepted only if they
run against latest CVS snapshots. |