Re: PING Process

Thanks Nick!

FWIW, as discussed on the last PING call, I’ve created a repo for tracking issues here: https://github.com/w3cping/tracking-issues/issues

If there are issues others have opened, please kindly add them using the pattern I’ve used above (linking to the issue, tagging the issue with labels describing the relevant standard, etc).  I’ve added all the issues I’m aware of that have been opened in the last ~9 months or so.

Pete Snyder
{pes,psnyder}@brave.com
Brave Software
Privacy Researcher

> On Aug 15, 2019, at 8:29 PM, Nick Doty <npdoty@ischool.berkeley.edu> wrote:
> 
> Just to follow up, I really appreciated Sam giving us an updated tour of the i18n group’s tools and process for their reviews on the teleconference today. I thought these two explainer documents were especially valuable, and I think it would be great if this document became similar: this is how you get your spec privacy reviewed, and this is how we’re going to track and resolve issues that are raised.
> 
> https://www.w3.org/International/review-request
> https://www.w3.org/International/reviews/projReview.html
> 
> (Actually, my only open question for them would be why there are two such documents.)
> 
> We might not immediately get to the level of detail that i18n wg has with its github issues and project tracking in this document, but we can add those details as we try it out and see what works for us. I also suspect that we don’t have meetings or bandwidth frequently enough that we would get PING review/approval of every privacy issue that a reviewer opens on another specification.
> 
> Cheers,
> Nick
> 
>> On Aug 1, 2019, at 11:15 AM, Nick Doty <npdoty@ischool.berkeley.edu> wrote:
>> 
>> Re: 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 
>> 
>> 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.
>

Received on Thursday, 22 August 2019 10:08:35 UTC