[v2] doc: process: add by-laws

The by-laws were only recorded as part of the website, move them to git
where they can be tracked.

Signed-off-by: Mike Holmes <mike.holmes@linaro.org>
---
v2:
   remove analytics

 doc/process-guide/Makefile.am       |   6 ++-
 doc/process-guide/bylaws-guide.adoc | 105 ++++++++++++++++++++++++++++++++++++
 2 files changed, 109 insertions(+), 2 deletions(-)
 create mode 100644 doc/process-guide/bylaws-guide.adoc

Merged,

took Bills review-by from first version.

Maxim.

On 01/21/2016 01:21, Mike Holmes wrote:
> The by-laws were only recorded as part of the website, move them to git
> where they can be tracked.
>
> Signed-off-by: Mike Holmes <mike.holmes@linaro.org>
> ---
> v2:
>     remove analytics
>
>   doc/process-guide/Makefile.am       |   6 ++-
>   doc/process-guide/bylaws-guide.adoc | 105 ++++++++++++++++++++++++++++++++++++
>   2 files changed, 109 insertions(+), 2 deletions(-)
>   create mode 100644 doc/process-guide/bylaws-guide.adoc
>
> diff --git a/doc/process-guide/Makefile.am b/doc/process-guide/Makefile.am
> index 95915c0..9fc3b80 100644
> --- a/doc/process-guide/Makefile.am
> +++ b/doc/process-guide/Makefile.am
> @@ -1,8 +1,10 @@
>   include ../Makefile.inc
>   
> -TARGET = release-guide.html
> +TARGET = bylaws-guide.html \
> +	 release-guide.html
>   
> -EXTRA_DIST = release-guide.adoc
> +EXTRA_DIST = bylaws-guide.adoc \
> +	     release-guide.adoc
>   
>   all-local: $(TARGET)
>   
> diff --git a/doc/process-guide/bylaws-guide.adoc b/doc/process-guide/bylaws-guide.adoc
> new file mode 100644
> index 0000000..e640811
> --- /dev/null
> +++ b/doc/process-guide/bylaws-guide.adoc
> @@ -0,0 +1,105 @@
> +:doctitle: OpenDataPlane (ODP)  By-laws-Guide
> +:description: This document is intended to guide a new application developer +
> +in understanding the by-laws
> +:toc:
> +:numbered!:
> +[abstract]
> +Abstract
> +--------
> +This document is intended to guide a new application developer in
> +understanding the by-laws.
> +
> +The ODP project has established a set of by-laws defining the operational
> +processes by which direction of ODP resources is determined and how the product
> +is managed.
> +
> +The by-laws define roles, stewardship/management, patch approvals, voting
> +procedures, and reporting (Roadmap) requirements.
> +
> +Further details about ODP may be found at the http://opendataplane.org[ODP]
> +home page.
> +
> +:numbered:
> +
> +== Roles considered
> +=== Users
> +People that use the project and submit bugs and request new features to the
> +project.
> +
> +=== Contributors
> +All of the volunteers who are contributing time, code, documentation, or
> +resources to the project. A contributor that makes sustained, welcome
> +contributions to the project may be invited to become a maintainer, though the
> +exact timing of such invitations depends on many factors.
> +
> +If a contributor wants to move the project in direction X or add feature Y, and
> +that requires a lot of rewrite in the existing code-base then:
> +
> +* explain that in an email to the mailing list.
> +* send out RFCs (early and often) with example code, so the community (and
> +maintainers) can see what you want and say if it fits or not.
> +
> +The above helps find and solve common problems among contributors.
> +
> +=== Maintainer(s)
> +* The maintainer for a project have push rights to the main repo. Only one
> +maintainer. The most trustworthy sub-maintainer shall step in and take over the
> +maintainer ship as required.
> +* Sub-maintainer(s) one or many for the different modules in the project.
> +* Sub-maintainers shall focus on ensuring that the current code base has good
> +quality and review new patches to maintain that good quality.
> +* When Maintainers accept code, they have to deal with it until they die or rip
> +it out (so its important that they understand what the code does and why they
> +need it). The contributor shall convince the maintainer to take their code (the
> +maintainer should feel like he would be stupid to not accept the code…)
> +
> +=== Release Manager ===
> +
> +* The RM shall publish a Release Plan on the roadmap. One week before the
> +release the candidate list will be reviewed.
> +* The RM is responsible for building consensus around the content of the
> +Release.
> +
> +== Roadmap
> +The roadmap shall state projected future releases and the expected content.
> +
> +== Steering Committee (SC)
> +* Defining the requirements for the project’s shared resources, email
> +  lists and the homepage.
> +* Speaking on behalf of the project.
> +* Resolving license disputes regarding products of the project.
> +* Nominating new PMC members and committers.
> +* Maintaining these by-laws and other guidelines of the project.
> +* Planning the roadmap (shall state projected future releases and the expected
> +content).
> +
> +=== Patch approval
> +Reviewed-by is only replied to the list after inspecting the code. If you have
> +review comments they should be constructive and not just saying “no”.
> +Reviewed-by and Signed-off-by implies that you are co-responsible for any bugs
> +found in the code.
> +
> +If you don’t respond you are assumed to agree with the patch.
> +
> +== Voting ==
> +Voting is necessary if consensus not has been reached. Must have established
> +quorum.
> +
> +* “Yes”, “Agree”,"+1"	the action should be performed.
> +In general, this vote also indicates a willingness on the behalf of the voter in
> +“making it happen”
> +
> +* “Abstain”	This vote indicates that the voter abstains.
> +The voter has no interest or does not participate in the vote.
> +
> +* “No”, “Disagree” "-1"	the action should not be performed.
> +On issues where consensus is required, this vote counts as a veto. All vetoes
> +must contain an explanation of why the veto is appropriate. Vetoes with no
> +explanation are void. It may also be appropriate for a -1 vote to include an
> +alternative course of action.
> +
> +== Adding new features ==
> +
> +If person X adds a new feature (API group X) then he should/could be asked to
> +be the maintainer for that feature. Code (old or new) is likely to be removed
> +if it is unmaintained.