From 078ad84e0026ffdf9a817c7f0a2be96e8de7c6b8 Mon Sep 17 00:00:00 2001 From: Patrick Hiesel Date: Tue, 24 Mar 2020 10:04:18 +0100 Subject: [PATCH] Document how the ESC evaluates design docs Change-Id: I18defbd1fd540677c73d4104ff0cf4341fed2898 (cherry picked from commit c49eea244730309ca177f7779c74518c056a274d) --- Documentation/dev-contributing.txt | 73 ++++++++++++++++++++++++++++++ 1 file changed, 73 insertions(+) diff --git a/Documentation/dev-contributing.txt b/Documentation/dev-contributing.txt index 0bac643f41..ff00471788 100644 --- a/Documentation/dev-contributing.txt +++ b/Documentation/dev-contributing.txt @@ -244,6 +244,79 @@ over, changes that have already been submitted for the feature might get reverted so that there is no unused or half-finished code in the code base. +[[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 ------ Part of link:index.html[Gerrit Code Review]