first pass of RFC refactor

Author: joeyaiello

RFC0000-RFC-Process.md

@@ -3,7 +3,7 @@ RFC: RFC0000
 Author: Steve Lee
 Status: Draft
 Area: Process
-Version: 1.3.1
+Version: 1.4
 Feedback: https://github.com/PowerShell/PowerShell-Language-RFC/issues/5
 ---
 
@@ -14,7 +14,7 @@ This provides the community an opportunity to provide feedback before code is wr
 compatibility.
 The complete list of RFCs are available at https://github.com/powershell/powershell-rfc
 
-This process was adapted from the Chef RFC process as well as from DMTF.org process.
+This process was adapted from the Chef RFC process as well as from the DMTF.org process.
 
 ## Roles
 
@@ -23,19 +23,19 @@ This process was adapted from the Chef RFC process as well as from DMTF.org proc
 (Learn more about the PowerShell Committee [here](https://github.com/PowerShell/PowerShell/blob/master/docs/community/governance.md#powershell-committee).)
 * **Committee Member**: An individual member of the PowerShell Committee.
 
-## RFC Naming Convention
+## RFC Submission Convention
 
-RFC documents shall follow the naming convention of "RFCNNNN-Title.md".
-Authors of RFCs do not assign an RFC number.
-When the Pull Request is submitted, ensure `Allow edits from maintainers` is checked so that the Committee can add the RFC number to the draft and also update the title accordingly.
+* When submitted, RFC documents shall follow the naming convention of `RFCNNNN-<Title>.md`.
+* Authors of RFCs shall not assign the RFC number (leave the `NNNN` in the filename).
+* When the Pull Request is submitted, the author shall select `Allow edits from maintainers` is checked so that the Committee can add the RFC number to the draft, update the title, and fix the filename.
 
 ## RFC Template
 
 RFC documents shall follow the following template:
 
 ```markdown
 ---
-RFC: RFC<four digit unique incrementing number - assigned by Committee>
+RFC: RFC<four digit unique incrementing number assigned by Committee, this should be left blank by the author>
 Author: <First Last>
 Status: <Draft | Experimental | Accepted | Rejected | Withdrawn | Final>
 SupercededBy: <link to another RFC>
@@ -62,59 +62,53 @@ Description and rationale.
 
 ## RFC Workflow
 
-RFCs go through applicable stages:
+RFCs may go through the following stages:
 
-* Draft
+### Draft
+ 
+This is the initial draft of an RFC posted for comments and considered a work-in-progress.
 
-This is the initial draft of a RFC posted for comments and considered a work-in-progress.
+* New proposed drafts should be submitted as a Pull Request from the Author's fork into the `Draft-Accepted` folder.
+* The Author shall ensure that the `Allow edits from maintainers` box is checked so that a Committee Member can assign the next RFC number.
+* If the Pull Request has followed the correct template and process, a Committee Member will assign the label `Review - Open for comments` to the Pull Request to indicate that anyone can comment on the content of the submission.
+Typically, one or two months is allowed for comments, though this may be extended if a submission is particularly conentious or hasn't received enough feedback for the Committee to feel comfortable making a decision.
+* When the Committee closes the comment period, the Author should update the RFC and Pull Request to address the comments.
+* The Committee shall vote to accept or reject the RFC and accept/close the Pull Request accordingly.
 
-New proposed drafts should be submitted as a Pull Request from the Author's fork.
-The Author must ensure that 'Allow edits from maintainers' is checked so that a Committee Member can assign the next RFC number.
+### Draft-Accepted
 
-Committee Members also ensure that the RFC adheres to the template and the RFC process before merging the Pull Request.
+The PowerShell Committee has reviewed the RFC and comments, and has voted to accept the RFC as a Draft.
 
-After the Pull Request is merged, Maintainers will ask the Author to create an issue for this RFC to collect and respond to feedback on the RFC.
-(The Author should create issue so that they get notified of new comments instead of the Committee Member.)
-Typically, one or two months is allowed for comments (see `Comments Due` above).
+* New comments are not being sought.
+* No one has begun implementing the RFC, and there are no current plans to implement the RFC.
+* The community is invited to implement the RFC (unless explicitly stated in the RFC).
 
-At this point, the community discusses the RFC.
+### Experimental
 
-After the `Comments Due` date, the Author summarizes the comments, submits a new Pull Request to make the final RFC Draft, and asks the PowerShell Committee to vote.
+RFCs in the `Experimental` stage have been accepted by the Committee, and code is being written to provide a working example of the proposed design change to get additional feedback.
 
-Just before voting, the PowerShell Comittee merges the Pull Request.
-The PowerShell Committee then votes to accept or reject the RFC Draft.
+### Experimental-Accepted
 
-* Draft-Accepted
-
-The PowerShell Committee has reviewed the RFC Draft and comments, and has voted to accept the RFC Draft.
-
-At this point, new comments are not being sought.
-
-No one has begun implementing the RFC, and there are no current plans to implement the RFC.
-
-The community is invited to implement the RFC.
-
-* Experimental
-
-Comments have been reviewed and code is being written to provide an working example of the proposed design change to get further feedback.
+Feedback from the experimental implementation and RFC have been reviewed.
 
-* Experimental-Accepted
+Because this working prototype already exists in preview builds available on GitHub, the community provide feedback on the implementation as issues in the [PowerShell/PowerShell repository](https://github.com/powershell/powershell) 
 
-Feedback from the experimental implementation and RFC have been reviewed.
-Engineering team will work towards final implementation in code to match the RFC.
+As the engineering team or code contributor works towards a final implementation, they should submit pull requests to PowerShell-RFC in order to keep the RFC in sync with the implementation.
+These pull requests shall be reviewed and accepted by the Committee, but a formal vote is not necessary.
+The Committee should merely confirm that the changes in the RFC match the working implementation.
 
-* Rejected
+### Rejected
 
-Based on community feedback, this RFC was decided to not proceed any further.
+RFCs in the `Rejected` state were rejected by the Committee who decided not to proceed further.
 
-* Withdrawn
+### Withdrawn
 
-Author has decided not to pursue this RFC any further
+RFCs in the `Withdrawn` state were rescinded by the RFC Author.
 
-* Final
+### Final
 
-Design and implementation is considered complete.
-Any proposed changes would be through a new RFC.
+RFCs in the `Final` state are considered fully complete and implemented in PowerShell.
+Any proposed changes should be made through a new RFC or via an Issue in the [PowerShell/PowerShell repository](https://github.com/powershell/powershell).
 
 ## History
 v1.1 - 5-20-2016 - Updated to enable RFCs for design changes that don't require code changes.
@@ -125,3 +119,6 @@ v1.2 - 8-18-2016 - Open submitting RFCs to the community and update formatting.
 v1.3 - 9-26-2016 - Added Withdrawn stage.  Comments Due field to template.  Updated guidance on RFC numbering.
 
 v1.3.1 - 3-22-2017 - Cleaned up language and made explicit clarifications to process
+
+v1.4 - 3-31-2017 - Revised the RFC process to leverage pull requests for comments instead of issues.
+Continued cleanup of language and formatting.