Skip to content

HTTPS clone URL

Subversion checkout URL

You can clone with HTTPS or Subversion.

Download ZIP
Browse files

Merge pull request #2 from bschussek/workflow-bylaw

WIP Improvements
  • Loading branch information...
commit 067c7d44b75386a7474ea466ada6c42c1ec9bd76 2 parents 235ef58 + d0f06c6
@philsturgeon philsturgeon authored
Showing with 38 additions and 12 deletions.
  1. +38 −12 bylaws/004-psr-workflow.md
View
50 bylaws/004-psr-workflow.md
@@ -1,10 +1,36 @@
# PSR Review Workflow
-Each PSR must have an original author and potentially a co-author in some cases, neither of which are
-required to be a voting member. Each PSR must also have two co-sponsors, both of whom are voting members
-and one of whom is a "coordinator" (they can switch if needs be).
+The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD",
+"SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be
+interpreted as described in [RFC 2119](http://tools.ietf.org/html/rfc2119).
-### 0.) Pre-Draft
+
+## 1. Roles
+
+**Author:** An author is actively involved in writing a PSR. A document MAY have multiple authors. Neither
+of them is REQUIRED to be a voting member.
+
+**Sponsor:** A voting member who officially supports a proposal. Each PSR MUST have two sponsors that
+MUST NOT include the author himself.
+
+> Why two and not just one?
+
+**Coordinator:** One of the sponsors is the coordinator of a PSR. The coordinator is in charge of the
+voting process. He notes the starting and ending dates, the number of voting members at the start of the
+vote, and the quorum count needed. He sends out reminders by whatever means he feels appropriate to drive
+the vote. At the end of the voting period, he tallies the votes, notes if quorum was established, and
+whether or not the application was accepted.
+
+> Note: copied from [Paul M. Jones' mail](https://groups.google.com/d/msg/php-fig/I0urcaIsEpk/uqQMb4bqlGwJ)
+
+**Contributor:** Anyone who feels like they have done a relevant amount of contribution. Includes anyone
+sending in a pull request during the Pre-Draft or Draft stages and anyone who feels like their review
+tweaks were relevant too. In case of doubt, the voters SHOULD use reasonable judgement to decide whether
+a contribution was relevant or not.
+
+## 2. Stages
+
+### 2.1 Pre-Draft
The author(s) can work on this anywhere they like, do whatever they like and come up with any ideas they
feel are within the scope of the PHP-FIG. Once the Pre-Draft content is considered ready by the author(s)
@@ -20,13 +46,13 @@ extension (Eg: "autoload-meta.md").
With both of these documents in the proposed folder, the author(s) can start to look for their sponsors, who
will then initiate a vote to make it reach "Draft".
-### 1.) Draft
+### 2.2 Draft
The author(s) and any contributors can make any changes they see fit via pull requests, comments on GitHub,
mailing list threads and IRC. Change here is not limited by any strict rules, and funamental rewrites are
possible if supported by the author(s).
-### 2.) Review
+### 2.3 Review
Once a PSR has reached Review the author must create a Pull Request on the official PHP-FIG ["fig-standards"
repo][repo] against the `master` and the file will remain in the `/proposed` folder with the same name.
@@ -36,13 +62,13 @@ While a PSR remains in Review, changes are limited to wording, typos, clarificat
etc. The author(s) and sponsors may use their own judgement to control the scope of these changes, and
block anything that is felt to be a fundamental change.
-### 3.) Accepted
+### 2.4 Accepted
An Acceptance vote is called when the coordinator feels the Review document is ready to have it's final vote.
If this vote passes then the Pull Request is merged, and the document is moved by a FIG member with
GitHub access from `/proposed` to `/accepted` and assigned a PSR number by incrementing the preview PSR number.
-## Progress
+## 3. Progress
Initially a vote must be called by the "coordinator" to get the PSR into Draft status, before that it's just
a third-party concept.
@@ -56,12 +82,12 @@ If the vote fails the author(s) can use feedback to improve and keep it in Revie
another vote later on. The author(s) also have the option of going back to the drawing board if their ideas
are slammed multiple times, meaning they need to tell folks they are back in Draft status.
-## Meta Document
+## 4. Meta Document
Each PSR must also contain a "Meta Document" to hold relevant information such as who the author(s) are,
who the sponsors are, which one is the "coordinator" and list any relevant contributors.
-### Author(s) and Sponsors
+### 4.1 Author(s) and Sponsors
Each PSR must contain author(s) and sponsors names listed in the document body. In the event that an author would
like to step down from their position mid-way then the a named author must listing the new author in the meta
@@ -76,14 +102,14 @@ would be invalidated until a new sponsor has been put in place. This would need
before it can be voted upon again - sticking to the two-week wait on votes which is the case for any and all votes,
as specified in the Voting Protocol.
-### Contributors
+### 4.2 Contributors
Anyone who feels like they have done a relevant amount of contribution should add themselves to the
meta document. Ideally anyone sending in a pull request during the Pre-Draft or Draft stages should go on here,
and anyone who feels like their review tweaks were relevant too. The author can use reasonable judgement for
this.
-### Example
+### 4.3 Example
This is an example template that can be used to build a meta document.
Please sign in to comment.
Something went wrong with that request. Please try again.