Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

update board/bylaws/team in v3.10 branch #5202

Merged
merged 1 commit into from
Jan 10, 2025
Merged
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
32 changes: 12 additions & 20 deletions docsrc/overview/cyrus_bylaws.rst
Original file line number Diff line number Diff line change
Expand Up @@ -11,12 +11,9 @@ The Cyrus Governance Board is responsible for the overall direction of the Cyrus

The Board is comprised of:

* Wes Craig
* Jeffrey Eaton
* Ken Murchison
* Benn Oshrin
* Dave McMurtrie
* Bron Gondwana
* Ken Murchison
* Ricardo Signes

II. The Cyrus Core Developers Group
-----------------------------------
Expand All @@ -25,11 +22,12 @@ The Cyrus Core Developers Group is responsible for the technical guidance of the

The members of the Core Developers group are:

* Wes Craig
* Alexey Melnikov
* Bron Gondwana
* ellie timoney
* Ken Murchison
* Matt Selsky
* Bron Gondwana
* Alexey Melnikov
* Robert Stepanek

III. The Release Engineer
-------------------------
Expand All @@ -38,24 +36,18 @@ The Release Engineer is responsible for making Cyrus releases. The Release Engin

The release engineer is:

* Jeroen van Meeuwen

IV. The Cyrus Roadmap
---------------------

The :ref:`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.

* ellie timoney

V. Development Process
----------------------
IV. 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.
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.

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 Release Engineer shall make regular releases. 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
V. Changes to the Bylaws
-------------------------

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