IIP-0001: Add description of the editor role in the IIP process

IIP_0001.md

@@ -31,7 +31,8 @@ There are three kinds of IIP:
 * A Process IIP describes a process surrounding ION, or proposes a change to (or an event in) a process. Process IIPs are like Standards Track IIPs but apply to areas other than the ION protocol itself. They may propose an implementation, but not to ION's codebase; they often require community consensus; unlike Informational IIPs, they are more than recommendations, and users are typically not free to ignore them. Examples include procedures, guidelines, changes to the decision-making process, and changes to the tools or environment used in ION development. Any meta-IIP is also considered a Process IIP.
 
 ## IIP Workflow
-The IIP process begins with a new idea for ION. Each potential IIP must have a champion -- someone who writes the IIP using the style and format described below, shepherds the discussions in the appropriate forums, and attempts to build community consensus around the idea. The IIP champion (a.k.a. Author) should first attempt to ascertain whether the idea is IIP-able. 
+
+The IIP process begins with a new idea for ION. Each potential IIP must have a champion -- someone who writes the IIP using the style and format described below, shepherds the discussions in the appropriate forums, and attempts to build community consensus around the idea. The IIP champion (a.k.a. Author) should first attempt to ascertain whether the idea is IIP-able.
 
 Vetting an idea publicly before going as far as writing an IIP is meant to save both the potential author and the wider community time. Many ideas have been brought forward for changing ION that have been rejected for various reasons. Asking the ION community first if an idea is original helps prevent too much time being spent on something that is guaranteed to be rejected based on prior discussions (searching the internet does not always do the trick). It also helps to make sure the idea is applicable to the entire community and not just the author. Just because an idea sounds good to the author does not mean it will work for most people in most areas where ION is used. Small enhancements or patches often don't need standardisation between multiple projects; these don't need an IIP and should be injected into the relevant ION development workflow with a patch submission to the applicable ION issue tracker.
 
@@ -64,6 +65,33 @@ The possible paths of the status of IIPs are as follows:
 
 Some Informational and Process IIPs may also have a status of "Active" if they are never meant to be completed. E.g. IIP 1 (this IIP).
 
+### IIP Editor Responsibilities & Workflow
+
+For each new IIP that comes in an editor does the following:
+
+* Read the IIP to check if it is ready: sound and complete. The ideas must make technical sense, even if they don't seem likely to be accepted.
+* The title should accurately describe the content.
+* The IIP draft must have been sent to the community for discussion (e.g. the ION Discord chat).
+* Motivation and backward compatibility (when applicable) must be addressed.
+* The defined Layer header must be correctly assigned for the given specification.
+* Licensing terms must be acceptable for IIPs.
+
+If the IIP isn't ready, the editor will send it back to the author for revision, with specific instructions.
+
+Once the IIP is ready for the repository it should be submitted as a "pull request" to the [IIPs git repository](https://github.com/ionomy/iip) where it may get further feedback.
+
+The IIP editor will:
+
+* Assign a IIP number in the pull request.
+
+* Merge the pull request when it is ready.
+
+* List the IIP in [README.md](README.md)
+
+The IIP editors are intended to fulfill administrative and editorial responsibilities. The IIP editors monitor IIP changes, and update IIP headers as appropriate.
+
+IIP editors may also, at their option, unilaterally make and merge strictly-editorial changes to IIPs, such as correcting misspellings, fixing broken links, etc.
+
 ## What belongs in a successful IIP?
 
 Each IIP should have the following parts:
@@ -75,4 +103,4 @@ Each IIP should have the following parts:
 * __Rationale__ — The rationale fleshes out the specification by describing what motivated the design and why particular design decisions were made. It should describe alternate designs that were considered and related work, e.g. how the feature is supported in other languages.
   * The rationale should provide evidence of consensus within the community and discuss important objections or concerns raised during discussion.
 * __Backwards Compatibility__ — All IIPs that introduce backwards incompatibilities must include a section describing these incompatibilities and their severity. The IIP must explain how the author proposes to deal with these incompatibilities. IIP submissions without a sufficient backwards compatibility treatise may be rejected outright.
-* __Reference Implementation__ — The reference implementation must be completed before any IIP is given status "Final", but it need not be completed before the IIP is accepted. It is better to finish the specification and rationale first and reach consensus on it before writing code. The final implementation must include test code and documentation appropriate for the ION protocol.
+* __Reference Implementation__ — The reference implementation must be completed before any IIP is given status "Final", but it need not be completed before the IIP is accepted. It is better to finish the specification and rationale first and reach consensus on it before writing code. The final implementation must include test code and documentation appropriate for the ION protocol.