Enumerate the requirements for wide review

[nigelmegitt]

I've observed that there is confusion about what constitutes a good wide review. It would be helpful to clarify in the Process the minimal requirements for processing review feedback, for example to match the good practice that was embedded in the old disposition of comments tool, namely:

• Announce by public notification and external liaison that must include the relevant groups listed in the Charter:
  • the review period,
  • the scope of the review being requested, and
  • the process for providing review feedback.
• Agree a WG disposition for each comment
• Send the WG disposition to the commenter (can have a latest response deadline not sooner than 2 weeks later)
• Record the commenter's response if any within the deadline

This is minimal - obviously groups that enter into discussions with the commenter and can document a conversation in which the WG and the commenter arrive at a mutually acceptable conclusion would satisfy these requirements.

[LJWatson]

@astearns commented:

Should the 6.2.3.1 SHOULD list have a bullet point for ”Other standards organizations working in a relevant area”? The CSSWG will sometimes ask for input from Unicode Consortium or WHATWG members (for example), and @nigelmegitt mentions other orgs as well above>

Makes sense to me. I've added:

• Other relevant standards organizations.>

[nigelmegitt]

@LJWatson @astearns thank you for that. The Liaisons page defines the minimal set of other relevant standards organizations, I believe.

[pes10k]

It would be good to clarify the procedural role of horizontal reviews. The relevant parts of the document say MAY, so its not clear what the expected role of these reviews are

• If issues are raised during a review, does progressing a standard depend on addressing those issues?
• If so, who decides if those issues have been addressed? The group authorizing the standard? The horizontal review group? The Director, directly?
• Are horizontal reviews expected at any stage in WICG group activity, formally or informally?

[LJWatson]

@snyderp commented:

If issues are raised during a review, does progressing a standard depend on addressing those issues?>

I think the short answer is yes, where "addressed" means "responded to satisfactorily", "resolved", "determined to be invalid", or some other thing that indicates the issue was given due consideration.

If so, who decides if those issues have been addressed? The group authorizing the standard? The horizontal review group? The Director, directly?>

Initially the person/group that raised the issue, but ultimately the Director. When a transition is requested, the group owning the specification is expected to provide evidence of wide/horizontal review, and that should include evidence that issues have been addressed appropriately.

Is it worth amending the proposed text to be more explicit about both these points?

This is where @dwsinger's idea for the traffic light system would be helpful, at least for horizontal review. If the horizontal review group is satisfied that its issues have been addressed, they would (I suppose) give the specification a green-light. The Director would then have a reasonably simple way of determining satisfaction with the responses.

Are horizontal reviews expected at any stage in WICG group activity, formally or informally?>

It would certainly be a good idea if they did, but the Process doesn't extend to CG as far as I know. The closest we can, and have, come to it, is expecting that a specification must solicit horizontal review before requesting transition onto the Recommendation Track.

[pes10k]

Initially the person/group that raised the issue, but ultimately the Director. When a transition is requested, the group owning the specification is expected to provide evidence of wide/horizontal review, and that should include evidence that issues have been addressed appropriately.

Is it worth amending the proposed text to be more explicit about both these points?

Thanks @LJWatson! Yes, I think it'd be very useful to outline the process for when the horizontal review group and the proposing / authoring disagree about whether an issue has been addressed. I'd be very happy to help work through this, informed by experiences we've had on PING.

Re WICG

I agree with you. WICG now has built up a sig amount of functionality thats shipping in major implementations, and that currently proposed specs are relying on. Anything that could be done to have horizontal reviews earlier and more often for CGs would be terrific, both from the HR review side, and i expect from the authors side (since less likely to have to make changes in the final steps).

Again, I'd be happy to help draft text to work on policy here if it'd be helpful

[cwilso]

I’m a little swamped with other things this week, but I’m happy to dive in more here. It would be useful to understand what the expectations of HR groups would be for early-stage requests - aka, how do we keep from swamping their pipelines?

[pes10k]

@cwilso That'd be great. Whats a good forum for that conversation?

I appreciate the concern about not overwhelming HR groups. At this point though, finding out a way for HR to do their work in a way that has a higher impact, and reduces the (understandable) push back from authors (who don't want to re-do months or years of work bc of serious but late discovered issues) is, from my view, a top priority. If that results in HR groups being overwhelmed, that'd be a better problem to sort out than the present situation :)

[aphillips]

@cwilso Please: swamp my pipeline. No, really. I agree with @snyderp that this is preferable to the current situation (where my pipeline is swamped with emergency requested pending CR---I've droned on enough as it is about this).

It might be good to think about a self service mechanism so that the HR teams don't have to separately maintain the equivalent of I18N's review radar

[LJWatson]

@snyderp commented:

Yes, I think it'd be very useful to outline the process for when the horizontal review group and the proposing / authoring disagree about whether an issue has been addressed. I'd be very happy to help work through this, informed by experiences we've had on PING.>

Thanks. Help very much welcome!

I've tried to distill what I think we might need, into a set of simple statements. I've avoided formal Process language for now, because I'm not sure I've captured the gist well enough to try for that just yet.

• The review group needs to acknowledge the request and confirm they intend to respond;
• The review group needs to raise issues within the agreed timeframe (noting that the deadline may be the result of a negotiation with the requesting group);
• The requesting group needs to acknowledge each issue, give each issue due consideration, and respond appropriately to each issue (noting that the response could be a proposal, solution, invalid state, or other);
• If the review group and requesting group don't agree on the response, they need to make their best effort to find agreement;
• When requesting transition, the requesting group needs to include all of the above as evidence of proper review, and in particular needs to highlight any issues that remain under contention and/or that have not been resolved satisfactorily.

For wide review we might drop the first two bullet points, since there are not always defined "groups" on the receiving end of wide review requests. We'd also want to substitute "review group" for "reviewer" or something I think.

[pes10k]

@LJWatson thanks for this! I think this is a great jumping off point. A couple of suggestions though:

• It may be worth having HR groups, as a requirement of transitions, independently do a 👍 / 👎. Otherwise, there may be cases where standards authors (by intention or by accident) do not report issues where they disagree with the HR(s). Otherwise, it creates the unfortunate current situation where HRs need to not only do reviews, but review transition requests separately to make sure disagreements are documented.
• Is the expectation that the materials in step 5 are being presented directly to the Director? To the ACs? Other?
• Would this process also apply to under-development-WICG-standards (say, 6 month intervals, something like that), or is that a separate conversation ? :)

[chaals]

@snyderp wrote

Would this process also apply to under-development-WICG-standards (say, 6 month intervals, something like that), or is that a separate conversation ? :)

More or less everything about CGs is a separate conversation. According to the Process, they basically don't exist. Their patent policy is managed by agreement on joining the CG, which is like an independent entity. They have almost no requirements for fair process or anything else.

WICG (and a few others) are therefore tricky cases, since we treat them as a formal part of the Process when in fact they are an established part of procedure.

That said, I think if we get to a workable answer, the fact that they behave as if they were and want to be a more formal part of the W3C could be a strong motivation for them to adopt whatever we believe will work well.

[r12a]

It would be useful to understand what the expectations of HR groups would be for early-stage requests - aka, how do we keep from swamping their pipelines?

That's one of the key reasons we're suggesting that the WG performs a self-review before FPWD.

[pes10k]

@chaals Thanks for the background info. I think that figuring out how to bring WICG CGs "into the fold" (re process, horizontal review) would be a very good thing, given

1) how much CG stuff is shipping and being used by websites 2) that by the time things leave CG, its (often? likely? always?) too late to make important HR-related changes in a collaborative manner, and things get heated (see: above process questions with @LJWatson )

If this isn't the place though, happy to let that part of the convo die here, and move this to somewhere else (preference / suggestion?). Thanks again :)

[dwsinger]

I am disturbed by the under-current/assumption here that review is necessarily "episodic" and "requested". I don't think we should write the process making that assumption, and I think we should try to make it that the tooling and so on encourage much earlier, more incremental, review. As long as we expect it to be requested and episodic, it'll also be late, I fear.

[pes10k]

@dwsinger the motivation behind "episodic" (e.g. every X months) requirements is that this would be strictly more, and earlier review, than happens currently, where things are getting reviewed after a great deal of implementation effort, and so that getting a collaborative discussion going is already difficult. And that this would result in more incremental review.

[dwsinger]

Undoubtedly better to have multiple episodes than one that is much too late. But I'd rather strive towards a state where the WG, no later than FPWD, makes sure that the specification is "on the radar" of the cross-functional groups (github repo location announced, labels set up, and the ability to watch and get notifications is in place), and that those groups start noticing pulls and actions and do incremental review, especially when seeing big features or other changes. Then when it comes to the final checks, they will be in a much better position, and problematic architectural choices will have been caught early. This is 'continuous' as opposed to 'episodic'.

[LJWatson]

We should definitely do all we can to encourage continuous review (horizontal and otherwise), and I think the following sentence captures this:

Wide review should be sought early and often as a specification matures, to allow different parts of the web community to iterate on requirements, problems, and solutions.>

I've updated the proposal to re-enforce it further:

Horizontal review should be sought early and often as a specification matures, so that accessibility, internationalisation, privacy, security, and technical architecture are considered throughout.>

That said, I think it's important to complement this with some minimum requirements. Yes, there is the risk that people will do the minimum and nothing else, but without them there is the risk that the minimum is nothing at all.

I've also updated the proposal to include the steps discussed with @snyder.

Must admit I'd like to push this through for Process 2020 if possible.

[dwsinger]

I have a problem with "early and often" as it implies an episodic relationship. Rather, I think we should be emphasizing that anyone whose review is expected should be in a place that the review is ongoing, continuous, that they are able to see changes as they happen, comment on proposals before they are integrated, comment on issues before they become proposals, and so on, and that 'episodic' checks should be the occasional whole-spec sanity checks, not the bulk of the work and surely not the only action.

[LJWatson]

Fair enough. Would changing it from "early and often" to something like "on an ongoing basis", do the trick?

[pes10k]

@LJWatson @dwsinger I agree with the idea that review should be continuous and collaborative, but "on an ongoing basis" isn't a thing that a policy can be formed around, that can easily be enforced through process rules, etc.

But "every X months" or "at A, B and C stages" etc has the benefit of being enforceable and unambiguous.

So, i share your goal, but i think saying "ongoing" will end up not resulting in any "on the ground" change

[dwsinger]

OK, let's try again. Change "Horizontal review should be sought early and often as a specification matures" to "Horizontal review is a continuous process that should be enabled (initiated??) as early as possible and also explicitly sought periodically as a specification matures, "

[LJWatson]

I've updated the relevant paragraphs in both wide and horizontal review sections, as follows:

Wide/Horizontal review should be sought continuously as a specification matures...>

It's short and makes the ultimate goal clear, , plus there is no formal language in this paragraph (the "SHOULD" and "MUST" language comes later).

I think this encourages the behaviour @dwsinger is advocating for, without the problem of it being an unenforceable formal requirement that @psnyder mentioned.

[r12a]

The level of operational detail that's appropriate for the Process Doc is in some ways not clear to me. However, to make the i18n review process actually work, however, we (the i18n WG folks) need quite specific ideas, in quite practical terms, as to how we are going to manage the potential workload given the very small bandwidth we currently have in terms of numbers of people*.

To this end, we have been writing up some guidelines we hope to recommend to WGs, but would like to discuss with other HGroups and people such as those on this list. (We're not asking that that text be used in the Process Doc, but rather than it describes how we in i18n actually implement the Process Doc.) Read the i18n Horizontal Review ideas

We'd like to discuss these ideas with all those on this thread and other HR groups at TPAC. It seems that we might dedicate some of the i18n WG time on Monday to that. Please contact myself or Addison if you'd like to participate.

• About bandwidth: None of the organisations of people commenting in this thread are currently fielding participants in the i18n WG who could help with reviews. It would really help the horizontal review process to work better if we could get more feet on the ground doing the work, as well as policies.

[r12a]

Here are some comments on the currently proposed text by Léonie.

Horizontal review should be sought continuously as a specification matures

This is a good aspirational goal, however, given constraints on bandwith for doing reviews, it's not so straightforward to implement. That said, i'm not saying we should change or remove that text.

Before a proposed specification transitions onto the Recommendation Track, the group responsible for the specification MUST 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).

When the First Public Working Draft of a specification is published, a notification MUST be sent to horizontal-review-announce@w3.org.

It seems to me that these 2 paragraphs could be merged, since i think we are looking for the same self-reviews and notifications in both cases. Also, "Before a proposed specification transitions onto the Recommendation Track" wasn't clear to me what that meant.

Horizontal review MUST be solicited from the Horizontal Review groups at least 60 days before

Elsewhere we've been talking about 90 days. This gives time for the HG to schedule a review around other work, as well as time for, sometimes complicated, discussion or research around points raised after the review.

One thing that it may be worth stressing is that the document doesn't need to be frozen or finished before the final review starts (because that would effectively produce an unnamed LC period). You'll see in the text linked from the previous comment, that we prefer to describe the 'review' activity as a collaboration with the WG rather than Quality Control, and we hope that the WG will work with us as they make post-review changes to the spec until the spec is ready for CR.

It may also be worth noting that if it turns out that this process of handling review comments and finalising the spec takes less than the 60/90 days, then the transition date can be brought forward.

hth

[LJWatson]

Before a proposed specification transitions onto the Recommendation Track, the group responsible for the specification MUST 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).>

When the First Public Working Draft of a specification is published, a notification MUST be sent to horizontal-review-announce@w3.org.>

@r12a said:

It seems to me that these 2 paragraphs could be merged, since i think we are looking for the same self-reviews and notifications in both cases. Also, "Before a proposed specification transitions onto the Recommendation Track" wasn't clear to me what that meant.>

It's the point at which a specification is ready to be moved out of incubation and onto the charter of a WG, and so onto the Rec Track. I was thinking that a self-review should be completed before that transition is requested, and that the self-review should be referenced in the transition request.

If it's the case that a spec moves out of incubation, into a WG, and goes straight to FPWD, we could merge the two statements. I was working on the basis that a spec might spend some time in the WG as an ED before hitting FPWD though, which is why I had them as separate statements.

Happy to merge them if my working assumption is/was wrong?

[LJWatson]

Horizontal review MUST be solicited from the Horizontal Review groups at least 60 days before.>

@r12a said:

Elsewhere we've been talking about 90 days. This gives time for the HG to schedule a review around other work, as well as time for, sometimes complicated, discussion or research around points raised after the review.>

One thing that it may be worth stressing is that the document doesn't need to be frozen or finished before the final review starts - effectively producing an unnamed LC period. You'll see in the text linked from the previous comment, that we prefer to describe the 'review' activity as a collaboration with the WG rather than Quality Control, and we hope that the WG will work with us as they make post-review changes to the spec until the spec is ready for CR.>

Revising the paragraph to say 90 days is easy enough. To provide some reassurance and/or clarification, would this work:

Horizontal review MUST be solicited from the Horizontal Review groups at least 90 days before requesting transition to Candidate Recommendation. The review period is intended to give the Working Group and the horizontal review group time to collaborate on any changes that may be needed before the specification is ready to transition to Candidate Recommendation.>

[r12a]

The i18n WG plans to run over https://github.com/w3c/i18n-activity/wiki/i18n-Horizontal-Review-ideas during their meeting at TPAC.

Objective: check whether we have coherent ideas around how to work with WGs for horizontal review/support, given our limited resources.

Anyone on this list is invited to join the discussion. We have tentatively planned it for 4pm on Monday. If you want to suggest alternative timing, please discuss at https://github.com/w3c/i18n-activity/issues/759

[i will delete this comment from the thread after the discussion]

[brewerj]

Richard, good to hear that I18N is taking up horizontal review discussion during your TPAC meeting. Can you please notify myself and other interested parties on this thread if the time changes from Monday 4pm, so we can plan accordingly. Also, as I sit here preparing some TPAC work with Philippe, he mentions that Sam Weiler may be interested, so please include him in the loop.

Also, please note a new requirement that I believe we need to add, relating to "freshness" of wide review. For instance, if a wide review was conducted several years ago, too much may have changed. My recommendation is that wide reviews should time out after one year, and be updated at that time. If nothing significant has changed in that time, a diff should confirm that in one minute. Happy to have discussion. Thanks Judy

[LJWatson]

Reminder of the proposed Process words I referenced in earlier comments.

[nigelmegitt]

Thanks for the reminder. Looking through that:

Before a proposed specification transitions onto the Recommendation Track, the group responsible for the specification MUST solicit a horizontal review

@LJWatson this seems too restrictive, and not in line with existing practice.

However:

When the First Public Working Draft of a specification is published, a notification MUST be sent to horizontal-review-announce@w3.org

This seems to hint at something that has been suggested also in TTWG, which is that we should simplify the process of requesting HR by having a common process that triggers it, just in the same way that, say, the call for exclusions works. In other words, tie a publication event at a particular maturity level with an automated mechanism for initiating HR.

The question I was asked as Chair was something along the lines of "why do you have to go through this bureaucratic process when it's required for everything - shouldn't it just happen?" I must admit to having some sympathy with this!

Tying it into the process in this way would of course not prevent consultation with HR groups earlier (or later).

[r12a]

Notification is only useful if it leads to some related activity. I can't speak for other HR groups, but the i18n WG can't guarantee that it has the manpower to review all FPWDs, hence the very important part of the wording that you omitted from the excerpts quoted above: " (in many cases, submitting a self-review to the reviewing group will satisfy this requirement). "

Doing a self-review at this stage is expected to be more of an educational exercise than a quality check. In line with our view that the requesting WG is responsible for getting horizontal considerations built into the spec, rather than just handing that responsibility off to the HR group, what we're actually hoping for is that groups will (rather than just sending out a notification) do a self-review at this crucial early stage, when it's easy to make course alterations, and then consult with us where things are unclear or they need assistance.

So, yes, an automated notification may be useful as the WG passes HR, but it doesn't address the key need here. (And note that a WG may obtain greater benefit by doing the self-review before the transition to FPWD than after – an approach for which there is likely no trigger.)

[nigelmegitt]

in many cases, submitting a self-review to the reviewing group will satisfy this requirement

@r12a if a self-review is needed, then the presence of a self-review could be made a condition for publishing the FPWD.

[r12a]

Personally speaking, i think that would be a grand idea.

[LJWatson]

@nigelmegitt commented:

this seems to restrictive, and not in line with existing practice.>

The trouble is that existing practice is inconsistent, and it leaves open the possibility of a specification being thoroughly incubated and implemented without ever having been through any kind of horizontal review. The expectation is then that the spec will transition onto the Rec Track and speed its way to Rec, and at that point horizontal review effectively becomes a blocker - and that isn't good for the spec editors or the HR groups.

This seems to hint at something that has been suggested also in TTWG, which is that we should simplify the process of requesting HR by having a common process that triggers it, just in the same way that, say, the call for exclusions works. In other words, tie a publication event at a particular maturity level with an automated mechanism for initiating HR.>

Yes, the email list has existed for quite some time but oddly it isn't used officially by the HR groups. @plehegar and @swickr have been working on harmonising the HR process though and I'm hopeful we'll see some consolidation soon.

The question I was asked as Chair was something along the lines of "why do you have to go through this bureaucratic process when it's required for everything

• shouldn't it just happen?" I must admit to having some sympathy with this!>

Yes it absolutely should. Unhappily it too frequently doesn't though, and that's why we're trying to make the process much clearer.

Tying it into the process in this way would of course not prevent consultation with HR groups earlier (or later).>

It's already in the Process, this is just an attempt to make what's in the Process a bit more specific, but you're right, this doesn't exclude doing more it only specifies a minimum.

Based on a suggestion from @dwsinger we used the wording (for both wide and horizontal review) - "...should be sought continuously as a specification matures", to encourage early and often review.

[nigelmegitt]

Based on a suggestion from @dwsinger we used the wording (for both wide and horizontal review) - "...should be sought continuously as a specification matures", to encourage early and often review.

I can see the motivation for this, but it may have undesirable consequences: I fear that if WGs take it at face value the HR groups will drown in small requests that have no impact.

Thinking about each HR request as a transaction for the reviewing group, that transaction has:

• an overhead for setup, understanding the subject area, the working group involved, managing the ticket/issue etc,
• then some "working" time to understand the specific request being made and draft the response,
• then some more overhead in communicating that response, tracking and closing the ticket.

Note that the per-review overhead is pretty similar across all requests, but the actual request processing time varies.

Since HR groups like i18n (sorry to pick on you @r12a et al) are already concerned about workload, we should be helping them to be efficient by maximising the ratio of "working" time to overhead for them. Continuously seeking review very likely does the opposite of this. It also makes it harder to predict workload.

So perhaps we should qualify that blanket statement about continuous review!

[michaelchampion]

I came across something the other day that might be relevant, the phrase "ambulance at the bottom of the cliff". The article i found it it was https://medium.com/swlh/3-problems-to-stop-looking-for-in-code-reviews-981bb169ba8b but it was the phrase more than the article I found memorable. See: https://medium.com/@nz_msc/blog-an-ambulance-at-the-bottom-of-the-cliff-7b4238f1e5a6 http://www.worldwidewords.org/qa/qa-amb1.htm

Better put a strong fence round the top of the cliff. Than an ambulance down in the valley!"

The lessons for W3C might be:

1. Invest in research and tooling for automated A11Y / I18N / checks. W3C has a lot of academic members, some must be doing or at least aware of research in this area. Yes it will take awhile to get anywhere near the level of linting, static analysis, restyling, etc. tools that software developers have available now, but it will take forever if you don't start.

2. I think this is the plan now but double down on putting it in practice: Write down the principles behind what wide reviewers do, disseminate them to WGs (and CGs, OSS projects, etc), and spend small amounts of time early in the process to coach spec developers on how to avoid problems later on.

[aphillips]

@michaelchampion I can't disagree with the sentiment in general, still...

You mean like specdev and the short and long checklists?

Automated I18N checks of specification text are hard. We could provide some linting for data structures and other technical artifacts. But nothing is as good at natural language understanding as a human being ;-). And much of what we do, at least, is about understanding the intention of the spec developer.

Horizontal review is not where I or my I18N colleagues would prefer to spend our time. It is far more useful (and interesting) to focus on the more immediate issues surrounding language and cultural support or, as with the language requirements work, collecting and describing the requirements and gaps to support the world's languages/cultures.

The reason the ambulance is frequently at the bottom of the cliff is that the ambulance drivers didn't consider the warning signs or chain link fence at the top: they didn't think it applied to them. If more WGs reviewed the checklists and pinged I18N with potential issues before writing and developing their specs, horizontal review would be irrelevant.

[LJWatson]

There is definitely more we need to do before we get review working the way we want it to; more self-review questionnaires, tooling where and when it's appropriate and so on, but I don't think Process language is necessarily the way to make those things happen.

When i spent time last year talking to team contacts, WG chairs, specification editors, members of HR groups and a few others besides, one of the points of feedback that came through most clearly was this:

Uncertaintys: Whether HR is required or encouraged; knowing if something is an HR issue or not; when and how it is requested; how long it takes; what is returned; responding to issues; resolving disputes; inconsistent processes.>

The proposed Process language is an attempt to address this feedback.

To try and keep things moving, unless anyone strongly feels otherwise, I'd like to move this to a PR so we can try to get it into Process 2021 if we can.

[michaelchampion]

Thanks @aphillips and @LJWatson. I was more struck by the "ambulance" metaphor at a high level than claiming the expertise to make concrete suggestions in any level of detail.

One thing that comes through in both your responses is "drivers didn't consider the warning signs or chain link fence at the top: they didn't think it applied to them." The proposed Process language at least moves in the right direction to put up fences and warning signs so the I18N and A11Y ambulance crews aren't so overworked.

[dwsinger]

Perhaps it's a separate but related issue: we'll never get a completely crisp definition of what an adequate wide review, with clear bright-line edges.

Who gets to assess whether the review was sufficiently wide, and sufficiently respected? At the moment, it's (theoretically) the Director, but in practice it varies around the team, and it's not clear whether they would all make the same call when presented with the same question.

[LJWatson]

In an effort to nudge this along, I've taken the text I first proposed in March 2018, discussed and evolved here and later moved to the W3C wiki, and proposed it as PR #401 .

[frivoal]

then [...] could be made a condition for publishing the FPWD

I'm not in favor of adding formal conditions to entering FPWD. Instead of hastening the start of HR and boosting the quality of FPWD, a very likely effect is delaying the point at which works enter the formal W3C Process, therefore delaying the point at which any of the rules of the Process apply at all, and delaying the start of HR (and of formal consensus, and of the ability to raise formal objections, and of the patent policy…).

[nigelmegitt]

I'm not in favor of adding formal conditions to entering FPWD

+1

A better outcome would be that we allow some kind of less formal HR process prior to FPWD, and then put specs formally on the HR "rails" from FPWD onward.

[cwilso]

Indeed. I would be VERY concerned about blocking FPWD on obtaining those reviews.

On Tue, May 19, 2020 at 1:56 AM Nigel Megitt notifications@github.com wrote:

I'm not in favor of adding formal conditions to entering FPWD

+1

A better outcome would be that we allow some kind of less formal HR process prior to FPWD, and then put specs formally on the HR "rails" from FPWD onward.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/w3c/w3process/issues/130#issuecomment-630685007, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAD3Y6NW753RNAOEF3RYQI3RSJCVRANCNFSM4ECUOH3A .

[aphillips]

It's hard to review something that isn't public yet or isn't published yet, so I agree. But I do think that having a checkpoint related to FPWD is helpful and necessary. I liked the aspect of @LJWatson's draft in which publishing FPWD results in the HR process starting.

I, of course, agree with @nigelmegitt's comments elsewhere that WGs should (and should be encouraged to) start doing HR-related work (such as engaging the HR WGs and doing self-reviews) before FPWD. But I wouldn't require it, for the reasons mentioned by @frivoal.

What's the problem with saying "FPWD must be announced on the HR list" and reviews requested?

[dwsinger]

What's the problem with saying "FPWD must be announced on the HR list" and reviews requested?

I think that's fine. "And the github repos connected, tooled (e.g. with the standard label set), and so on." i.e. the team makes sure that after FPWD, the document is 'on the radar' for the community as a whole.

[nigelmegitt]

What's the problem with saying "FPWD must be announced on the HR list" and reviews requested?

No problem in general. As discussed elsewhere on this issue, I agree that the Process should assign the responsibility to some entity to take the action. I'd give it to the team, and let them use tooling if they like, which they almost certainly do.

[frivoal]

What's the problem with saying "FPWD must be announced on the HR list" and reviews requested?

None. I am very much in favor of that. I am not in favor of blocking FPWD based on things that must have happened before it.

[nigelmegitt]

What's the problem with saying "FPWD must be announced on the HR list" and reviews requested?

None. I am very much in favor of that. I am not in favor of blocking FPWD based on things that must have happened before it.

There is a phrasing issue here: it needs to be written so that it is clear that the announcement is a post-publication task not a pre-publication requirement.

[aphillips]

I am not in favor of blocking FPWD based on things that must have happened before it.

Note that some things must have happened before FPWD. Generally there is a charter and you have to do housekeeping stuff such as pubrules. Drafts don't just fall out of the sky. And I do favor encouraging WGs to do self-reviews and such as early as possible. But for requirements, we can use FPWD as a trigger.