Proposes changes to wide/horizontal review #401
There are no files selected for viewing
| Original file line number | Diff line number | Diff line change |
|---|---|---|
|
|
@@ -2365,49 +2365,99 @@ Reviews and Review Responsibilities</h4> | |
| <h5 id="wide-review"> | ||
| Wide Review</h5> | ||
|
|
||
| The objective of <dfn id=dfn-wide-review export>wide review</dfn> is to seek | ||
| feedback on a specification from the entire web community, including the general | ||
| public. The goal is the early identification and resolution of issues in order to make the specification as robust as possible before it becomes a [=W3C Recommendation=]. | ||
|
|
||
| Wide review <em class="rfc2119">should</em> be sought continuously as a | ||
| specification matures, to allow different parts of the web community to iterate | ||
| on requirements, problems, and solutions. | ||
|
Contributor
There was a problem hiding this comment. It would be helpful to add here some words to the effect that WR comments received on a spec that is in CR or later should be noted and resolved where possible but that it could be reasonable for WGs to defer those to a future iteration of the specification itself. I say this because looking at the delta relative to the previous text here, there was a strong sense that WR feedback before CR is somehow weightier than WR feedback during CR or PR, or even Rec. This sense was borne out of the fact that WR must be demonstrated in order to transition to CR but further WR need not be solicited after CR. My concern here is that WGs should be allowed to make good progress through the maturity levels without being pushed into some kind of circular pattern whenever any comment is received on a spec, especially one that has already made it to CR.
Contributor
Author
There was a problem hiding this comment. I agree we do not want specs being held up. Equally I'm not sure how to put something as nuanced as you suggest into the Process in a way that is useful - sometimes there will be things caught at CR that are a showstopper. Based on suggestions elsewhere in this thread, the following was updated to include the "heads up" note:
Does that help with your concern? If not could you suggest some succinct words/placement that would? |
||
|
|
||
| When the [=First Public Working Draft=] of a specification has been published, the Team <em class="rfc2119">must</em> ensure that a notification is sent to <a href="https://lists.w3.org/Archives/Public/public-review-announce/">[email protected]</a>. | ||
|
|
||
| As a specification progresses along the Recommendation Track, Working Groups | ||
|
Contributor
There was a problem hiding this comment. I'd like this to say that the review should be solicited from FPWD at the latest. This wording suggests that it's okay to solicit review in a piecemeal fashion giving different stakeholders longer or shorter review periods. That might be okay but I think the SHOULD ought to prompt WGs to solicit feedback sooner rather than later, and to treat all stakeholders similarly while giving the freedom to make local exceptions if that is appropriate. Should we allow consideration of WR sought on pre-FPWD drafts to count? Since HR is part of WR and the requirements in this proposal include stating that HR needs to begin before entering Rec Track I think the implication is probably yes, in which case we should say that explicitly.
Contributor
Author
There was a problem hiding this comment. Is there a reason you worry that groups could be offered different turnaround times at this particular point, as opposed to any other? I'm hesitant to say much about wat happens before FPWD because more often than not these days that happens in a CG and outside of the Process' remit. It's tricky though.
Contributor
There was a problem hiding this comment. I do know that several HR groups have expressed a desire to participate in reviews in those early stages, though - e.g. the Privacy Interest Group wants to (and does) review WICG incubations.
Contributor
There was a problem hiding this comment. "As a specification is being prepared for, and then moved along, the Recommendation track…" ?
Contributor
There was a problem hiding this comment.
I think if it looks like W3C is treating different groups differently without some good reason then it would reflect badly on W3C. I'm only picking it up here because this is the change being proposed. I suppose I could try to review the whole Process for it and open a separate issue, but I wasn't particularly aware of it as a problem elsewhere before.
Contributor
Author
There was a problem hiding this comment. I've updated the text to use @dwsinger's suggestion:
Contributor
There was a problem hiding this comment. This new wording works for me. |
||
| <em class="rfc2119">should</em> solicit review from some or all of the following | ||
| stakeholders: | ||
|
|
||
| <ul> | ||
| <li>The Working Group responsible for the specification</li> | ||
| <li>The horizontal review groups (see 6.2.3.2)</li> | ||
| <li>The Groups and external organisations documented in the Working Group's charter or with which the Working Group has relevant liaisons</li> | ||
| <li>The general public</li> | ||
| <li>Other relevant standards organizations</li> | ||
|
Contributor
There was a problem hiding this comment. propose to add
Collaborator
There was a problem hiding this comment. I agree in principle, but isn't that redundant with "external organisations documented in the Working Group" as you suggested in an earlier point? Or do we have liaisons that aren't listed in the charter?
Contributor
There was a problem hiding this comment. Indeed, there is nothing to tie the listed liaisons to the groups listed in the Charter for a WG. It is possible for liaisons to be established with a WG mid-Charter-period, for example.
Contributor
There was a problem hiding this comment. I would mark this as resolved but I do not seem to have the rights to do that on this pull request. |
||
| </ul> | ||
|
|
||
| The Director <em class="rfc2119">must</em> consider evidence of wide review before | ||
| approving transitions. Appropriate evidence <em class="rfc2119">should</em> include: | ||
|
|
||
| <ul> | ||
| <li>Documented requests for wide review</li> | ||
| <li>Documented discussion and resolution of issues raised during wide review</li> | ||
| </ul> | ||
|
|
||
| <h5 id="horizontal-review"> | ||
| Horizontal Review</h5> | ||
|
|
||
| The objective of <dfn id=dfn-horizontal-review export>horizontal review</dfn> is the early identification and resolution of issues in order to make sure specifications are robust in terms of accessibility, internationalisation, | ||
| privacy, security, and technical architecture by the time they become a [=W3C Recommendation=]. | ||
|
Collaborator
There was a problem hiding this comment.
How about
Contributor
Author
There was a problem hiding this comment. I'm hesitant to bring compatibility with existing deployments into it, but I like the idea I think you're aiming at, so I've updated both the wide and horizontal review intro paragraphs to include:
And:
|
||
|
|
||
| Horizontal review <em class="rfc2119">should</em> be sought continuously as a | ||
| specification matures, so that accessibility, internationalisation, privacy, | ||
| security, and technical architecture are considered throughout. | ||
|
|
||
| As a specification is being prepared for, and moved along, the Recommendation Track, the | ||
| group responsible for the specification <em class="rfc2119">must</em> solicit a | ||
| horizontal review from each of the horizontal review groups (in many cases, | ||
| submitting a self-review to the reviewing group will satisfy this requirement). | ||
|
|
||
|
Contributor
There was a problem hiding this comment. I think this needs to be re-phrased so as not to imply that solicitation of review can be done once, but that the HR groups have adequate notice and opportunity to review.
Contributor
There was a problem hiding this comment. The topic of soliciting review seems important to me. As a WG Chair, given that the HR requirement is fixed and known, I want the admin task of requesting review to be minimal. It needs to happen automatically at defined stages, and manually when the WG makes a significant change that would warrant a re-review. The automatic request should be as lightweight as possible. I certainly don't want to be engaging in multiple 1-1 conversations with HR group Chairs/leads to agree timescales for specific reviews, if it can be avoided. I suspect that if that seems like it would be onerous to me for one WG, it would be an order of magnitude worse for the HR groups! I know @plehegar is presenting something about this at the upcoming AC, but I'm not sure how far it will go and how much it should be written into the Process.
Contributor
Author
There was a problem hiding this comment. I think the sentiment @dwsinger is aiming for is expressed in this sentence:
But the remainder of the text is more explicit about the minimum that needs to be done, which I think is where @nigemlmegitt isaiming. |
||
| The <dfn id=dfn-horizontal-review-groups export>Horizontal Review Groups</dfn> are: | ||
|
|
||
| <ul> | ||
| <li><a href="https://www.w3.org/WAI/APA/">Accessible Platform Architectures Working Group</a></li> | ||
| <li><a href="https://www.w3.org/International/core/Overview">Internationalisation Working Group</a></li> | ||
| <li><a href="https://www.w3.org/Privacy/">Privacy Interest Group</a></li> | ||
| <li><a href="https://www.w3.org/2001/tag/">Technical Architecture Group</a></li> | ||
| </ul> | ||
|
Contributor
There was a problem hiding this comment. Isn't there a Security group too? I find this confusing since the TAG seems to require a security self-review too. But @plehegar has recently shared slides that do list Security explicitly. |
||
|
|
||
| When the [=First Public Working Draft=] of a specification has been published, the Team <em class="rfc2119">must</em> ensure that a notification is sent to | ||
| <a href="https://lists.w3.org/Archives/Public/horizontal-review-announce/">[email protected]</a>. | ||
|
|
||
| Transition to [=Candidate Recommendation=] <em class="rfc2119">must</em> not be requested unless either the Horizontal Review groups have been given at least 60 days notice to review the specification or the Horizontal Review Groups have completed their reviews. | ||
|
|
||
| Horizontal Review Groups <em class="rfc2119">should</em> be notified of all new and significantly revised sections of a specification that has already been reviewed. Note: failure to do so may result in the transition to [=Candidate Recommendation=] being delayed. | ||
|
|
||
| When a Working Group requests horizontal review: | ||
|
|
||
| <ul> | ||
| <li>The horizontal review group <em class="rfc2119">must</em> acknowledge | ||
| receipt of the request and indicate whether the review will be conducted</li> | ||
| <li>The horizontal review group <em class="rfc2119">should</em> review | ||
|
Contributor
There was a problem hiding this comment. We need to say somewhere that a well-formed HR review includes a timeframe for response, which should either be predefined or have been negotiated out-of-band by staff and/or Chairs. |
||
| the specification and raise relevant issues within the agreed timeframe</li> | ||
| <li>The requesting Working Group <em class="rfc2119">must</em> acknowledge | ||
| receipt of each issue, then give each issue due consideration before | ||
| providing an appropriate response</li> | ||
| <li>If the Working Group and the horizontal review group do not agree, | ||
| they <em class="rfc2119">should</em> make a determined effort to find | ||
| agreement</li> | ||
| <li>When the Working Group requests transition of a specification, evidence | ||
| of this process <em class="rfc2119">must</em> be provided and any issues | ||
| that remain unresolved <em class="rfc2119">must</em> be indicated</li> | ||
|
Comment on lines
+2436
to
+2444
Collaborator
There was a problem hiding this comment. While these last 3 bullets are true for issues raised during HR, they're not limited to HR, and are also true for issues raised by anybody at any time. If this needs to be clarified, it should be clarified in the "Advancement on the Recommendation Track" section. But redundant requirements with slightly different phrasing are not good, so I'd remove theses 3 bullet points from here.
Contributor
Author
There was a problem hiding this comment. Happy to remove them but I wasn't sure if you meant they should be moved to the general section, replace what's already in that section, or just be outright deleted? |
||
| </ul> | ||
|
|
||
| The Director <em class="rfc2119">must</em> consider evidence of horizontal | ||
| review before approving transitions. Appropriate evidence <em class="rfc2119">should</em> include: | ||
|
|
||
| <ul> | ||
| <li>Documentation that the Horizontal Review Group did not consider a review to be necessary; or</li> | ||
| <li>In the event that "no review" is cited, documentation that at least 60 days has elapsed since the review request was made to the Horizontal Review Group; or</li> | ||
| <li>Documentation that the Horizontal Review Group raised no issues; or</li> | ||
| <li>Documentation of both: | ||
| <ol> | ||
| <li>The list of issues raised by the Horizontal Review Group that were resolved</li> | ||
| <li>The list of issues raised by the Horizontal Review Group that remain unresolved, including evidence that a determined effort was made to find a resolution in each case</li> | ||
| </ol></li> | ||
| </ol> | ||
|
|
||
| <h4 id="correction-classes"> | ||
| Classes of Changes</h4> | ||
|
|
||
|
|
||
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Seems like losing the sense of this section is a shame; I thought this process text was very useful in framing how WGs think about their wide review. I wonder if, in the way that @frivoal suggested in https://github.com/w3c/w3process/pull/401/files#r426429326 this can be refactored somehow so that the definition of documentation for demonstrating due process has been applied to review comments can be moved to a place where it clearly applies both to all wide review comments including horizontal review comments.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Moving it makes sense. I'm just not sure of the mechanics of doing it in a way that does not get lost. if @frivoal can make it happen, since his Github fu is likely better than mine) that would e good.