RFC Proposal Path #462
Conversation
Codecov Report
@@ Coverage Diff @@
## main #462 +/- ##
==========================================
+ Coverage 59.61% 61.15% +1.53%
==========================================
Files 26 31 +5
Lines 1768 1964 +196
==========================================
+ Hits 1054 1201 +147
- Misses 714 763 +49
Continue to review full report at Codecov.
|
|
What ticket does this address? |
This was an action item from the standup ❤️ |
|
I read through it, looks like a very good starting point. |
|
I think the RFC approach is good. I also believe, as is outlined in the process, that getting consensus on ideas is an important phase of proposal. Does it make sense to have a step before your RFC process steps that is a small white paper about the idea before it is committed to the RFC process? |
I tried to cover this in https://github.com/prince-chrismc/pyrsia-sandbox/tree/proposal-path/docs/rfc#before-creating-an-rfc
Perhaps is a little unclear or hidden? |
Looking it over, i felt it could be improved! https://github.com/prince-chrismc/pyrsia-sandbox/blob/proposal-path/docs/rfc/readme.md#summary Thanks for the input 👏 |
which is where this came from
|
I was reading through this and the references from RUST community. For our small team and purpose this is very detailed and has too many required sections. I would like this to be simplified as TL;DR And provide references in case we are making such a fundamental change that other sections may make sense and let the proposer choose to add sections. In general reduce the barrier for people to submit proposals, but give them a little bit of structure. |
There was a problem hiding this comment.
I was reading through this and the references from RUST community.
For our small team and purpose this is very detailed and has too many required sections.
I would like this to be simplified as
TL;DR
What is the Issue?
Solutions available
Proposed Solution
Comments
And provide references in case we are making such a fundamental change that other sections may make sense and let the proposer choose to add sections.
In general reduce the barrier for people to submit proposals, but give them a little bit of structure.
|
@betarelease it's unlear if you are referring to the template of the proposal workflow 😕 Which file (or both) so I take that feedback into account for? |
|
|
||
| # Future possibilities | ||
|
|
||
| Think about what the natural extension and evolution of your proposal would |
There was a problem hiding this comment.
This paragraph is too much to ask from a proposer.
There was a problem hiding this comment.
I made this sectional optional but I like the idea to leave space for anything extra the author might want to add
Is that a good middle ground?
Co-authored-by: Sudhindra Rao <41690+betarelease@users.noreply.github.com>
and less restrictive Co-authored-by: Sudhindra Rao <41690+betarelease@users.noreply.github.com>
Co-authored-by: Sudhindra Rao <41690+betarelease@users.noreply.github.com>
Co-authored-by: Sudhindra Rao <41690+betarelease@users.noreply.github.com>
Co-authored-by: Sudhindra Rao <41690+betarelease@users.noreply.github.com>
As discussed in our retro, we need to formally have a processes
We'll need to prioritize writing the proposals that we made verbally.
My goal is to fold this into the new website's documentation under the "Developer Hub".
I might tweak the header of the template to render better on the website.