Re: Getting sign-off from horizontal groups

On Jun 21, 2019, at 1:18 PM, David Singer <singer@apple.com> wrote:
> 
> I previously raised the idea of traffic-light signals from x-func (and maybe other) groups that could signal to the team and AC the status of specs that are asking for approval to progress.
> 
> I realized the other day that this is quite easily done.
> 
> Create a fake interest-group, which only has invited members. Call it the horiz-review-IG. Ask each horizontal review group (accessibility, i18n, privacy, security, TAG, ’team’..) to nominate a voter in the horiz-review-IG group.
> 
> The groups gets a WBS poll on specs looking for advancement.
> 
> “Name of your x-functional group, that you are filing on behalf of:
> 
> Do you:
> green) see no reason to stop this this specification being advanced as-is?
> yellow) think that this specification has considerations that should be carefully weighed by the AC and Director before approving advancement (details below)?
> red) think that this specification should not be advanced, and be returned to the WG for further work (details below)?”
> 
> Then we, as a community, would be able to see what traffic-light and comments were received in summary (and that we’re often missing a security review, ahem).
> 
> I think this would elevate the PING comments and feelings quite substantially.
> 
> What do you think?

I’m encouraged by the idea, and it seems like one of the steps towards more thorough horizontal reviews.

This particular design (and what Jason describes) sounds to me a little like the IETF’s process where Area Directors in the IESG can approve or DISCUSS a spec — hold its publication until some issues are further discussed and addressed. That’s not always used “horizontally” but it can be, in the case of Security ADs for example. But it does require a lot of investment of time from people to conduct those reviews and to work through those discussions promptly. In general, I think we need to invest more in increasing our bandwidth for conducting reviews and resolving issues as we do in getting more Process attention to highlight or gate on those reviews.

Another new step for us would be determining which issues should be blocking of advancement. For the most part, we’ve tried to raise issues with working groups, discuss them and try to help find resolutions, but mostly not make group determinations about the severity of issues or what mitigations are satisfactory or not. We might need to put some work into deciding which issues are “yellow lights" and which are “red lights" and how PING as a group will make those determinations. I think that’s a good thing to do in general — I would like us to have a more solidified privacy model of the Web so that we can more definitively say which things are consistent or inconsistent with it — but just noting that it wouldn’t be an obvious determination, especially for the group as a whole rather than any individual who raises an issue.

> The proposal that Pete references below and that I’ve discussed with David and some others is that at the top of a W3C document that has gotten horizontal review, it would be good for each horizontal review team to give a red/yellow/green light like:
> 
> i8n - Approves/Approves with issues/Disapproves with issues/Disapproves/Not yet reviewed
> AX - Approves/Approves with issues/Disapproves with issues/Disapproves/Not yet reviewed
> PING - Approves/Approves with issues/Disapproves with issues/Disapproves/Not yet reviewed
> Security - Approves/Approves with issues/Disapproves with issues/Disapproves/Not yet reviewed
> Architecture - Approves/Approves with issues/Disapproves with issues/Disapproves/Not yet reviewed
> 
> Where “issues" are links to the relevant open issues in Github.
> 
> Having such information at the top of the document would help clarify:
> - The status of horizontal reviews;
> - The outcomes fo horizontal reviews both to the AC and to the wider public; and
> - The necessity of horizontal reviews and their outcomes to authors.
> 
> And, I think such a public indicia would help discourage horizontal review issues from not being taken seriously.

I think prominent categorization of open issues could help a lot, and right away! Just having consistent tagging of issues and making those issues appear at the top of a document both makes horizontal review issues important, but also makes it easy for anyone reading a spec (either for review or implementation) to find out what serious open questions are present. And it would also be necessary for PING as a group to make any efficient determinations of what issues are open and how serious/blocking they are.

To Pete’s point about conducting reviews earlier and all along, I think the model of tracking GitHub issues works for raising items earlier in the process and then it also facilitates the later review, which becomes putting together the existing issue list and statuses, along with a final readthrough to catch anything missed earlier.

Looking forward to talking more tomorrow,
Cheers,
Nick