Merge branch 'stable-3.1'
* stable-3.1: ConfigSuite: fix example for setting config in test Documentation: Fix dev-contributing Q&A list items Documentation: Fix dev-contributing trail line wrap Document how the ESC evaluates design docs Clarify that non-maintainers can candidate as community manager Change-Id: Idde5c95c1a1878d12aa35ff838f80912dc9da9a7
This commit is contained in:
@@ -267,34 +267,42 @@ meetings.
|
|||||||
|
|
||||||
=== Evaluation
|
=== Evaluation
|
||||||
Product/Vision fit
|
Product/Vision fit
|
||||||
|
|
||||||
Q: `Do we believe this feature belongs to Gerrit Code Review use-cases?`
|
Q: `Do we believe this feature belongs to Gerrit Code Review use-cases?`
|
||||||
|
|
||||||
* Yes: Customizable dashboards
|
* Yes: Customizable dashboards
|
||||||
* No: UI for managing an LDAP server
|
* No: UI for managing an LDAP server
|
||||||
|
|
||||||
Q: `Is the proposed solution aligned with Gerrit’s vision?`
|
Q: `Is the proposed solution aligned with Gerrit’s vision?`
|
||||||
|
|
||||||
* Yes: Showing comments of older patch sets in newer patch sets to
|
* Yes: Showing comments of older patch sets in newer patch sets to
|
||||||
keep track (core code review)
|
keep track (core code review)
|
||||||
* No: Implement a bug tracker in Gerrit (not core code review).
|
* No: Implement a bug tracker in Gerrit (not core code review).
|
||||||
|
|
||||||
=== Impact
|
=== Impact
|
||||||
Q: `Will the new feature have a measurable, positive impact?`
|
Q: `Will the new feature have a measurable, positive impact?`
|
||||||
|
|
||||||
* Yes: Increased productivity, faster/smoother workflow, etc.
|
* Yes: Increased productivity, faster/smoother workflow, etc.
|
||||||
* Yes: Better latency, more reliable system.
|
* Yes: Better latency, more reliable system.
|
||||||
* No: Unclear impact or lacking metrics to measure.
|
* No: Unclear impact or lacking metrics to measure.
|
||||||
|
|
||||||
=== Complexity
|
=== Complexity
|
||||||
Q: `Can we support/maintain this feature once it is in Gerrit?`
|
Q: `Can we support/maintain this feature once it is in Gerrit?`
|
||||||
|
|
||||||
* Yes: Code will fit into codebase, be well tested, easy to
|
* Yes: Code will fit into codebase, be well tested, easy to
|
||||||
understand.
|
understand.
|
||||||
* No: Will add code or a workflow that is hard to understand
|
* No: Will add code or a workflow that is hard to understand
|
||||||
and easy to misinterpret.
|
and easy to misinterpret.
|
||||||
|
|
||||||
Q: `Is the proposed feature or rework adding unnecessary complexity?`
|
Q: `Is the proposed feature or rework adding unnecessary complexity?`
|
||||||
|
|
||||||
* Yes: Adding a dependency on a well-supported library.
|
* Yes: Adding a dependency on a well-supported library.
|
||||||
* No: Adding a dependency on a library that is not widely used
|
* No: Adding a dependency on a library that is not widely used
|
||||||
or not actively maintained.
|
or not actively maintained.
|
||||||
|
|
||||||
=== Core vs. Plugin decision
|
=== Core vs. Plugin decision
|
||||||
Q: `Would this fit better in a plugin?`
|
Q: `Would this fit better in a plugin?`
|
||||||
|
|
||||||
* Yes:The proposed feature or rework is an implementation (e.g. Lucene
|
* Yes:The proposed feature or rework is an implementation (e.g. Lucene
|
||||||
is an index implementation) of a generic concept that others
|
is an index implementation) of a generic concept that others
|
||||||
might want to implement differently.
|
might want to implement differently.
|
||||||
@@ -307,6 +315,7 @@ Q: `Would this fit better in a plugin?`
|
|||||||
Q: `Is someone willing to implement it?` (this question is
|
Q: `Is someone willing to implement it?` (this question is
|
||||||
especially important when reviewers propose alternative designs
|
especially important when reviewers propose alternative designs
|
||||||
to the author’s own solution).
|
to the author’s own solution).
|
||||||
|
|
||||||
* Yes: The author or someone else commits to implementing the
|
* Yes: The author or someone else commits to implementing the
|
||||||
proposed solution.
|
proposed solution.
|
||||||
* Yes: If a mentorship is required, a mentor is willing to help.
|
* Yes: If a mentorship is required, a mentor is willing to help.
|
||||||
@@ -315,8 +324,94 @@ to the author’s own solution).
|
|||||||
=== Community
|
=== Community
|
||||||
Q: `If in doubt, is there a substantial benefit to a long-standing
|
Q: `If in doubt, is there a substantial benefit to a long-standing
|
||||||
community member with many users?`
|
community member with many users?`
|
||||||
|
|
||||||
* The community shapes the future of Gerrit as a product. In
|
* The community shapes the future of Gerrit as a product. In
|
||||||
cases of doubt, the ESC can be more generous with long-standing community members compared to `drive-by` contributions.
|
cases of doubt, the ESC can be more generous with long-standing
|
||||||
|
community members compared to `drive-by` contributions.
|
||||||
|
|
||||||
|
[[esc-dd-evaluation]]
|
||||||
|
== How the ESC evaluates design documents
|
||||||
|
This section describes how the ESC evaluates design documents. It’s
|
||||||
|
meant as a guideline rather than being prescriptive for both ESC
|
||||||
|
members and contributors.
|
||||||
|
|
||||||
|
=== General Process
|
||||||
|
As part of the design process, the ESC makes a final decision if a
|
||||||
|
design gets to be implemented. If there are multiple alternative
|
||||||
|
solutions, the ESC will decide which solution can be implemented.
|
||||||
|
|
||||||
|
The ESC should wait until all contributors had the chance to
|
||||||
|
voice their opinion in review comments or by proposing alternative
|
||||||
|
solutions. Due to the infrequent ESC meetings (every 2-4 weeks)
|
||||||
|
the ESC might discuss documents in cases where the discussion is
|
||||||
|
already advanced far enough, but not make a decision yet. In this
|
||||||
|
case, contributors can still voice concerns or discuss alternatives.
|
||||||
|
The decision can be at the next meeting or via email in between
|
||||||
|
meetings.
|
||||||
|
|
||||||
|
=== Evaluation
|
||||||
|
Product/Vision fit
|
||||||
|
|
||||||
|
Q: `Do we believe this feature belongs to Gerrit Code Review use-cases?`
|
||||||
|
|
||||||
|
* Yes: Customizable dashboards
|
||||||
|
* No: UI for managing an LDAP server
|
||||||
|
|
||||||
|
Q: `Is the proposed solution aligned with Gerrit’s vision?`
|
||||||
|
|
||||||
|
* Yes: Showing comments of older patch sets in newer patch sets to
|
||||||
|
keep track (core code review)
|
||||||
|
* No: Implement a bug tracker in Gerrit (not core code review).
|
||||||
|
|
||||||
|
=== Impact
|
||||||
|
Q: `Will the new feature have a measurable, positive impact?`
|
||||||
|
|
||||||
|
* Yes: Increased productivity, faster/smoother workflow, etc.
|
||||||
|
* Yes: Better latency, more reliable system.
|
||||||
|
* No: Unclear impact or lacking metrics to measure.
|
||||||
|
|
||||||
|
=== Complexity
|
||||||
|
Q: `Can we support/maintain this feature once it is in Gerrit?`
|
||||||
|
|
||||||
|
* Yes: Code will fit into codebase, be well tested, easy to
|
||||||
|
understand.
|
||||||
|
* No: Will add code or a workflow that is hard to understand
|
||||||
|
and easy to misinterpret.
|
||||||
|
|
||||||
|
Q: `Is the proposed feature or rework adding unnecessary complexity?`
|
||||||
|
|
||||||
|
* Yes: Adding a dependency on a well-supported library.
|
||||||
|
* No: Adding a dependency on a library that is not widely used
|
||||||
|
or not actively maintained.
|
||||||
|
|
||||||
|
=== Core vs. Plugin decision
|
||||||
|
Q: `Would this fit better in a plugin?`
|
||||||
|
|
||||||
|
* Yes:The proposed feature or rework is an implementation (e.g. Lucene
|
||||||
|
is an index implementation) of a generic concept that others
|
||||||
|
might want to implement differently.
|
||||||
|
* Yes: The proposed feature or rework is very specific to a custom setup.
|
||||||
|
* No: The proposed feature or rework is applicable to a wider user
|
||||||
|
base.
|
||||||
|
* No: The proposed feature or rework is a `core code review feature`.
|
||||||
|
|
||||||
|
=== Commitment
|
||||||
|
Q: `Is someone willing to implement it?` (this question is
|
||||||
|
especially important when reviewers propose alternative designs
|
||||||
|
to the author’s own solution).
|
||||||
|
|
||||||
|
* Yes: The author or someone else commits to implementing the
|
||||||
|
proposed solution.
|
||||||
|
* Yes: If a mentorship is required, a mentor is willing to help.
|
||||||
|
* No: Unclear ownership, mentorship or implementation plan.
|
||||||
|
|
||||||
|
=== Community
|
||||||
|
Q: `If in doubt, is there a substantial benefit to a long-standing
|
||||||
|
community member with many users?`
|
||||||
|
|
||||||
|
* The community shapes the future of Gerrit as a product. In
|
||||||
|
cases of doubt, the ESC can be more generous with long-standing
|
||||||
|
community members compared to `drive-by` contributions.
|
||||||
|
|
||||||
GERRIT
|
GERRIT
|
||||||
------
|
------
|
||||||
|
|||||||
@@ -58,6 +58,7 @@ import org.junit.runners.model.InitializationError;
|
|||||||
* public static Config firstConfig() {
|
* public static Config firstConfig() {
|
||||||
* Config cfg = new Config();
|
* Config cfg = new Config();
|
||||||
* cfg.setString("gerrit", null, "testValue", "a");
|
* cfg.setString("gerrit", null, "testValue", "a");
|
||||||
|
* return cfg;
|
||||||
* }
|
* }
|
||||||
* }
|
* }
|
||||||
*
|
*
|
||||||
@@ -66,6 +67,7 @@ import org.junit.runners.model.InitializationError;
|
|||||||
* public static Config secondConfig() {
|
* public static Config secondConfig() {
|
||||||
* Config cfg = new Config();
|
* Config cfg = new Config();
|
||||||
* cfg.setString("gerrit", null, "testValue", "b");
|
* cfg.setString("gerrit", null, "testValue", "b");
|
||||||
|
* return cfg;
|
||||||
* }
|
* }
|
||||||
*
|
*
|
||||||
* {@literal @}Test
|
* {@literal @}Test
|
||||||
|
|||||||
Reference in New Issue
Block a user