Forum OpenACS Improvement Proposals (TIPs): TIP #1 (Rejected): OpenACS Core Team Rules and Responsibilities


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.


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 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.


The primary decision-making mechanism is the OpenACS Improvement Proposal (TIP). The process for creating and acting upon TIPs is detailed in another TIP.


The primary mechanism for communicating with the OpenACS Core Team is the 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 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 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.

3: Seconded (response to 2)
Posted by Lars Pind on
I assume that it's acceptable to comment on TIPs?

Thank you, Peter and Joel.

This is a wonderful initiative! I'm looking forward to seeing this initiative organize and formalize the toolkit's development, test, and release process.


I disagree with this proposal strongly because of the way the OCT has been selected. No problem with the people at all but it's unacceptable for a community effort to have leaders selected this way.

We need to establish a way for OCT members to be selcted.


I recommend that OCT members are elected by a vote of those with CVS commit access. This group represents the members of the community who have already proven significant time, investment and energy in the project.

I also recommend that OCT membership is limited to a certain number of people, that those people must be active members during their membership and must maintain a certain level of participation.

Dan Wickstrom is a critical member of the OpenACS community and has historically done some massive heavy lifting, but is he really appropriate to be on the OCT right now? I'd like to know Dan's opinion on this as well.

I understand he's really busy outside of the OACS at the moment, which is cool. But I don't think it's appropriate for the OCT.

Anyway, I call for an immediate election of the OCT by a referendum among CVS committers.


First of all I second Talli's motion of a vote of people with CVS commit rights for membership of the OCT.

Secondly, I would strongly encourage not to have more than one person in the OCT per organization (I know this only holds true for collaboraid at the moment, but having the two main members of a company also be 1/3rd of the OCT does not feel good.).

I would like to second Malte's suggestion. My opinions on the subject matter have been recorded in the following thread four (4) months ago:

Here's a snippet from what I've wrote in that thread (date: April 25, 2003):

Having said that, I would like to contribute my 2 cents in this discussion. I believe that most good examples of consortiums/organizations of this form have one basic principle that I strongly believe should also be a fundamental rule for any future governance body that will be formed:

<em>No single company or a coalition of interests should be able to control the faith of the project.</em>

What I'm saying is that the governance body, *IMHO*, should be formed of a variety of people with no common interests (in the sense of funding and so on) so that the project won't shift away based on the interests of that one entity or coalition.

Reading through this document again, I think it's a bad idea. Too much room for the project to become a clique. And the aD/OACS world has too much history of cliques for this not to be a potentiality.



I am not sure what you mean by OpenACS becoming a clique. It seems to me that generally the decisions are made by people who are now the de facto core team.

The current process is working, but using the struture in this TIP would make the process more transparent as the decisions would be made in the open.

TIP is adopted from TCL and I believe stood for Tcl Improvement Proposal or something similar. For OpenACS I just that is a misname, and we will need to think of another clever name for proposals.

Dave, what's wrong with a vote? If we elect the same people, that's fine. But if this is not a clique, then we should be able to prove that it's not by letting the community decide who they want to lead.

For instance, Bart Teeuwise has done a lot of work setting up tDOM in the OACS. He should be a candidate for the OCT. As should Dirk. As should you, etc

Dan Wickstrom, though, hasn't been around for a while. His positin on the OCT is based on a lot of the historical work that he's done and because he may come back in the future.

(I really don't want to pick on Dan - it's just an example of why I don't like this structure.)

As far we this is what Tcl uses... Well, how big is that community nowadays? Not the user base, the Tcl community.

I'll work on an alternative proposal.



Ok. I misintepreted your message. I have no problem with a vote. I thought you were rejected the entire proposal not the part the accepts the original suggested members of the core team.

Dave, I have no problem with most of the proposal (nor anyone on the proposed OCT - in fact most of them have stayed at my home!) I just don't like they've been put there without a more transparent process and that there is no language about OCT rotation, elections, etc.

For me, the most important part of governance is showing community members, new and old, that there are clear and transparent ways to gain leadership positions. This proposal says nothing other than if the OCT likes you, you can have a leadership position. That's no good.

I would like to see annual elections with more clear explanations of how someone can get CVS access, for instance.



Never let Don stay at your place. He'll make you take a cab all the way across the city and have you pay $400 for half a roll of toilet paper from the restroom of a dirty garage.


Restroom, Election, OpenACS, getting confused here.

Anyway it would be nice to have elections now, than say a year later.  Even though we may end up with same set of people.  We start on a nice fresh way.

Also what about none technical concerns?  Does OCT handle that or some other group?

Just my opinion.

My understanding from this proposal is that the OCT will deal purely with technical issues involving the toolkit. I don't foresee them coordinating marketing events for OpenACS (as an example).
17: Call for Full Vote (response to 1)
Posted by Joel Aufrecht on
Although there haven't been any Vetos, I think we have enough community feedback to need a full vote :)

I agree with Talli's concerns about the unelected nature of the OCT. However, given the time (many months) and length (many posts) and concrete results (very little) of discussions to date, I see our current choice as between the OCT and the fraction of Don that is available, rather than between an elected OCT and a cabal.

So I'm calling for a full vote of the existing OCT to ratify themselves, because then our process will be bootstrapped up one level. We'll have a place of record for decisions and we'll have a process that isn't wholly dependent on Don.

Then we should start a new discussion, leading within days or weeks to a TIP, so that we can ask the current OCT to approve their own replacement via a permanent, democratic process.

What do we actually want the OCT to represent? Should it represent each and every individual that has managed to log in and become a member, or, should it represent the best knowledge and skills found within the community?

In other words, do we want the OCT to reflect quantity of ideas or quality of ideas? Do we want our community to be a democracy (ruled by the people) or a meritocracy (ruled by the merited - meaning those who, *through practice*, have turned out to be the greatest resources)?

I for one thought it was long since acknowledged that this community is a meritocracy ...

As for cvs access - If someone feels that they need to be able to commit to one part or another of the code tree they will most likely either contact the leaders directly and ask for it, or post on the forums about how to get it. I see no difficulty in that, especially since the leaders seem to follow the posting traffic closely.

Joel, that makes no sense. How can there be any vetos if veto power is only among the OCT and the OCT was not elected democratically?

Let's have an immediate vote of the CVS committers to ratify the OCT or set up a complete election for the OCT.


I don't feel as strongly about voting issues as Talli does, though I generally agree with his points.

I do, however, think that this process looks awfully bureacratic.  My first impression when I read it was that very few people are going to want to go through all that to contribute their code.  After thinking it over for several days I still feel that way, plus I'm worried about bottlenecks.  Having every bug fix reviewed means a *lot* of time spent on a task which is not really rewarding for anyone.  I've been through this before on other projects and it always ends up at the bottom of people's todo lists, especially when there is paying work to be done.

I understand and even mostly agree with the reasons for wanting more structure.  I realize that right now the project is not as organized or directed as it could be, and that we don't have enough safeguards to keep bad code out.  But in the long run we will not benefit from a process that causes the project to stagnate because everyone keeps their work to themselves, either.

I don't have a competing proposal to make - I guess my main reason for posting is to find out if I'm the only one who feels this way?  If so, I will consider myself outvoted and sit down quietly. :)  But if anyone else shares my concerns, now is the time to speak up, before anything is really set in stone.


I believe this proposal only affects the OpenACS core pacakges. I think we agree that the core packages should be stable. Perhaps we should list the existing packages that make up the core. Other packages not part of the core should be managed by the maintainer of those packages.

Packges in acs-core according to CVS:



Also the proposal says:

"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."

Later it says that the maintainer of a package can approve and apply bug fixes with no input from the core team.

So I think this is mostly inline with the current informal process. If you want to add a feature, discuss on the forum, email one of the prominent members of the community and get CVS commit privileges.

Does that address your concerns?

Ola, I have a deep and nearly uncontrollable hatred for the concept of a meritocracy. I find "merit" to be arbirary and incoherent when aligned with the principles of an open community. And I believe that it leads to entrenched cliques.

The provisional voting structure has been set up because that was a way for identifying a "citizenry" quickly and easily. But those people are not necessarily the most important nor the most qualified for OpenACS to succeed. For example, some of those who have voted haven't had the most time to work on code lately or don't represent the one of the key factors in OpenACS improvements - access to funding.

This is an example of how "merit" is very difficult to define.

Over the next month we'll have to come up with a governance infrastructure that makes more sense. I asked a month or so ago about what makes a good OpenACS citizen and got very little response. I will spend some time on a proposal and post it as an RFC.


Janine, I agree with you that the requirement of having to submit patches risks becoming a bottleneck. We have seen that patches are not being committed quickly enough in the Bug Tracker. I think that people with commit rights should be allowed to make bug fixes without having to submit a patch first. Other parts of the cvs guidelines are still worth thinking about though, i.e. preserve upgradability, respect code freezes, keep code simple, be careful about what you are committing etc.
I guess it will remain to be seen whether the package maintainers can keep up with the bug fixes, and whether having to write a TIP (or whatever it ends up being called) will stifle people's desire to contribute.  I can't say for sure that it will;  that was just my impression.
I guess I am really confused. From what I read, package maintainers can fix bugs and commit them without any extra process. Obviously others who do not have commit privileges will still need to submit a patch. Anyone who wants to change how OpenACS works, or add a feature to the core will need to dicuss it on the forums.

I don't seem any place in the proposal that suggests a TIP needs to be submitted for every bug fix.

Besides this, if you want to add a feature and it isn't approved to go into the core, it can always go into an add-on pacakge. Most of the packages in CVS now are add on packages.

I think the process to approve adding or changing features will help to direct development of the OpenACS core.

I never said you had to write a TIP for every bug fix.  But it does say that package maintainers are supposed to review bug fixes, and all of the maintainers I know are very busy people.
I think the key is that the core team can delagate responsibility. Also any package maintainer, for a core package or not can delagate to someone else.

I really want to know how a specified "process" is any worse than the way it is now. There are many many unresolved bugs and patches. Noone really maintains this now. Why can't we say that package maintainers need to actually maintain the packages?

More on my previous post. We need to get realy volunteers who will take the time to close bug reports, apply or reject patches and generally keep people informed of what is going on. If we don't do this there is no reason to have a bugtracker.

That is, is the current CVS maintainers just keep everything to themselves and commit work without closing bugs, we might as well just send email to someone who we think might be able to help and hope for the best.

I'll start a thread in the regular developers forum. I think we need to get someone who will really maintain each package in the core before we talk about a formal process for those people.