Re: PING Process

Re: https://github.com/w3cping/administrivia/blob/process-changes-2019q3/README.md <https://github.com/w3cping/administrivia/blob/process-changes-2019q3/README.md>
 as pointed to by Christine https://www.w3.org/mid/3D2DBB1E-32D9-4839-84C6-9D0B0A8A15C5@isoc.org <https://www.w3.org/mid/3D2DBB1E-32D9-4839-84C6-9D0B0A8A15C5@isoc.org>

Thanks Tom for getting this text drafted, based on previous discussions on PING calls. I think it’s brief and easy to read, which is important for others who will want to read this quickly and get to the substantive matters at hand. I had a few comments based on reading over it this morning, included below.

Cheers,
Nick

How about “Architectural Concerns” rather than “Serious Concerns”? It seems like some Issues (which are a separate category) can also be serious, and then we don’t have to debate how serious/important an issue is, just whether it’s a fundamental question, or an issue where we have a recommended fix. And noting it as an architectural concern also seems like a time that we might try to loop in the TAG in particular to provide advice.

I think we could also be a little more descriptive about what an Issue is, rather than just indicating it as blocking. It seems like it’s a comment, open question or concern about how implementations of the specification would create privacy risks for users of the Web.

I would suggest we not make claims in our documentation about what is or isn’t allowed to progress along the Recommendation track. That’s a topic for other documents (like the W3C Process doc, which gets a lot of input and I think the AB manages it). This document can explain what it takes to get PING review and satisfy our process, not what the effects of those outputs are on other people or groups.

Incidentally, I do agree that privacy issues should be resolved before a spec progresses, and I hope that the Director/AB/AC or whoever will naturally come to that conclusion, and that it’ll be especially easy for them to do so the more we show that we have an effective review process. And Formal Objections in some cases might be ways for us to do that in the existing Process, although even in that case, our Objection might be overruled during some evaluation process, and I think that’s reasonable.

Related, the doc currently uses “must” and “should” quite a bit, and I’m not sure if we intend that in an RFC 2119 sense or not. I think most of the time we just mean: this is an effective way to work with our group. I don’t think we need to make recommendations to implementers in this document, although noting for spec authors that some implementers may not start development of features until this review is complete (and getting some UAs or others to back that up) would be a really significant encouragement.