Created by Ana Holzbach, last modified by Ana Holzbach 25 Sep 2006, at 09:26 PM
<html>
<head>
<script src="http://simile.mit.edu/timeline/api/timeline-api.js" type="text/javascript"></script>
<script src="timeline.js"></script>
<link rel='stylesheet' href='timeline.css' type='text/css' />
</head>
<body onload="onLoad();" onresize="onResize();">
<!-- <p>Ana Holzbach, Carl Blesius - September 2006</p>-->
<div id="body">
<h1 align="center">OpenACS Fall Conference 2006<br>Harvard Conference Center Room Schedule</h1>
<table width="1000">
<tr>
<td width="10%">
<table height="250">
<tr>
<td>Room 1</td>
</tr>
<tr>
<td>Room 2</td>
</tr>
<tr>
<td>Room 3</td>
</tr>
</table>
</td>
<td width="90%">
<div id="tl" class="timeline-default" style="height: 250px;"></div>
</td>
</tr>
</table>
</div>
</body>
</html>
Created by Carl Blesius, last modified by Carl Robert Blesius 08 Mar 2006, at 07:26 PM
[NOTE: THIS IS A ROUGH DRAFT BASED ON THE OPENACS EQUIVALENT]
Abstract
This document describes both the basic rules and responsibilities of the .LRN Core Team as well as the nomination and election process. When in doubt about how the .LRN Core Team works, consult this document as the final authority.
Introduction
The .LRN Core Team is a group of .LRN experts who are responsible for the evolution and management of the .LRN project. The .LRN Core Team decides what goes into releases, works with the OpenACS Core Team, the OpenACS technical release mangement, and the .LRN technical release management to help managing implementation, testing, documentation of new features and bug fixes, and allocates a portion of the .LRN Consortium Budget defined by the Board of Directors of the Corporation. The Core Team is also responsible for the dotlrn.org Web site.
Scope: the .LRN Project
The phrase ".LRN Project" refers to the portion of the OpenACS CVS tree and distribution as defined in CVS by the module alias "dotlrn-all". The .LRN Core Team may choose to take on additional responsibilities in the future. We expect other development teams to form independently from the .LRN Core Team to manage additional projects.
Team membership
The .LRN Core Team (referred to below as LCT) is a small group of people who are making major contributions to the development of the .LRN project and who are highly motivated, respected, and trusted by both the .LRN and the OpenACS communities. Team members are expected to invest significant amounts of their time to improve .LRN.
The first group of Team members will be nominated by the .LRN Board of Directors, but the LCT will then be nominated and elected based on the process outlined in this document.
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 .LRN 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 through .LRN Motions. The process for creating and acting upon .LRN Motions is detailed in the .LRN Motions document.
Communication
The primary mechanism for communicating with the .LRN Core Team is the OpenACS.org .LRN forums. Forums are publicly available and permanently archived. The .LRN Motions 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 official Chairman position, although the team may create an internal organizational structure if needed. Anyone on the .LRN 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 Motion, creating additional tools, etc.). [We should consider a possible Board VETO power]
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 LCT members.
Projects and maintainers
.LRN improvements are organized around two key ideas: projects and maintainers. Most of the activities of the .LRN Core Team consist of projects. A project can consist of a bug fix, a new feature in the .LRN core, a new facility in the OpenACS Developer Exchange, or anything else except a change to this Document. 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.
Implementors outside the .LRN Core Team
We encourage people outside the .LRN Core Team to get involved with .LRN development. For example, anyone can submit patches for bug fixes. It's also fine for someone outside the .LRN core team to propose a feature change and then implement it, but there must be a sponsor on the .LRN 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 LCT 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 .LRN Web site
Everyone in the .LRN Core Team has write access to all of the Web site, but they may only make changes consistent with approved projects. The .LRN Core Team can also give access to other people who are working on projects. For example, as part of a project proposal a .LRN 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 .LRN Core Team member; the .LRN 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 the .LRN Board of Directors will step in and make enough unilateral decisions to break the deadlock.
Document History
Text taken from the original OpenACS Core Team document and edited by Gustaf Neumann & Carl Blesius.
