Process proposal #20
Process proposal #20
Conversation
This change adds a process proposal as discussed on several PING calls.
Thanks to @snyderp's suggestion, this change expands the opening paragraps to make clear that though this document is mostly about the process of privacy reviews, that's only the most-visible tip of the iceberg when it comes to our overall work.
|
|
||
| PING's goal is to ensure that the specifications recommended by the W3C respect the privacy of people who use the web platform, and ensure that the web platform is an environment which allows people to browse the web privately. | ||
|
|
||
| PING's core administrative mechanism for achieving this is _horizontal review_: members of PING review specifications and provide recommendations to the authors about how to ensure that their specifications support a web platform which respects privacy. This formal review process is the most visible part of a larger iceberg of activities aimed at helping specification authors write with privacy in mind. The best place to make privacy-related improvements to specifications is substantially in advance of horizontal review points. PING welcomes conversations with authors at all phases of specification development. Ideally, PING would be thoroughly familiar with specifications, their potential privacy impacts, and the measures takes to mitigate those impacts well before the time horizontal review points are reached, and those privacy reviews would consist mostly of codifying & recording conversations which have already happened, rather than pointing new things out to authors. |
There was a problem hiding this comment.
PING has a privacy questionnaire at https://w3c.github.io/ping/privacy-questions.html. Is that expected to flag enough issues that specification authors can reliably write with privacy in mind, or do you expect every specification to need a conversation with PING members during the early design phase in order to be generally on the right track?
|
|
||
| **Serious Concerns** are fundamental problems with the approach or goals of the specification. These are unlikely to have straightforward technical remediations. They require fundamentally re-thinking or re-architecting the specification. This should be rare. | ||
|
|
||
| When there are serious concerns with a specification, PING will outline them in a response to the privacy review request. Specification authors should work with PING to understand these concerns and re-architect the specification, which may require re-chartering. When the specification has been re-thought in this way, specification authors should open a new privacy review request for the new specification |
There was a problem hiding this comment.
When PING notices "Serious Concerns" with a specification that weren't flagged by answers to the PING Privacy Questions, should the process suggest updating the Privacy Questions so future authors have a better chance of avoiding the concerns in the future?
|
|
||
| This status should be indicated at the top of all specification documents, alongside the similar status from other horizontal review groups. | ||
|
|
||
| Specifications which are not in state #1 are not eligible to proceed to recommendation status. |
There was a problem hiding this comment.
All for more and more thorough horizontal reviews, but I don't believe this statement is true.
If there are disagreements between groups, it's an input and a data point for the process but not a "not eligible" blocker. Case in point, webperf WG may express concerns about potential performance implications of the feature, but that does not mean that it makes in not eligible to proceed to recommendation status.
|
|
||
| ## Privacy Review | ||
|
|
||
| Every specification seeking recommendation status must be reviewed by PING. Specification authors request review by opening an issue in the [`w3cping/privacy-reviews`](https://github.com/w3cping) GitHub repository, using the supplied privacy review issue template. This issue should include as much context as possible so that PING can understand the aims and working environment of the specification. |
There was a problem hiding this comment.
Every specification seeking recommendation status must be reviewed by PING.
This sounds like something that needs be part of the W3C's process document in order to have any effect
There was a problem hiding this comment.
Absolutely. A PING-published doc is the wrong place for this, except as it reflects changes otherwise made in the process. Thanks for calling it out.
|
|
||
| **A review will either result in PING raising issues, raising serious concerns, or raising neither.** | ||
|
|
||
| Review is not a sign-off or authorization step — it involves substantial engagement with the design and implementation of the specification as well as its goals and likely impact on the web platform. PING recommends that specification authors ask PING to start a review as soon as they have the broad outline of a specification, and no less than once every six months during a specification's lifespan. Many privacy issues can be anticipated at this early stage. Learning about these potential issues allows working groups and specification authors to implement solutions smoothly and thoughtfully. This should lead to fewer issues raised during review. |
There was a problem hiding this comment.
no less than once every six months during a specification's lifespan
That seems prohibitively expensive and unnecessary (e.g. if the specification has not changed since the last review)
|
|
||
| ### Raising Issues | ||
|
|
||
| **Issues** are specific privacy drawbacks with the specification which must be addressed before the specification becomes a recommendation. When raising issues, PING will endeavor to articulate posssible technical approaches which mitigate those issues. |
There was a problem hiding this comment.
It might be better for PING to stick to articulating the problems, rather than trying to force specific mitigations
There was a problem hiding this comment.
While I don't want to see PING obligated to fix others' problems, it seems to me that suggesting fixes would be helpful to groups that struggle to see fixes on their own. There's a difference between "articulate possible" (as Tom writes) and "force" (as your comment says).
|
|
||
| This status should be indicated at the top of all specification documents, alongside the similar status from other horizontal review groups. | ||
|
|
||
| Specifications which are not in state #1 are not eligible to proceed to recommendation status. |
There was a problem hiding this comment.
Again, something that needs to part of the W3C process document
Thanks for everyone's patience as I wrote this up. I'm leaving this PR in draft form so that I can integrate feedback without before eventually merging.