Import pre-RFC-process-dated DCP Media Types #113
Conversation
|
Given that this document pre-dates the formal DCP RFC process and is de facto approved and implemented, I plan to bypass the usual process and merge it in after letting it sit for a week. If you have objections or minor edits to propose, please let us know by the end of this week. Barring objections, I'll merge the doc in on Monday, September 23. |
|
@kislyuk @diekhans please go through the standard RFC process for this. Not doing so sets a precedent that may lead to unexpected outcomes later: people might be lead to believe that they can bypass the process if they implement something first and then publish the RFC. If the RFC process is too slow, consider adding input to RFC: Proposing changes/updates to the RFC process. |
|
Matt,
Did you understand the scenario here?
This is not about code that was written before there RFC process.
This is an RFC that was written before the current RFC process.
Are you suggesting that every time we tweak the RFC process, we need to re-review all RFCs?
…-Sam.
On Sep 17, 2019, at 4:18 PM, Matt Weiden ***@***.***> wrote:
@kislyuk <https://github.com/kislyuk> @diekhans <https://github.com/diekhans> please go through the standard RFC process for this. Not doing so sets a precedent that may lead to unexpected outcomes later: people might be lead to believe that they can bypass the process if they implement something first and then publish the RFC.
If the RFC process is too slow, consider helping build solutions to the problem in RFC: Proposing changes/updates to the RFC process <#109>.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub <#113?email_source=notifications&email_token=AADLV2UGY2MW6SOVDJDLWKTQKE3SZA5CNFSM4IXEMAZ2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD65YZKA#issuecomment-532384936>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AADLV2WZVCLR4ZVLA4CITNDQKE3SZANCNFSM4IXEMAZQ>.
|
|
Ping @mweiden |
|
Discussed during the 2019-10-11 Arch meeting. We reached consensus on importing all old RFCs from google drive and labeling them "Imported." |
|
I believe it is important to put all labels at the start of the document as well as github labels so it is easy to see when reading. |
maniarathi
force-pushed
the
akislyuk-rfc-dcp-media-types
branch
from
b193e12 to
4c640ea
Compare
maniarathi
changed the title
There was a problem hiding this comment.
If we are going to import these into the current process, lets really import them by converting to markdown and committing. This way they can be used and maintained as with all other RFCs.
It doesn't really need to follow the template exactly, just be under source control and follow the naming convention.
This can be semi-automated by saving the page as HTML and doing
pandoc DCPMediaTypes.html -t markdown_github > DCPMediaTypes.md
Although the markdown is a bit ugly and needs some editing. Probably other tools too.
maniarathi
changed the title
|
Updated to import DCP Media Types again. |
|
|
||
| # DCP Media Types | ||
|
|
||
| DISCLAIMER: Please note that this RFC has been imported its original Google Doc and went through a design review process prior to the implementation of the current [RFC Process](https://github.com/HumanCellAtlas/dcp-community/blob/master/rfcs/text/0001-rfc-process.md). The original document is [here](https://docs.google.com/document/d/1TqihrgXjct9aDmTJO52_gE2WlpFysB1OkG9C8exmWTw/edit#heading=h.87ix45a71erf). Please be aware that the contents below may potentially be out-of-date as the last-modified date of the original Google Document is October 20th, 2017. |
There was a problem hiding this comment.
Your "out of date" comment seems unnecessary. They same could be said of all RFCs the day after they are written.
And AFAICT this information is all still current at this time.
There was a problem hiding this comment.
Agreed; we should be checking for accuracy on import. I think the important thing to note is not that is was in google docs, but it was approved by an older process.
It would be good to update the google doc to point to the RFC.
There was a problem hiding this comment.
@sampierson Deleted the last sentence. Thanks.
@diekhans I have an earlier sentence in that paragraph "and was approved by a design review process prior to the implementation of the current RFC Process."
@diekhans @sampierson I will let the original author decide whether to point the Google Doc to the RFC :)
|
|
||
| ## Motivation | ||
|
|
||
| The DCP should not invent new media types; we should append `dcp-type=metadata` or `dcp-type=data` to our Content-Types using the media type "parameter" syntax, e.g. `Content-Type: application/json; dcp-type=”metadata/sample”`. Instead the DCP should strive to use "in-band" media type communication mechanisms where possible. |
There was a problem hiding this comment.
This paragraph seems a little mangled. I think what you are trying to say is "The DCP should not xxx . Instead it should do yyy". Right now the Instead clause come after the "should do" clause.
|
note: I will be importing the domain RFC ~ Nov 13th |
|
I don't see the value in putting these into a special directory "imported". This just creates a special case because of being reviewed with a different process. I think the idea is for these to be first-class RFCs just like all the others. We don't really want to have a new directory every time we change the RFC process. |
This RFC imports the DCP Media Types design document (https://docs.google.com/document/d/1TqihrgXjct9aDmTJO52_gE2WlpFysB1OkG9C8exmWTw/edit#) that was decided upon prior to the RFC process.
November 19th: Last call for community review