You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The current proposal process for non spec changes is fairly lightweight for the proposer: there is a text box labeled "Proposal Details".
This has led to quite a large number of proposals, at the time of filing: 743 open proposals marked incoming, with a total of 636 filed this year so far, averaging 1.89 per day.
A recurring pattern in proposals is that they lack the detail: they'll often just vaguely describe a desired change. This results in some repetitive back and forth as we try to narrow it down to a specific api change that can be evaluated, and surface the motivations for the proposal.
I propose a 3 field proposal form that covers the majority of proposals we see:
Proposal summary: in words, describe the proposal.
Motivation:
Describe why the change should be made
If this is already possible in a third party library, why it should be in the standard library
If this has previously been proposed and declined, what significant new information justified revisiting the decision.
Include references to external specs, code searches for frequent patterns, etc.
Change details:
For API changes, the desired new api in godoc format, including comments.
For behavioural changes, the updated godoc describing the new behaviour.
cc @golang/proposal-review
The text was updated successfully, but these errors were encountered:
Proposal Details
The current proposal process for non spec changes is fairly lightweight for the proposer: there is a text box labeled "Proposal Details".
This has led to quite a large number of proposals, at the time of filing: 743 open proposals marked incoming, with a total of 636 filed this year so far, averaging 1.89 per day.
A recurring pattern in proposals is that they lack the detail: they'll often just vaguely describe a desired change. This results in some repetitive back and forth as we try to narrow it down to a specific api change that can be evaluated, and surface the motivations for the proposal.
I propose a 3 field proposal form that covers the majority of proposals we see:
cc @golang/proposal-review
The text was updated successfully, but these errors were encountered: