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
|
||||
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.
|
||||
@@ -307,6 +315,7 @@ Q: `Would this fit better in a plugin?`
|
||||
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.
|
||||
@@ -315,8 +324,94 @@ to the author’s own solution).
|
||||
=== 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.
|
||||
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
|
||||
------
|
||||
|
||||
@@ -58,6 +58,7 @@ import org.junit.runners.model.InitializationError;
|
||||
* public static Config firstConfig() {
|
||||
* Config cfg = new Config();
|
||||
* cfg.setString("gerrit", null, "testValue", "a");
|
||||
* return cfg;
|
||||
* }
|
||||
* }
|
||||
*
|
||||
@@ -66,6 +67,7 @@ import org.junit.runners.model.InitializationError;
|
||||
* public static Config secondConfig() {
|
||||
* Config cfg = new Config();
|
||||
* cfg.setString("gerrit", null, "testValue", "b");
|
||||
* return cfg;
|
||||
* }
|
||||
*
|
||||
* {@literal @}Test
|
||||
|
||||
Reference in New Issue
Block a user