-
Notifications
You must be signed in to change notification settings - Fork 251
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
Design document for Alloy proposal process (#908) #909
Conversation
94aee15
to
4d00ba1
Compare
Make it clearer that the background is for the "why" a proposal is necessary and what problems are being solved.
Include why the following are necessary: * A formalized process for proposal review and proposal creation * A single source of truth for discussions
Original discussion can be found at #908. |
@erikbaranowski @tpaschalis @mattdurham Does the current state of the design document address all of your concerns? @wildum ping on the current state just to make sure you're still comfortable with everything here. @thampiotr I know you had some concerns with the proposed process. Is the current state better? What changes would you like to see? |
@ptodev Checking in, what's your current feeling on this proposal? |
* Discussion on issues should be done conversationally rather than responding | ||
to individual lines of text. This can help reduce the total number of | ||
comments and make a conversation more digestible. |
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.
As mentioned before, I find long-form essays by far less digestible than comments on individual lines of text, where all the context is available. I feel the argument in your doc is up for the debate and could actually have quite the opposite effect. A lot (if not all) modern communication tools for large groups of people support threads, so my view on this topic is also likely to be quite common.
Having said that, I'm happy that PR with design doc can become the source of truth for a more involved discussion. In fact, I would consider a policy where anything more than two threads or two rounds of technical comments should usually be migrated to a design doc PR. Worst case it'd be a short design doc.
It sounds like we're at a rough consensus with the current state of this proposal, so I'll move this to Likely Accept. This marks the start of the final comment period for consensus to be changed. If consensus hasn't changed by Friday, June 14, this proposal will become Accepted. cc @erikbaranowski @tpaschalis @mattdurham @wildum @thampiotr @ptodev |
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.
Happy to trial this. I'd like to be careful not to generate too much work for the proposers and maintainers with this. I'm sure we can adjust in the future if this becomes the case.
No change in consensus, so this proposal is now Accepted. I will merge this and follow up on the next steps to roll this process out to other proposals. |
This PR creates a design document for #908.
To demonstrate the proposed process, the design document follows the procedures laid out in the proposal itself.