Cyrus Bylaws
************

To better facilitate the governance and to ensure the future of the
Cyrus Project, we have established these bylaws under which the
Project will be managed.


I. The Cyrus Governance Board
=============================

The Cyrus Governance Board is responsible for the overall direction of
the Cyrus project. Members of the board are nominated by the Cyrus
community at large. Following nomination, a vote must be called by a
current member of the board. A nominated member must be elected by a
simple 2/3 majority vote of the current Board. There is no upper limit
to the number of members of the Board. An existing member may be
removed from the board by resigning, or by a unanimous vote of the
remaining members of the board.

The Board is comprised of:

* Wes Craig

* Jeffrey Eaton

* Ken Murchison

* Benn Oshrin

* Dave McMurtrie

* Bron Gondwana


II. The Cyrus Core Developers Group
===================================

The Cyrus Core Developers Group is responsible for the technical
guidance of the Cyrus project. Members are nominated by the Cyrus
developer community. Following nomination, a vote must be called by a
current Core Developer. A nominated member must be elected by a simple
2/3 majority of the current Core Developers Group, then confirmed by a
simple 2/3 majority of the Governance Board.

The members of the Core Developers group are:

* Wes Craig

* Ken Murchison

* Matt Selsky

* Bron Gondwana

* Alexey Melnikov


III. The Release Engineer
=========================

The Release Engineer is responsible for making Cyrus releases. The
Release Engineer is also responsible for committing contributions from
non-committers in the absence of anyone accepting the responsibility
for a particular issue. The Release Engineer must be elected by a
simple 2/3 majority of the Core Developers Group, then confirmed by a
simple 2/3 majority of the Governance Board.

The release engineer is:

* Jeroen van Meeuwen


IV. The Cyrus Roadmap
=====================

The Cyrus Roadmap is a guideline as to the future of the Cyrus
project. The Roadmap will include milestones including both new
feature development as well as further development on existing
features. Releases will be made in accordance with the Roadmap when
possible. Changes to the Roadmap are suggested by the community at
large. Changes must be approved by a series of votes. All changes must
pass a simple 2/3 majority of the Core Developers Group and a simple
2/3 majority of the Governance Board.


V. Development Process
======================

Significant new features or changes to existing code should be
discussed on the cyrus-dev mailing list prior to beginning development
to allow feedback from other developers. Once a solution has been
proposed and accepted by rough consensus of the developers, coding
should proceed. All patches must be submitted through the bug tracking
system. Once submitted to the tracking system, a member of the core
developers group must review the code. If there are no objections to
the patch by the core developers, the core developer should then
commit the code to the source repository. The submitter of the code is
responsible for ensuring that the code gets reviewed by the core
developers. Submitters may inquire as to the status of their patches
to either the Release Engineer or CORE no more than once per week.
Accepted patches will be included in the next appropriate release
regardless of the Roadmap.

The Release Engineer shall make releases according to the Roadmap. If
there are no blocker-level bugs, a release may be made at the Release
Engineer’s discretion. The Release Engineer may also classify a bug as
blocker or as a security fix that requires immediate release.

The Core Developers group may block a pending release with a simple
majority vote.


VI. Changes to the Bylaws
=========================

A simple 2/3 majority vote of the current Governance Board is required
to change the bylaws.
