summaryrefslogtreecommitdiffstats
path: root/governance/Committer/parser project committer promotion guidline.rst
diff options
context:
space:
mode:
authorzhipengh <huangzhipeng@huawei.com>2016-04-18 23:05:58 +0800
committerzhipengh <huangzhipeng@huawei.com>2016-04-18 23:07:08 +0800
commit56c2a5d3ba6193c9a98870a264bc5e3aca19a086 (patch)
tree2b3034d3083f35331145010b1810ee902677cb64 /governance/Committer/parser project committer promotion guidline.rst
parent4e4c86a06d58b1816c074c7f9da4c58bbf10368c (diff)
Establish Parser Governance
Change-Id: I9a2963cc2bd4a77448ed7ac623582d91ff94d60d
Diffstat (limited to 'governance/Committer/parser project committer promotion guidline.rst')
-rw-r--r--governance/Committer/parser project committer promotion guidline.rst67
1 files changed, 67 insertions, 0 deletions
diff --git a/governance/Committer/parser project committer promotion guidline.rst b/governance/Committer/parser project committer promotion guidline.rst
new file mode 100644
index 0000000..c8c5448
--- /dev/null
+++ b/governance/Committer/parser project committer promotion guidline.rst
@@ -0,0 +1,67 @@
+.. This work is licensed under a Creative Commons Attribution 4.0 International License.
+.. http://creativecommons.org/licenses/by/4.0
+
+============================================
+Parser Project Committer Promotion Guideline
+============================================
+
+Note
+====
+
+This rst document serves only as a guideline for current committers and PTL to
+refer when they are electing new committers. We would strongly recommend the
+qualities listed in this document (in the Guidelines section) to be taken into
+consideration, however there is no legal or mandatory authority whatsoever.
+Any terms that might be in conflict with TSC charter is void by nature.
+
+Goal
+====
+
+* Make Parser grow stronger and healthier, with more new ideas and new people
+* Few committers that work with more contributors on a large size of work.
+* Committers number expands when Parser project itself grows.
+* Committer swap to ensure participating company’s interest.
+* Do not mandatory set limit to ban contributors to run, the ultimate result of
+a promotion is still a consensus driven by community discussion.
+
+Rationale
+=========
+
+* Committers should be a small group of core contributors that could provide
+a leading force for a balk of work in the project.
+* Parser as a small new project, growth is very important
+* For any newly proposed committers, besides KPIs like commits, they should be
+able to bring and work on an appropriate size of workload, with or without new
+work force, so that the ratio between committer numbers and the workload is
+appropriate.
+* Key mission of the committer is to expand and strengthen the project,
+with new ideas or new participants.
+
+Guidelines
+==========
+
+* For those who are proposed as committers, if other KPI holds, for approval
+they should have new work plan proposed that are beyond the work from past
+release. For those who have brought forward both new work plan as well as
+new contributors, their promotion should be considered approved in a fast
+track.
+* For those who are proposed as committers, if other KPI holds, but they only
+cover a similar size of work to the past release, for approval they should
+replace the original committer of the same company. If there is no previous
+committer member from the same company, then the promotion should be put
+through with enough discussions.
+* There will be a cap on committer number per company. It is recommended that
+each participating should not have more than 2 committers at the moment. However
+this cap subjects to modification in the future should the team decide to change.
+There is no cap for individual contributors.
+
+Guideline Creation and Modification Procedure
+=============================================
+
+* Current committers vote on this motion via email, approval require a unanimous
+consent.
+* Submit this motion as a rst file into the parser governance repo, to setup a
+precedent. PTL should kick off a review for the document each cycle.
+* Any future change to the guideline should be done via new patches and code
+reviews, with record of showing a previous committer unanimous vote result on
+the motion of such modification.