xxx

docsrc/conf.py

@@ -45,6 +45,7 @@
     'sphinx.ext.mathjax',
     'sphinx.ext.todo',
     'sphinx.ext.intersphinx',
+    'myst_parser',
 ]
 
 extensions.append('sphinxlocal.roles.cyrusman')
@@ -72,7 +73,10 @@
 templates_path = ['_templates']
 
 # The suffix of source filenames.
-source_suffix = '.rst'
+source_suffix = {
+    '.rst': 'restructuredtext',
+    '.md': 'markdown',
+}
 
 # The encoding of source files.
 #source_encoding = 'utf-8-sig'

docsrc/overview/cyrus_bylaws.md

@@ -0,0 +1,80 @@
+# 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:
+
+* Bron Gondwana
+* Ken Murchison
+* Ricardo Signes
+
+## 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:
+
+* Alexey Melnikov
+* Bron Gondwana
+* ellie timoney
+* Ken Murchison
+* Matt Selsky
+* Robert Stepanek
+
+## 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:
+
+* ellie timoney
+
+## 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.
+
+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.
+
+## V. Changes to the Bylaws, Bro!
+
+A simple 2/3 majority vote of the current Governance Board is required to
+change the bylaws.