Update RFC-1 from Ulysses

.gitignore

@@ -5,3 +5,4 @@ _build
 _bikeshed
 .tox
 .vscode
+.*plist

rfc/1/review_template.md

@@ -0,0 +1,27 @@
+:orphan:
+
+# Review Template
+
+Replace the title of this file with “Review of RFC-NUM: Brief title”
+
+## Review authors
+
+## Summary
+
+## Significant comments and questions
+
+### Subheadings
+
+Structure any subheadings as necessary. 
+
+## Minor comments and questions
+
+Similarly, add any subheadings necessary
+
+## Recommendation
+
+Adopt, major, minor, reject
+
+
+conflict of interest: TODO
+TODO: place these 

rfc/1/template.md

@@ -1,3 +1,4 @@
+@: template
 # RFC Template
 
 Summary: Sentence fragment summary
@@ -65,7 +66,7 @@ that the following text SHOULD be used in all RFCs:
 
 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 [IETF RFC 2119][1]
+interpreted as described in [IETF RFC 2119](https://tools.ietf.org/html/rfc2119)
 
 ## Stakeholders (Recommended Header)
 
@@ -99,7 +100,7 @@ may result in the realization that the proposed solution in this RFC is too
 complex given the problem.
 
 For the RFC author, typing out the implementation in a high-level often serves
-as "[rubber duck debugging][2]" and you can catch a lot of
+as "[rubber duck debugging](https://en.wikipedia.org/wiki/Rubber_duck_debugging)" and you can catch a lot of
 issues or unknown unknowns prior to writing any real code.
 
 ## Drawbacks, risks, alternatives, and unknowns (Recommended Header)
@@ -195,8 +196,26 @@ Does it restrict existing assumptions or remove existing restrictions?
 
 How are implementations expected to handle these changes?
 
-## Security considerations (Optional Header)
+## Testing (Recommended Header)
+
+How will you test your feature? A typical testing strategy involves unit,
+integration, and end-to-end tests. Are our existing test frameworks and
+infrastructure sufficient to support these tests or does this proposal require
+additional investment in those areas?
+
+If your proposal defines a contract implemented by other people, how will those
+people test that they have implemented the contract correctly? Consider, for
+example, creating a conformance test suite for this purpose.
+
+## Tutorials and Examples (Recommended Header)
 
+It is strongly recommended to provide as many examples as possible of what both users and developers can expect if the RFC were to be accepted. Sample data should be shared publicly. If longer-term is not available, contact the **Editors** for assistance.
+
+## Additional considerations (Optional Header)
+
+Most RFCs will not need to consider all the following issues. They are included here as a checklist 
+
+### Security
 What impact will this proposal have on security? Does the proposal require a
 security review?
 
@@ -206,7 +225,7 @@ From there, consider how known classes of vulnerabilities might apply to the
 system and what tools and techniques can be applied to avoid those
 vulnerabilities.
 
-## Privacy considerations (Optional Header)
+### Privacy
 
 What impact will this proposal have on privacy? Does the proposal require a
 privacy review?
@@ -215,18 +234,7 @@ A good starting point is to think about how user data might be collected,
 stored, or processed by your system. From there, consider the lifecycle of such
 data and any data protection techniques that may be employed.
 
-## Testing (Recommended Header)
-
-How will you test your feature? A typical testing strategy involves unit,
-integration, and end-to-end tests. Are our existing test frameworks and
-infrastructure sufficient to support these tests or does this proposal require
-additional investment in those areas?
-
-If your proposal defines a contract implemented by other people, how will those
-people test that they have implemented the contract correctly? Consider, for
-example, creating a conformance test suite for this purpose.
-
-## UI/UX (Optional Header)
+### UI/UX
 
 If there are user- or frontend-impacting changes by this RFC, it is important
 to have a "UI/UX" section. User-impacting changes might include changes in how
@@ -242,15 +250,11 @@ feel like the rest of the ecosystem. Further, if the breaking changes are
 intolerable or there is a way to make a change while preserving compatibility,
 that should be explored.
 
-## Tutorials and Examples (Recommended Header)
-
-TODO
-
 ## Style Notes (EXAMPLE)
 
 All RFCs should follow similar styling and structure to ease reading.
 
-TODO: This section should be updated as more style decisions are made
+This section will updated as more style decisions are made
 so that users of the template can simply cut-n-paste sections.
 
 ### Heading Styles
@@ -277,13 +281,6 @@ some category or point to attention. For example, a list of API considerations:
 
 American spelling is preferred.
 
-### Typeface
-
-Type size should use this template's default configuration (11pt for body text,
-larger for headings), and the type family should be Arial. No other typeface
-customization (e.g., color, highlight) should be made other than italics, bold,
-and underline.
-
 ### Code Samples
 
 Code samples should be indented (tab or spaces are fine as long as it is
@@ -301,8 +298,4 @@ formatting as part of the user experience.
 	    }
 
 
-Note: This template is based on the [RFC template from Hashicorp][3] used with permission.
-
-[1]:	https://tools.ietf.org/html/rfc2119
-[2]:	https://en.wikipedia.org/wiki/Rubber_duck_debugging
-[3]:	https://works.hashicorp.com/articles/rfc-template
+Note: This template is based on the [RFC template from Hashicorp](https://works.hashicorp.com/articles/rfc-template) used with permission.

rfc/index.rst

@@ -2,21 +2,41 @@ RFCs
 ====
 
 .. toctree::
+   :maxdepth: 1
+   :glob:
+   :hidden:
 
-   listing
-   process
+   */index
 
 
 Requests for comments (RFCs) are used to discuss and capture
 high-level decisions within the NGFF community. Throughout
 the `specifications themselves <../specifications/>`_,
 RFCs can be referenced to provide readers further background reading.
-For example, `RFC-1 <1/>`_ defines the process in detail, but an overview
-is available under `Process <process/>`_. Authors interested in
-creating an RFC should take a look through
-the `listing <listing.html>`_ of current RFCs as well as the
-`template <1/template.html>`_ which should be copied and modified.
 
+The RFC process is defined in `RFC-1 <1/index.html>`_
+and anyone interested in participating in the RFC
+process should familiarize themselves with that text.
 
+Relevant sections describing the phases depicted in
+the diagram below include:
 
+ * `DRAFT <1/index.html#draft>`_
+ * `RFC <1/index.html#rfc>`_
+ * `SPEC <1/index.html#spec>`_
+
+A `template <1/template.html>`_ is available for the
+creation of new RFCs.
+
+Authors interested in creating an RFC may also want to take a look through
+the listing of current RFCs below.
+
+If there are any questions, please contact the editors under
 <mailto:ngff-editors@openmicroscopy.org>
+
+Listing
+-------
+
+.. csv-table:: RFC List
+   :file: listing.csv
+   :header-rows: 1