Re: [Rfced-future] WGLC Review of the draft

[Peter Saint-Andre <[e-mail]>]

On 1/3/22 5:19 PM, Eric Rescorla wrote:
> Hi folks,
> 
> I have reviewed this document and feel that it is generally
> in good shape. I have made a small editorial PR
> (https://github.com/intarchboard/program-rfced-future/pull/148 
> <https://github.com/intarchboard/program-rfced-future/pull/148>)
> and filed four issues. As I know some people don't like using
> Github, I recap them here.
> 
> 
> Issue 144: The current text seems to say that we would need
> WG consensus for any other mode of operation than a mailing
> list, including a meeting. I understand that people want
> to require consensus to use Github and I'm not trying
> to change that, but do we really need to require consensus
> to have a meeting?
> https://github.com/intarchboard/program-rfced-future/issues/144 
> <https://github.com/intarchboard/program-rfced-future/issues/144>

I tend to think not.

> Issue 145: I had understood that we believed that the only
> two valid reasons for a CONCERN were:
> 
>     * The proposal represents a serious problem for one or more of the
>        individual streams.
> 
>     * The RSAB member believes that the proposal would cause serious
>        harm to the overall Series, including harm to the long-term
>        health and viability of the Series.
> 
> I see that to this we have added
> 
>     *  Comments received during a community call for comment need to be
>        addressed, as described under Section 3.2.3.
> 
> Two points:
> 
> (1) I don't actually see clear text that the list isn't exhaustive
> If we agree it is, we should say so.
> 
> (2) Assuming we agree it's exhaustive, then the comments reason
> allows non-conforming reasons to be used as the basis of
> a CONCERN by just saying that a community member made them.

Heh, I had not seen that backdoor.

One way to look at it is that the community call for comment could 
surface issues that meet the first two criteria, and if so it's the 
responsibility of the RSAB to bring those back to the review process by 
raising CONCERN positions. This way, arbitrary community concerns that 
don't meet the first two criteria can't get special consideration.

> My proposal would be to state that it's exhaustive and to require
> the comments to either be about one of the two reasons or that
> the comment hasn't been responded to, but not that the response
> wasn't to the satisfaction of the RSAB.
> https://github.com/intarchboard/program-rfced-future/issues/145 
> <https://github.com/intarchboard/program-rfced-future/issues/145>
> 
> 
> Issue 146: The current text describes the following core RPC
> responsibilities:
> 
>     The core responsibility of the RPC is continuous improvement
>     regarding the implementation of RFC policies (including the
>     dimensions of document quality, timeliness of production, and
>     accessibility of results), while taking into account issues raised
>     by the community through the RSWG and by the stream approving
>     bodies.
> 
> I agree continuous improvement is good, but I tend to think the
> core responsibility is just to publish the documents at all.
> https://github.com/intarchboard/program-rfced-future/issues/146 
> <https://github.com/intarchboard/program-rfced-future/issues/146>

That's sensible.

> Issue 147: This requires the RPC to keep certain records,
> e.g., of dialogue with document authors. Does that formally
> happen now, or is it just in people's e-mail folders?
> Do these records need to be public?
> https://github.com/intarchboard/program-rfced-future/issues/147 
> <https://github.com/intarchboard/program-rfced-future/issues/147>

It's not clear to me whether all record-keeping needs to be public. It 
might be acceptable that records are kept and available on request if 
needed (e.g., in case of an appeal).

Thanks for the review.

Peter