Rework process to use pull requests instead of issues

QEP-0-Template.md

@@ -6,8 +6,6 @@
 
 **Contact** user at domain dot tld
 
-**maintainer** @user
-
 **Version** QGIS X.X
 
 # Summary
@@ -16,19 +14,27 @@
 
 ## My Section
 
-(optional) Insert custom sections wherever needed
+*(optional)* Insert custom sections wherever needed
 
 ## Proposed Solution
 
-(required)
+*(required)*
+
+## Deliverables
+
+*(required for QGIS grant submissions)*
 
 ### Example(s)
 
-(optional)
+*(optional)*
 
 ### Affected Files
 
-(required if applicable)
+*(optional)*
+
+## Risks
+
+*(required)*
 
 ## Performance Implications
 
@@ -40,12 +46,8 @@
 
 ## Backwards Compatibility
 
-**(required)**
+**(required if applicable)**
 
 ## Issue Tracking ID(s)
 
 *(optional)*
-
-## Votes
-
-(required)

README.md

@@ -1,26 +1,55 @@
 QEP Process and workflow
 ---
 
-QEP's (QGIS Enhancement Proposals) are used in the process of creating and discussing new enhancements or policy for QGIS
-
-All QEP's are created as new [issues](https://github.com/qgis/QGIS-Enhancement-Proposals/issues).  Create a new ticket using the [template](https://raw.githubusercontent.com/qgis/QGIS-Enhancement-Proposals/master/QEP-0-Template.md)
+QEP's (QGIS Enhancement Proposals) are used in the process of creating and discussing new enhancements or policy for
+QGIS
 
 QEP's should generally be created for (only examples):
 
 - Large application wide changes (e.g major UI redesign)
 - Large work with wider scope (e.g something that might effect how layers are loaded.)
-- Community processes and policies (e.g 3.0 release)
+- Community processes and policies (e.g 3.0 release, changes to coding conventions)
 
 Generally smaller features do not require a QEP unless they can have large knock on effect.
 
-## Process
-
-- A QEP must be open for at least two weeks. This may be extended upon request (eg, "I'm on holidays but have feedback to give").
-- Newly submitted QEPs should be announced to the community via a message to the [QGIS Developer Mailing List](https://www.qgis.org/community/organisation/mailinglists/#qgis-developers-list). The [QGIS User Mailing List](https://www.qgis.org/community/organisation/mailinglists/#qgis-users-list) should also be messaged if the changes impact on QGIS end-users.
-- Comments from the **whole** community are invited and valuable! You do not need any special permissions or status in order to give feedback. We welcome feedback from all parties, whether you're a developer, a documenter, a translator or an end-user.
-- For acceptance, a QEP requires at least 2 +1's from core QGIS developers or PSC members
-- If -1 votes are received from core QGIS developers, then the proposal should be amended or further discussion conducted to satisfy all interested parties. If consensus cannot be reached, the QEP can be raised to the PSC for voting.
-- A PR can also be opened at the same time - *this is done at the developer's own risk as the proposal may be rejected and the development effort wasted*
+QEPs which describe project policies (such as those which describe coding conventions, acceptable practice for Pull
+Request reviews, etc) are mutable, and can be revised
+in future. See Processes and Policies section below for a description on how to amend an existing QEP.
+
+## Process and policies
+
+If you are:
+
+- **Proposing a brand new QEP**: make a copy of the [QEP-0-Template.md](QEP-0-Template.md) file, populate the template
+  and rename as required. Submit a Pull Request to this repository adding your new QEP file.
+- **Proposing a change to an existing QEP**: just submit a Pull Request which modifies the corresponding QEP markdown
+  file accordingly.
+
+The same policies apply whether you a proposing a new QEP or a change to an existing QEP:
+
+- The proposal must be open for at least two weeks. This may be extended upon request (eg, "I'm on holidays but have
+  feedback to give").
+- Proposals (both for new QEPs and amendments to existing QEPs) should be announced to the community via a message to
+  the [QGIS Developer Mailing List](https://www.qgis.org/community/organisation/mailinglists/#qgis-developers-list).
+  The [QGIS User Mailing List](https://www.qgis.org/community/organisation/mailinglists/#qgis-users-list) should also be
+  messaged if the changes impact on QGIS end-users.
+- Comments from the **whole** community are invited and valuable! You do not need any special permissions or status in
+  order to give feedback. We welcome feedback from all parties, whether you're a developer, a documenter, a translator
+  or an end-user.
+- For acceptance, a proposal requires at least 2 +1's from core QGIS developers or PSC members
+- If -1 votes are received from core QGIS developers, then the proposal should be amended or further discussion
+  conducted to satisfy all interested parties. If consensus cannot be reached, the proposal can be raised to the PSC for
+  voting.
+- A PR can also be opened at the same time - *this is done at the developer's own risk as the proposal may be rejected
+  and the development effort wasted*
+
+When the discussion and voting period ends, one of the following actions are taken:
+
+- **If the proposal was accepted**: the Pull Request should be amended, making sure that the QEP markdown file correctly
+  reflects the final accepted form of the proposal. It should then be merged. Please announce
+  to [QGIS Developer Mailing List](https://www.qgis.org/community/organisation/mailinglists/#qgis-developers-list) the
+  outcome of the proposal.
+- **If the proposal was rejected**: the Pull Request should be closed
 
 ## FAQ