Add GOVERNANCE.rst, based on the WarpX model

Docs/sphinx_documentation/source/Governance.rst

@@ -0,0 +1 @@
+../../../GOVERNANCE.rst

Docs/sphinx_documentation/source/index.rst

@@ -64,6 +64,7 @@ Documentation on migration from BoxLib is available in the AMReX repository at D
    External_Frameworks_Chapter
    Regression_Testing_Chapter
    Faq
+   Governance
 
 .. toctree::
    :maxdepth: 1

GOVERNANCE.rst

@@ -0,0 +1,135 @@
+.. _governance:
+
+AMReX Governance
+================
+
+AMReX is led in an open governance model, described in this file.
+
+
+Steering Committee
+------------------
+
+Current Roster
+^^^^^^^^^^^^^^
+
+- John Bell (chair)
+- Ann Almgren
+- Weiqun Zhang
+- Andrew Myers
+
+Role
+^^^^
+
+Members of the steering committee (SC) can change organizational settings, do administrative operations such as rename/move/archive repositories, change branch protection rules, etc.
+SC members can call votes for decisions (technical or governance).
+
+The SC can veto decisions of the technical committee (TC) by voting in the SC.
+The TC can overwrite a veto with a 2/3rd majority vote in the TC.
+Decisions are documented in developer meeting notes and/or on the GitHub repository.
+
+The SC can change the governance structure, but only in a unanimous vote.
+
+Decision Process
+^^^^^^^^^^^^^^^^
+
+Decision of the SC usually happen in the developer meetings, via e-mail or public chat.
+
+Decisions are made in a non-confidential manner, by majority on the cast votes of SC members.
+Votes can be cast in asynchronous manner, e.g., over the time of 1-2 weeks.
+In tie situations, the chair of the SC acts as the tie breaker.
+
+Appointment Process
+^^^^^^^^^^^^^^^^^^^
+
+Appointed by current SC members in an unanimous vote.
+As a SC member, regularly attending and contributing to the weekly developer meetings is expected.
+
+SC members can resign or be removed by majority vote, e.g., due to inactivity, bad acting or other reasons.
+
+
+Technical Committee
+-------------------
+
+Current Roster
+^^^^^^^^^^^^^^
+
+- Axel Huebl
+- Kevin Gott
+- Marc Day
+- Michael Zingale
+
+See: `GitHub team <https://github.com/orgs/AMReX-Codes/teams/amrex>`__
+
+Role
+^^^^
+
+The technical committee (TC) is the core governance body, where under normal operations most ideas are discussed and decisions are made.
+Individual TC members can approve and merge code changes.
+Usually, they seek approval by another maintainer for their own changes, too.
+TC members lead - and weigh in on - technical discussions and, if needed, can call for a vote between TC members for a technical decision.
+TC members merge/close PRs and issues, and moderate (including block/mute) bad actors.
+The TC can propose governance changes to the SC.
+
+
+Decision Process
+^^^^^^^^^^^^^^^^
+
+Discussion in the TC usually happens in the developer meetings. Developer meetings can be scheduled by any member of the SC or TC.
+
+If someone calls for a vote to make a decision: majority based on the cast votes; we need 50% of the committee participating to vote. In the absence of a quorum, the SC will decide according to its voting rules.
+
+Votes are cast in a non-confidential manner.
+Decisions are documented in the developer meeting notes and/or on the GitHub repository.
+
+TC members can individually appoint new contributors, unless a vote is called on an individual.
+
+Appointment Process
+^^^^^^^^^^^^^^^^^^^
+
+TC members are the maintainers of AMReX.
+As a TC member, regularly attending and contributing to the developer meetings is expected.
+
+One is appointed to the TC by the steering committee, in a unanimous vote, or by majority vote of the TC. The SC can veto appointments.
+Steering committee members can also be TC members.
+
+TC members can resign or be removed by majority vote by either TC or SC, e.g., due to inactivity, bad acting or other reasons.
+
+
+Contributors
+------------
+
+Current Roster
+^^^^^^^^^^^^^^
+
+See: `GitHub contributors <https://github.com/AMReX-Codes/amrex/graphs/contributors>`__
+
+Role
+^^^^
+
+Contributors are valuable, vetted developers of AMReX.
+Contributions can be in many forms and not all need to be code contributions.
+Examples include code pull requests, support in issues & user discussions, writing and updating documentation, writing tutorials, visualizations, R&D on algorithms, testing and benchmarking, etc.
+Contributors can participate in developer meetings and weigh in on discussions.
+Contributors can "triage" (add labels) to pull requests, issues, and GitHub discussion pages.
+Contributors can comment and review PRs (but not merge).
+
+Decision Process
+^^^^^^^^^^^^^^^^
+
+Contributors can individually decide on classification (triage) of pull requests, issues, and GitHub discussion pages.
+
+Appointment Process
+^^^^^^^^^^^^^^^^^^^
+
+Appointed after contributing to AMReX (see above) by any member of the TC.
+
+The role can be lost by resigning or by decision of an individual TC or SC member, e.g., due to inactivity, bad acting or other.
+
+
+Former Members
+--------------
+
+"Former members" are *not* tracked as a governance role in AMReX.
+Instead, former (e.g., inactive) contributors are acknowledged separately in GitHub contributor tracking, the AMReX documentation, references, etc. as appropriate.
+
+Former members of SC, TC and Contributors are not kept in the roster, since committee role rosters should reflect currently active members and the responsible governance body.