Open brianraymor opened 5 years ago
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!
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.
The first potential Informational RFC is Adding DCP support for image-based transcriptomics which validates the need for this type of RFC.
Raised by @briandoconnor in his review of the RFC process. See the discussion.
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