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>

1 files changed, 0 insertions, 68 deletions

diff --git a/governance/Committer/parser project committer promotion guidline.rst b/governance/Committer/parser project committer promotion guidline.rst
deleted file mode 100644
index cc65a2d..0000000
--- a/governance/Committer/parser project committer promotion guidline.rst
+++ /dev/null
@@ -1,68 +0,0 @@
-.. 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.