diff options
author | zhipengh <huangzhipeng@huawei.com> | 2017-03-02 11:51:07 +0800 |
---|---|---|
committer | zhipengh <huangzhipeng@huawei.com> | 2017-03-02 12:05:07 +0800 |
commit | 53b22cfb7ad8b323073213e4e55584261dd4e50a (patch) | |
tree | fc8c6bed95c2dc66cb812b7023bafdbd2799d3a6 /docs/governance/committer/parser project committer promotion guidline.rst | |
parent | 9a2b86ff190a16822ec3f68b2c1d070d54a47da9 (diff) |
Danube Release Docs Fixup patch 1
Done in this patch
1. Fixes in overview.rst
2. Moves governance folder under docs
3. Adds arno release use case doc from
https://wiki.opnfv.org/display/parser/Parser+Use+Cases to the
requirement folder
4. Moves two old tosca2heat documents into developer/design/examples
5. Adds new empty tosca2heat and verigraph design document under
developer/design.
6. Remove old contents in yang2tosca and policy2tosca design docs since
they are all related to installation/execution, not design.
7. Fixes in installation.instruction.rst and usage,guide.rst
To do in the following patches
1. Design doc writeup: Xiaodong(tosca2heat),
Shiva(yang2tosca/policy2tosca), Serena(verigraph)
2. Release doc writeup: Xiaodong and Howard
(postinstall.rst,scenario.description.rst), Serena(verigraph part of
release-notes.rst), release-notes.rst
Change-Id: If4f51067dd33acd2332e503ee31d6941b4df4c89
Signed-off-by: zhipengh <huangzhipeng@huawei.com>
Diffstat (limited to 'docs/governance/committer/parser project committer promotion guidline.rst')
-rw-r--r-- | docs/governance/committer/parser project committer promotion guidline.rst | 68 |
1 files changed, 68 insertions, 0 deletions
diff --git a/docs/governance/committer/parser project committer promotion guidline.rst b/docs/governance/committer/parser project committer promotion guidline.rst new file mode 100644 index 0000000..cc65a2d --- /dev/null +++ b/docs/governance/committer/parser project committer promotion guidline.rst @@ -0,0 +1,68 @@ +.. 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 + contributors. +* Few committers who 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. +* As a small new project, the growth of Parser 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. |