Abstract
This document describes the basic rules and responsibilities of
the OpenACS core team. When in doubt about how the OpenACS core
team works, consult this document as the final authority.
Introduction
The OpenACS Core Team is a self-organizing group of OpenACS experts who are responsible for the evolution and management of the OpenACS project. The OpenACS Core Team decides what goes into releases. It is responsible for managing implementation, testing, and documentation of new features and bug fixes. The Core Team is also responsible for the OpenACS.org Web site.
Scope: the OpenACS Project
The phrase "OpenACS Project" refers to the OpenACS CVS tree and distribution. The OpenACS Core Team may choose to take on additional responsibilities in the future. We expect other OpenACS development teams to form independently from the OpenACS Core Team to manage additional projects. For example, the dotLRN Technical Advisory Board manages the dotLRN project, which is based on OpenACS.
Team membership
The OpenACS Core Team (referred to below as OCT) is a small group of people who are making
major contributions to the development of the OpenACS core and who
are highly respected and trusted by the OpenACS community. Team
members are expected to invest significant amounts of their time
to improve the OpenACS core.
The original group of Team members was determined by the OpenACS
community, but the OCT now handles its own membership according
to rules described here. To become a member of the Team you must
be nominated by an existing member and voted on by the existing
Team; you must receive 2/3 of the votes cast. If you would like
to join the OpenACS Core Team, you should first demonstrate your
development skills and leadership by participating in
development projects under the auspices of an existing team
member.
Inactive or disruptive members of the team can be removed by a
vote of other Team members: a 2/3 majority of those voting is
required to remove a Team member.
Decisions
The primary decision-making mechanism is the OpenACS Improvement Proposal (TIP). The process for creating and acting upon TIPs is detailed in another TIP.
Communication
The primary mechanism for communicating with the OpenACS Core Team is the OpenACS.org forums. Forums are publicly available and permanently archived. The TIP forum is reserved for proposals and their discussion and votes; other forums are used for general discussion.
Basic organizational structure
The team structure is simple and flat. All members have equal
standing: there is no Chairman. The OpenACS Core Team makes its own
rules and chooses its own members as described in this
document. Anyone on the OpenACS Core Team can propose a change in
the rules; after discussion, the change is voted on by the Team
and must receive 2/3 of the votes cast. The person proposing a
rules change is responsible for making sure that the change is
properly implemented after it has been approved (e.g. by
modifying this TIP, creating additional tools, etc.).
2/3 vote
Wherever a 2/3 vote is called for in this document, it means
that a proposal must receive at least two-thirds of the
votes cast, not votes from at least two-thirds of all OCT
members.
Projects and maintainers
OpenACS improvements are organized around two key ideas:
projects and maintainers. Most of the
activities of the OpenACS Core Team consist of projects. A project
can consist of a bug fix, a new feature in the OpenACS core, a new
facility in the OpenACS Developer Exchange, or anything else except
a change to this TIP. We divide projects into two general
categories: bug fixes and feature changes. In general, if a
project requires manual entries to be updated then it is a
feature change; when in doubt, a project is a feature change. Bug fixes use a more streamlined process for implementation,
whereas feature changes require discussion and approval in
advance.
A maintainer is someone who has taken primary responsibility for a portion of the OpenACS sources. Many maintainers will be members of the OpenACS Core Team, but the Team may also select maintainers from outside the OpenACS Core Team. We hope to find enough maintainers to cover all of the OpenACS sources, but we will appoint
a default maintainer to handle the parts of OpenACS for
which no other maintainer has volunteered. We'll also try to
have backup maintainers who can step in when the primary
maintainers are on vacation or otherwise unavailable.
A maintainer accepts several responsibilities, including the
following:
-
Monitoring the bug database for bugs in his/her area.
-
Arranging for bugs to be fixed, either by doing it
himself/herself or finding someone else to do it.
-
Coordinating and reviewing all modifications to his/her
area.
-
Providing assistance to other people working in his/her
area.
Project life-cycle: approval, implementation, integration; TYANNOTT
The project for a feature change goes through three stages:
approval, implementation, and integration.
A project starts it is proposed as a TIP. Whoever proposes a project is responsible for making sure it is properly implemented. A proposal without a committed implementor cannot be approved.
Project approval is done through a process called
TYANNOTT: Two Yesses And No No's Or Two Thirds. In
order for a project to be approved it must have support from at
least one other member of the OpenACS Core Team besides the
proposer. Once a project has been proposed and discussed, if
there are no objections and there is a vote of confidence from a
second team member ("Two Yesses And No No's"), then
the project is approved. If objections remain after the
discussion, then the proposer must summarize the objections and
call for a vote of the OCT; a 2/3 vote is required for
approval. The idea here is that most projects will be
no-brainers and we want a simple decision process that doesn't get in the way of progress. On the other hand, the OpenACS Core Team can only work effectively if it is highly collegial; if the Team can't reach pretty clear agreement on a project (i.e more than 1/3 of the OCT objects to it) then the project needs to be rethought.
The second phase of a project is implementation. The proposer is responsible for the implementation, either doing it herself or arranging for someone else to do it. The
implementation is done in a private work area and may not be integrated with the official sources until the third phase, below.
The third phase of a project is integrating the results back
into the official OpenACS repository. This is where maintainers come
in. First, before any change can be applied to the official OpenACS
sources, the implementor must post it as a patch to the
OpenACS.org patch manager. This rule applies regardless of the
type of change (anything from a 1-line bug fix to a major new
feature) and regardless of who is proposing the change. We use
the OpenACS.org patch manager to record all changes and also to
facilitate discussion about the changes before they are applied.
When a patch arrives in the patch manager, the
appropriate maintainer reviews it and works with the proposer to
revise it as necessary. Other people can also review the patch,
since it is public. If changes are needed, a revised patch is
logged in the patch manager (the final version of the patch must
always appear in the patch manager). Once the
maintainer is satisfied with the patch, it can be applied to the
OpenACS sources. If the patch implementor has write access to the
sources that he or she can apply the patch once the maintainer
has approved it. If the patch implementor doesn't have write
access to the sources than the maintainer applies the patch.
Maintainers are responsible for watching the patch
manager to make sure that incoming patches in their area are
dealt with quickly.
If the implementor of a patch is the maintainer, then he/she can
apply the patch to the OpenACS sources immediately after logging it
in the patch manager, without waiting for additional
approval. However, if someone objects to the patch then the
maintainer must be prepared to revise it after the fact.
Fast path for bug fixes
For a bug fix, no initial proposal or approval is required. The
only approval needed is for the maintainer to review the patch
before it is applied to the sources. For example, we invite
everyone in the OpenACS community to fix bugs and submit patches to
the OpenACS patch manager.
Implementors outside the OpenACS Core Team
We encourage people outside the OpenACS Core Team to get involved
with OpenACS development. For example, anyone can submit patches for
bug fixes. It's also fine for someone outside the OpenACS core team
to propose a feature change and then implement it, but there
must be a sponsor on the OpenACS Core Team who will take personal
responsibility for it. Typically the sponsor will be the
maintainer for the area of the change. It is the sponsor's
responsibility to provide whatever level of supervision is
appropriate to ensure that the project is executed well. If the
implementor for a project is not a OCT member then they cannot
vote for approval: TYANNOTT requires the sponsor plus one other
Team member.
Raising concerns
If you have concerns about a project, the best time to raise
them is during the initial discussion. Once a project has been
approved, the best approach is to raise the issue directly with
the implementor; most issues should get resolved quickly this
way. If you can't find the implementor or can't reach agreement,
and if the implementor is not a member of the OpenACS Core Team, the
next person to talk to is the OpenACS Core Team member in charge of
the project. If you still can't get satisfaction, then raise the
issue with the entire OpenACS Core Team by leading a
discussion. Once all the issues are out, you can either withdraw
your objection or summarize the issues (on both sides!) and call
for a vote. If you aren't a member of the OpenACS Core Team you will
need to convince a Team member to manage the discussion and
vote.
Even if a project has received initial approval, a Team member
can object to the project later (e.g. if they believe it hasn't
been implemented properly). If the objection isn't resolved
there will be an additional vote of the Team, and the project
cannot be applied to the official sources unless it receives a
2/3 majority of the votes cast. At the same time, Team members
are expected to raise their objections as early as possible; it
would be somewhat anti-social to raise a basic design objection
late in the implementation of a project when it could have been
raised during the initial approval.
Disagreements over patches
Normally, patches are not reviewed by the entire OCT; once the
relevant maintainer has reviewed and approved them then they can
be integrated. However, everyone is invited to review as many
patches as they wish. If someone on the OCT objects to a patch
and can't resolve the objection with the implementor and/or
maintainer, then it gets discussed by the entire OpenACS Core Team
with the usual rules: if anyone on the OpenACS Core Team has an
objection that isn't resolved by the discussion, then a 2/3 vote
is required to retain the patch. Thus if an implementor reaches
a disagreement with a maintainer he/she can appeal to the entire
OpenACS Core Team. Or, if someone on the OpenACS Core Team objects to a
patch applied by a maintainer, they too can start a discussion
in the whole team. The goal of the maintainer mechanism is to
simplify and speed up improvements in the common case where
everyone is in agreement, while still allowing the entire OpenACS
Core Team to offer input and resolve disagreements.
Changes that span areas
If a change involves several different areas of the OpenACS sources,
with different maintainers, then one of the maintainers acts as
coordinator (presumably the one whose area has the most
changes). It is their responsibility to consult with other
maintainers whose areas are affected, so that all relevant
maintainers are happy before the patch is applied to the
sources.
Write access to the OpenACS sources and the Web site
Everyone in the OpenACS Core Team has write access to all the
sources and the Web site, but they may only make changes
consistent with approved projects. The OpenACS Core Team can also
give access to other people who are working on projects. For
example, as part of a project proposal a OpenACS Core Team member
can propose that the work will be done by someone outside the
team, and that that person should have write access for putting
back changes. Giving out write access is part of a project
decision, with the associated rules for approval. However, if
someone outside the OpenACS Core Team has write access, it must be
under the auspices of a OpenACS Core Team member; the OpenACS Core Team
member is personally responsible for making sure the project is
completed satisfactorily and/or cleaning up any messes.
Deadlock resolution
If something should go wrong with the OCT organization and the
OpenACS Core Team deadlocks to a point where it can't make
meaningful progress, then Don Baccus will step in as
benevolent dictator and make enough unilateral decisions to
break the deadlock.
Document History
Originally the TCL TIP document. Edited by Peter Marklund, Joel Aufrecht.
