Adding Informational RFCs

[brianraymor]

Raised by @briandoconnor in his review of the RFC process. See the discussion.

In the Commons we've used informational RFCs to communicate what a given working group has done over a 6 month period. For example, we have a working group on GUIDs. That group made an informational RFC that covered the different GUID types they explored, how they work, benefits, etc. And that was passed to other groups as a "here's what you need to know if you haven't been attending the call over the last 6 months"... it seems to be a very efficient communication mechanism. Since the stakes are lower for these, maybe the goal is to collect comments but, eventually, the RFC period ends and the informational RFC is just collected as a point of reference? There's no reason to build consensus per se since it's just reporting back information to other groups. I'm not sure but I think that could be helpful in the HCA project but maybe less so than in the Commons since there are fewer groups doing exploration work and needing to report back. It would be nice to have the informational RFC as an option, though, to have a framework to discuss items in a structured way.

Notes from @brianraymor on similar models:

Not All RFCs are Standards
Choosing between Informational and Experimental Status

An “Informational” specification is published for the general information of the Internet community, and does not represent an Internet community consensus or recommendation. The Informational designation is intended to provide for the timely publication of a very broad range of responsible informational documents from many sources, subject only to editorial considerations and to verification that there has been adequate coordination with the standards process (see section 4.2.3).

Specifications that have been prepared outside of the Internet community and are not incorporated into the Internet Standards Process by any of the provisions of section 10 may be published as Informational RFCs, with the permission of the owner and the concurrence of the RFC Editor.

Python Informational PEP(s)
An Informational PEP describes a Python design issue, or provides general guidelines or information to the Python community, but does not propose a new feature. Informational PEPs do not necessarily represent a Python community consensus or recommendation, so users and implementers are free to ignore Informational PEPs or follow their advice

[tburdett]

I like the idea of informational RFCs, I had some review comments about our current work practices that informational RFCs would help resolve. So +1 from me!

[brianraymor]

Notes from PM F2F (9/25/18):

There was consensus to add this type to the RFC Process - but it will not block approval for RFC v0. @brianraymor to collaborate with @tburdett and @briandoconnor on a proposal.

[brianraymor]

The first potential Informational RFC is Adding DCP support for image-based transcriptomics which validates the need for this type of RFC.