Guidelines for IS&T and SIPB Collaboration on Debathena


The following stakeholders are identified:

  • SIPB Debathena Developers: Those SIPB contributors who focus on Debathena development, defined as the moira group debathena-dev.
  • IS&T Developers: Those IS&T developers who devote a significant portion of their time to Debathena, currently amb and rbasch.
  • IS&T Support: Those IS&T staff members who devote a significant portion of their time to supporting Debathena, currently jdreed.
  • Debathena Release Team: All those IS&T staff and SIPB contributors who have an active interest in Athena, comprising the list release-team.

Vicarious stakeholders: In that Debathena is branded as a collaboration between SIPB and IS&T, both organizations as a whole have an interest in the project.

Consensus Decision-Making

Debathena relies on discussion and consensus to make major decisions, choose among technical architectures, shape major user-facing features, and make other significant choices. Before committing any such change, consensus must be reached, and all stakeholders must be notified.

The "second and white ballot" procedure

Minor decisions in Debathena development are made using a process similar to the "second and white ballot" procedure used by parliamentary organizations. A change should not be made until it has been (1) proposed in one of the acceptable discussion forums described below, (2) has received positive approval of the change from another developer (preferably one with expertise in the code being changed) and (3) an appropriate period of time has passed to allow stakeholders to object to the change.

If at a point prior to deploying a change to production, there are objections to a change from one of the stakeholders, the objections should be addressed before the change can proceed to the next stage of the process. An objection can be addressed by adjusting the change so as to satisfy the objector(s), or by achieving consensus from the other stakeholders that we should proceed with the proposal despite the objections.

Section III will detail the development process more precisely, as well as some specific circumstances that require stronger consensus.

Discussion Forums

The two acceptable discussion forums are identified as the zephyr class debathena ("Zephyr") and the mailing list ("Email"). Each of the stakeholders is responsible for monitoring these forums. Recognizing that Zephyr is more suitable for a real-time discussion, it is an ideal place for discussing details of changes, which should then be summarized over Email, referring to the Zephyr logs as appropriate. Larger changes should use Email as the discussion medium, to ensure that all stakeholders have a chance to participate in the discussion.

If all members of a stakeholder group anticipate being offline for an extended period of time, they shall designate a proxy.

Development Process

This section has been superseded by WorkflowPolicy.

The following development process should be followed for all changes:

a. Discuss the change with other developers and achieve consensus that the change is desirable. The discussion threshold varies dependening on the significance of a change. Bugfixes and other small changes should be discussed at the concept level prior to being committed using the "second and white ballot" procedure described above.

If a change is large, complex, potentially objectionable to one of the stakeholders, or otherwise unusual, one should solicit opinions via Email (waiting at least 3 business days for discussion) and achieve clear consensus before committing the change.

In particular, changes that have significant impact on the user experience, and new features that might generate significant support burden, must be explicitly approved by IS&T Support. Similarly, all major feature removals must be explicitly approved by the Debathena Release Team.

b. Develop and test the change. Untested changes should never be committed or uploaded to the beta ("-proposed") repository unless they are clearly non-functional (e.g. an update to a package's description).

c. Commit the change and upload it to the beta ("-proposed") repository for beta testing. Complex changes to dependencies, as well as those that might affect the update infrastructure, should always be tested via the alpha ("-development") repository before being moved to the beta ("-proposed") repository. Uncommitted changes should never be uploaded to the beta ("-proposed") repository.

d. Wait 2 business days for post-commit review of the change andtesting in the beta ("-proposed") repository. For changes that are complex or significant, this period should be extended to a week.

The implementation of any change must be approved via the "second and white ballot" procedure before it can be moved into production.

e. Move the change into production. This action should always be announced via one of the acceptable forums for communication.

Exceptions can be made to the development process in cases where clear consensus is reached that the exception should be made; this should involve an explicit approval from at least 3 developers, and from any other stakeholders who might have a particular interest in the exception. Time-sensitive security fixes are a good example of when this might be appropriate.

Security Guidelines

Your root instance in Kerberos, authorized to upload into the production apt repository, is trusted by many people. It's important that it remain secure. You should type your root-instance password into at most a handful of machines, and keep all those machines secure. Keep in mind that public machines could be compromised, which could in turn compromise your dotfiles. You should therefore either avoid running your Athena dotfiles on your trusted machines or abstain from logging in to public Athena machines.


This document may be amended through consensus decisions of the Debathena Release Team. Amendments must be discussed for at least a week over Email before they can be made.