From patchwork Wed Jan 20 22:21:20 2016 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Patchwork-Submitter: Mike Holmes X-Patchwork-Id: 60052 Delivered-To: patch@linaro.org Received: by 10.112.130.2 with SMTP id oa2csp3438140lbb; Wed, 20 Jan 2016 14:21:35 -0800 (PST) X-Received: by 10.140.134.197 with SMTP id 188mr52350780qhg.58.1453328495879; Wed, 20 Jan 2016 14:21:35 -0800 (PST) Return-Path: Received: from lists.linaro.org (lists.linaro.org. [54.225.227.206]) by mx.google.com with ESMTP id 7si46012023qgy.13.2016.01.20.14.21.35; Wed, 20 Jan 2016 14:21:35 -0800 (PST) Received-SPF: pass (google.com: domain of lng-odp-bounces@lists.linaro.org designates 54.225.227.206 as permitted sender) client-ip=54.225.227.206; Authentication-Results: mx.google.com; spf=pass (google.com: domain of lng-odp-bounces@lists.linaro.org designates 54.225.227.206 as permitted sender) smtp.mailfrom=lng-odp-bounces@lists.linaro.org; dkim=neutral (body hash did not verify) header.i=@linaro.org Received: by lists.linaro.org (Postfix, from userid 109) id 2F81F6165F; Wed, 20 Jan 2016 22:21:35 +0000 (UTC) Authentication-Results: lists.linaro.org; dkim=fail reason="verification failed; unprotected key" header.d=linaro.org header.i=@linaro.org header.b=KwZOMqtm; dkim-adsp=none (unprotected policy); dkim-atps=neutral X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on ip-10-142-244-252 X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=BAYES_00,DKIM_SIGNED, RCVD_IN_DNSWL_LOW,RCVD_IN_MSPIKE_H2,T_DKIM_INVALID,URIBL_BLOCKED autolearn=disabled version=3.4.0 Received: from [127.0.0.1] (localhost [127.0.0.1]) by lists.linaro.org (Postfix) with ESMTP id 99DE36165F; Wed, 20 Jan 2016 22:21:28 +0000 (UTC) X-Original-To: lng-odp@lists.linaro.org Delivered-To: lng-odp@lists.linaro.org Received: by lists.linaro.org (Postfix, from userid 109) id 28246616E7; Wed, 20 Jan 2016 22:21:27 +0000 (UTC) Received: from mail-qg0-f52.google.com (mail-qg0-f52.google.com [209.85.192.52]) by lists.linaro.org (Postfix) with ESMTPS id 2B363615F6 for ; Wed, 20 Jan 2016 22:21:26 +0000 (UTC) Received: by mail-qg0-f52.google.com with SMTP id 6so18178835qgy.1 for ; Wed, 20 Jan 2016 14:21:26 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=from:to:cc:subject:date:message-id:mime-version:content-type :content-transfer-encoding; bh=AUSRFhfWZPYyugsUSAZMKHy2Px2rLPqjCA1g48ZHq/A=; b=KwZOMqtmhOZDmB1t13TWIs2O2l5b2tFeL4UC5MTBkZMDdAZFe2FxLkHwP2zZ6BwiVE AcwlQYB+5ay3YOOZRRc/VxC7tLU0+YPvNCJXUfRldmy6B0l8hrhg5syW6zoFO8+piJpo 7IqgmFgvt2y2JtUwMg2AARHre6Yr+cCF62mu4= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:to:cc:subject:date:message-id:mime-version :content-type:content-transfer-encoding; bh=AUSRFhfWZPYyugsUSAZMKHy2Px2rLPqjCA1g48ZHq/A=; b=Mrc8I/wScy/cI8ZmMkdzG8Gt5smh3t83IP+WnJStcXj0h28FO2jlNv9AGmrWw7EqoL +PxpgeZ+qp29SWqtMq2/uUmOZ0uEOhtDiPAsKVZ6/ddielqm111IQrRMwRbdbPyhAtM/ ij6/pRUOPTy4ZyETNLyWWqVVqXU+hC0VleFlLf0hlZoQ831zesy9t9VIQ7eidwCSK3RD d6qSCCSMRRcNjsX66d4ct+xzdhW4w55D64ua7kS0ClRncf9YNmYJyQ9lszJLkWbL3jSP veeflDG2iHT4+wnLwMaGQ8/xtorAUHwZ0y02FFfpySY+9p5mnJk6xW5L3260s6sMUw1s dcsQ== X-Gm-Message-State: ALoCoQnieXuVWbY+VTDKBAWR/1z1H8Pb+L/CW9/sT6ZTQoQGPmoBDu6RNAQZcJflQhOp3IMsv+/6jp143Js5IVunexY9NVuBpg== X-Received: by 10.140.223.148 with SMTP id t142mr50675649qhb.65.1453328485964; Wed, 20 Jan 2016 14:21:25 -0800 (PST) Received: from localhost.localdomain (c-98-221-136-245.hsd1.nj.comcast.net. [98.221.136.245]) by smtp.gmail.com with ESMTPSA id b135sm15213383qka.2.2016.01.20.14.21.25 (version=TLS1_2 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Wed, 20 Jan 2016 14:21:25 -0800 (PST) From: Mike Holmes To: lng-odp@lists.linaro.org Date: Wed, 20 Jan 2016 17:21:20 -0500 Message-Id: <1453328480-15701-1-git-send-email-mike.holmes@linaro.org> X-Mailer: git-send-email 2.5.0 MIME-Version: 1.0 X-Topics: patch Subject: [lng-odp] [PATCH v2] doc: process: add by-laws X-BeenThere: lng-odp@lists.linaro.org X-Mailman-Version: 2.1.16 Precedence: list List-Id: "The OpenDataPlane \(ODP\) List" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: lng-odp-bounces@lists.linaro.org Sender: "lng-odp" 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 --- 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.