Document project governance
We recently discussed a proposal to foster a better collaboration within
the Gerrit community.
Google proposes to:
1. Have clear project governance rules, including a steering committee
for decision making (this change)
2. Establish a new contribution process for large/complex features that
requires to write a design doc first (change If1b6f71e7)
3. Offer mentorships to make contributions easier and faster, and raise
the quality of new features (change I10fa8e926)
4. Appoint a community manager, who focuses on the health of the
Gerrit community and constantly improves community processes (change
I39fea7a2a)
With this proposal Google increases its investment into the Gerrit open
source community. Google will fund the work of 3 steering committee
members, 1-2 mentorships at a time and a community manager.
Historically Gerrit has been a Google project that was led by Googler
Shawn Pearce. We are aware that Shawn had an exceptional standing in the
community, which is why we don't think another person could fulfill his
role, hence we want to establish a steering committee instead to take
care of leading the project.
The steering committee should have 5 members. Google as the main driver
of the Gerrit core project claims 3 steering committee members to honor
its funding of the project.
The Google members of the steering committee are appointed by Google.
The other members are elected by the non-Google maintainers.
The steering committee should act in the interest of the Gerrit project
and the whole Gerrit community.
As an integral part of the Gerrit community, the steering committee is
committed to transparency and to answer incoming requests in a timely
manner.
For decisions, consensus between steering committee members and all
other maintainers is desired. If consensus cannot be reached, decisions
can also be made by simple majority in the steering committee (should be
applied only in exceptional situations).
The steering committee has the following responsibilities and tasks:
* define project vision and project scope
* maintain a roadmap, a release plan and a prioritized backlog
* ensure timely design reviews and approvals (see change If1b6f71e7 that
documents the design-driven contribution process)
Steering committee members must dedicate sufficient time to their role
so that the steering committee can fulfill its duties.
To be able to steer the project the steering committee gets the final
decision making authority. Individual maintainers can still raise
concerns regarding new features, and hence the project direction, by
taking part in design reviews. The steering committee prefers consensus
and should use its decision power to overrule opinions only in
exceptional situations.
Having a clear process for project governance makes it transparent and
predictable how and how fast decisions are made. By having a steering
committee we also have dedicated people that are responsible for project
vision, project scope, roadmap, release plan, prioritized backlog etc.
(all things that have been badly missed by the community so far).
Details about the working mode of the steering committee are
intentionally not defined yet. It's expected that the steering committee
organizes itself and then documents how it works and how transparency is
achieved (e.g. if there are meetings, will there be meeting
notes? Where can they be found? Where is the roadmap published? etc.).
This change documents how the project governance works and which powers
and responsibilities the steering committee has. Follow-up changes will
document the new design-driven contribution process (change If1b6f71e7),
mentorships (change I10fa8e926) and the community manager role (change
I39fea7a2a).
For Google, setting up clear project governance is the most important
part of the proposal and without it we cannot invest into mentorships
and the community manager.
Signed-off-by: Edwin Kempin <ekempin@google.com>
Change-Id: I27e432cced4acb7ed42d45c4f1080e2a488347a3
diff --git a/Documentation/dev-community.txt b/Documentation/dev-community.txt
index 04a96c3..fff3467 100644
--- a/Documentation/dev-community.txt
+++ b/Documentation/dev-community.txt
@@ -15,6 +15,7 @@
* link:https://gerrit-review.googlesource.com/q/status:open+project:gerrit[Change Review]
* link:dev-design.html[System Design]
* Processes
+** link:dev-processes.html#project-governance[Project Governance / Steering Committee]
** link:dev-contributing.html[Contribution Process]
** link:dev-processes.html#dev-in-stable-branches[Development in stable branches]
** link:dev-processes.html#backporting[Backporting to stable branches]
@@ -24,6 +25,7 @@
** link:dev-roles.html#supporter[Supporter]
** link:dev-roles.html#contributor[Contributor]
** link:dev-roles.html#maintainer[Maintainer]
+** link:dev-roles.html#steering-committee-member[Steering Committee Member]
** link:dev-roles.html#release-manager[Release Manager]
[[how-to-contribute]]
diff --git a/Documentation/dev-processes.txt b/Documentation/dev-processes.txt
index 12ffb45..b25d425 100644
--- a/Documentation/dev-processes.txt
+++ b/Documentation/dev-processes.txt
@@ -1,5 +1,66 @@
= Gerrit Code Review - Development Processes
+[[project-governance]]
+[[steering-committee]]
+== Project Governance / Steering Committee
+
+The Gerrit project has a steering committee that is in charge of:
+
+* Gerrit core (the `gerrit` project) and the core plugins
+* defining the project vision and the project scope
+* maintaining a roadmap, a release plan and a prioritized backlog
+* ensuring that new features are compatible with the project vision and
+ are well aligned with other features
+* vetoing new features
+* accepting new plugins as core plugins
+* making changes to the project governance process and the
+ link:dev-contributing.html[contribution process]
+
+The steering committee has 5 members:
+
+* 3 Googlers that are appointed by Google
+* 2 non-Google maintainers, elected by non-Google maintainers for the
+ period of 1 year (see link:#steering-committee-election[below])
+
+The steering committee should act in the interest of the Gerrit project
+and the whole Gerrit community.
+
+For decisions, consensus between steering committee members and all
+other maintainers is desired. If consensus cannot be reached, decisions
+can also be made by simple majority in the steering committee (should
+be applied only in exceptional situations).
+
+The steering committee is empowered to overrule positive/negative votes
+from individual maintainers, but should do so only in exceptional
+situations after attempts to reach consensus have failed.
+
+As an integral part of the Gerrit community, the steering committee is
+committed to transparency and to answering incoming requests in a
+timely manner.
+
+[[steering-committee-election]]
+=== Election of non-Google steering committee members
+
+The election of the non-Google steering committee members happens once
+a year in May. Non-Google link:dev-roles.html#maintainer[maintainers]
+can nominate themselves by posting an informal application on the
+non-public maintainers mailing list by end of April (deadline for 2019
+is Mon 13th of May). By applying to be steering committee member, the
+candidate confirms to be able to dedicate the time that is needed to
+fulfill this role (also see
+link:dev-roles.html#steering-committee-member[steering committee
+member]).
+
+Each non-Google maintainer can vote for 2 candidates. The voting
+happens by posting on the maintainer mailing list. The voting period is
+14 calendar days from the nomination deadline (except for 2019, where
+the initial steering committee should be confirmed during the Munich
+hackathon, the voting period goes from 14th May to 16th May).
+
+Google maintainers do not take part in this vote, because Google
+already has dedicated seats in the steering committee (see section
+link:steering-committee[steering committee]).
+
[[contribution-process]]
== Contribution Process
@@ -18,14 +79,14 @@
branch before the first release candidate is created.
* To stabilize the code before doing a major release several release candidates are created. Once
the first release candidate was done no more features should be accepted on the stable branch.
- If more features are found to be required they should be discussed with the Gerrit maintainers
+ If more features are found to be required they should be discussed with the steering committee
and should only be allowed if the risk of breaking things is considered to be low.
* Once a major release is done only bug-fixes and documentation updates should be done on the
stable branch. These updates will be included in the next minor release.
* For minor releases new features are only acceptable if they are important to the Gerrit
community, if they are backwards compatible and the risk of breaking things is low and if there
- are no objections from the Gerrit community.
- * In cases of doubt it's the responsibility of the release maintainer to evaluate the risk of new
+ are no objections from the steering committee.
+ * In cases of doubt it's the responsibility of the steering committee to evaluate the risk of new
features and make a decision based on these rules and opinions from the Gerrit community.
* The older a stable branch is the more stable it should be. This means old stable branches
should only receive bug-fixes that are either important or low risk. Security fixes, including
diff --git a/Documentation/dev-roles.txt b/Documentation/dev-roles.txt
index 1cc1897..cb5e7c5 100644
--- a/Documentation/dev-roles.txt
+++ b/Documentation/dev-roles.txt
@@ -130,7 +130,9 @@
Maintainers should only approve changes that:
* they fully understand
-* seem to be in scope for what Gerrit should do
+* are in line with the project vision and project scope that are
+ defined by the link:dev-processes.html#steering-committee[steering
+ committee], and should consult them, when in doubt
* meet the quality expectations of the project (well-tested, properly
documented, scalable, backwards-compatible)
* implement usable features or bug fixes (no incomplete/unusable
@@ -158,8 +160,10 @@
ignored if there is a good reason, in this case the reason should be
clearly communicated on the change
* submit changes
-* veto changes if they disagree with a feature or with how it is being
- implemented (vote `-2` on the `Code-Review` label)
+* block submission of changes if they disagree with a feature or with
+ how it is being implemented (vote `-2` on the `Code-Review` label),
+ but their vote can be overruled by the steering committee, see
+ link:dev-processes.html#project-governance[Project Governance]
* nominate new maintainers and vote on nominations (see below)
* administrate the link:https://groups.google.com/d/forum/repo-discuss[
mailing list], the
@@ -199,6 +203,27 @@
* high quality code reviews
* activity on the mailing list
+[[steering-committee-member]]
+== Steering Committee Member
+
+The Gerrit project has a steering committee that governs the project,
+see link:dev-processes.html#project-governance[Project Governance].
+
+Members of the steering committee are expected to act in the interest
+of the Gerrit project and the whole Gerrit community.
+
+For those that are familiar with scrum, the steering committee member
+role is similar to the role of an agile product owner.
+
+Steering committee members must be able to dedicate sufficient time to
+their role so that the steering committee can satisfy its
+responsibilities and live up to the promise of answering incoming
+requests in a timely manner.
+
+link:#maintainer[Maintainers] can become steering committee member by
+election, or by being appointed by Google (only for the seats that
+belong to Google).
+
[[release-manager]]
== Release Manager
