-
Notifications
You must be signed in to change notification settings - Fork 89
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
RFC 249: Rewrite the V2 Experiments RFC to have a more working-backwards tone #377
Conversation
03d9294
to
bb25608
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Much better than the previous RFC.
I don't have any deep questions here but a few things worth cleaning up before merging.
Co-authored-by: Niranjan Jayakar <[email protected]>
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Please also see
#377 (comment) and #377 (comment)
Otherwise LGTM.
I suggest keeping this RFC around for a couple of more days to see if others have anything to say.
I believe this is the correct thing to do if our choices have changed during implementation of the original RFC. OTOH, if these changes are part of a new project, then a new RFC is better. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks great. Some minor comments, but no major disagreements from me.
Pull request has been modified.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
👍
While working on the release of the CDK v2 Experimental Modules, I found myself looking for a place to document and discuss some of the customer-facing decisions being made (e.g., package naming, versioning, Changelog organization). Unfortunately, the current state of RFC 249 does not lend itself well to this format (IMO); the RFC as-is is more implementation-focused and more heavily leans towards the why of many of the decisions. While absolutely useful context, it doesn't read as much as a working-backwards document as I'd like.
My mental model to solve this was to copy (and save!) this really useful decision-making document, and replace the main RFC body with a series of working-backwards artifacts that (hopefully?) capture the customer experience of working with the alpha/unstable modules.
We don't usually go back and update old RFCs, so I recognize maybe this isn't the correct approach. I am very open to feedback on whether (a) this is useful; and (b) this is the best way to go about documenting these decisions.
Apologies for the ugly diff. I'd recommend opening up the rendered version of the new RFC to review, rather than viewing the diff directly.
[Rendered Version]
By submitting this pull request, I confirm that my contribution is made under
the terms of the Apache-2.0 license