Closed Kevsy closed 9 months ago
@Kevsy @jordonezlucena I have seen somewhere a discussion about this pull request, but can't find it anymore.
My understanding from it was that we don't need a new category of decision, but could formulate the "No Go" option in a way that it also allows to resubmit the proposal after the objections are addressed.
Who can take that? (the PR needs anyway to be rebased on the updated version).
BTW: I can't find the related issue for this PR either
Apologies - I had not raised an issue. Now done: #90
Here is an excerpt from the email discussion with @jordonezlucena
"Thanks for this PR. I totally support the intention of this PR, though am not sure whether this constitutes a separate decision outcome (and therefore deserves to be captured into a separate bullet) or if it can be included as part of the “No-Go!” decision. Let me elaborate below.
IMHO, this “return for changes” information would be included in the justifications that objecting companies shall provide when going for “No-Go!” decision. Lack of clarity, existing gaps, or simply clarifications are examples why a API proposal might be rejected after first submission. When notified with “No-Go!” decision, if the requests (for clarification/correction/changes) are included in the justification section, the authors can address them and proceed with the re-submission for next TSC meeting. With this approach, there’d be no need to have this “return for changes” as a separate bullet. "
I agree, and have updated the commit to include the additional text within 'No-Go!' rather than a separate decision.
@Kevsy the proposal looks good to me. I have resolved the merge conflict and replaced "Steering Committee" by "TSC"
I suppose we are good to go, will merge it.
Fixes #90