Horizontal Review -- 21 Sep 2016

<MichaelC_> scribe: MichaelC

<scribe> scribe: MichaelC

js: APA is moving towards asking for an ¨accessibility considerations¨ section as a routine part of specs

point out some of the things that implementers need to be conscious of, even if that stuff is also woven into the spec

ap: I worry those sections can be a ¨penalty box¨

so for I18N wouldn´t want to do this

but can see value for a11y

pl: have seen less need for this because of normal reviews

js: really useful to be able to say where the rub is

pl: the self review questionnaire has been very helpful

could provide some common pitfalls advice

js: checklist sounds like a good approach

though APA also wants a full Web Technology Accessibility Guidelines

jb: have heard that once a guide like that exists, the horizontal group can be disbanded

<r12a> https://www.w3.org/International/techniques/developing-specs?collapse&open=language

there are still things the group needs to do, to address things that can´t be captured by a self review guide

ap: the guide helps to avoid basic mistakes

and trigger questions earlier in the development process

that´s valuable

I worry about how to schedule reviews and interactions with WGs in a constructive manner

there is the CR gate, but get review requests only then

then they are mad at us when we find issues and need to hold up the spec

and difficult to schedule review for ourselves that way

ri: we want to get groups to start thinking about things before we look at it

ideally before FPWD

but that doesn´t mean the checklist replaces our role

in more comprehensive review

js: APA has also been impacted by urgent CR timeframe reviews

to forestall we look at specs published to TR on a regular basis

try to catch them early in the lifecycle

has led to being able to get features into specs

also to creation of specs that supplement with accessibility features

we´re struggling now with API specs that lack plain explanation of what they do

would like introductions etc.

gz: use cases really help

<r12a> https://www.w3.org/International/techniques/developing-specs?collapse&open=language

we can review those and predict issues

ri: I think a checklist is much better than asking someone to read and remember a whole doc

which takes time, working memory etc. that people less likely to advance

checklist has do and don´t stuff

ar: +1 to plain language doc about what a spec does

I recommend them being separate from the technical spec

spec without this can lack design thinking

specs can be hard to read, so having this material separately makes it easier to consume

then they can dig deeper into the spec if they need

ap: we don´t have a structured way of engaging

we don´t get a lot of unsolicited review requests, notification of work, etc.

we have relationship with groups that tend to have known issues

otherwise I only find out from routine publication announcements

jb: what are mechanisms for discoverability of stuff outside spec?

ar: put link at top of spec

in design phase often start with explainer doc before spec

which helps design

jb: how does that help with impact statements?

ar: gives good orientation so you can figure out what you might need

ri: we don´t undertand all the technologies at W3C

have to go through learning curve when reviewing new specs

the explainer help with that

but we still have to get into the spec

and when they are just bare algorithms, hard to follow even with the explainer

just a short para at the top could help

tl: code comments

ri: es

and examplyes really help

tl: @

<slightlyoff> here's the Intersection Observer explainer: https://github.com/WICG/IntersectionObserver/blob/gh-pages/explainer.md

ri: so want more than a link to explainer, do need some of that material in context

ap: explainers and spec can get out of sync

<slightlyoff> and the spec: https://wicg.github.io/IntersectionObserver/

<Zakim> MichaelC, you wanted to talk about setting cross review expectations and to say explainers help us a lot

<slightlyoff> here's the Service Worker explainer doc: https://github.com/w3c/ServiceWorker/blob/master/explainer.md

<slightlyoff> and the spec (maintained in the same repo): https://w3c.github.io/ServiceWorker/

mc: @@ setting cross review expectations

jb: get that spec developers don´t want to clutter spec, but also hear the value for additional info

<slightlyoff> here's the background sync explainer: https://github.com/WICG/BackgroundSync/blob/master/explainer.md

do we have evidence about how the approaches work?

<slightlyoff> and the spec: https://wicg.github.io/BackgroundSync/spec/

ri: the link to explainer is also great, just also need some inline guidance

jb: we´re guessing right now about which approach works

think the impact statement in the spec can trigger attention and interest

we haven´t tested these ideas

ri: have considered requesting teleconferences with spec developers

for them to explain the features

because of when we don´t understand the techology well

the link at the top to explainer would also help

we´ve done some recent reviews with embedded examples, much easier to review

leads to better comments

js: strong +1 to RI

explanation helpful, conversation can be a good idea

where we have common issues, we try to recruit participants in our group with domain knowledge

lost a couple key ones this week though :(

ap: get that spec owners don´t want stuff that is extranneous to implementers

don´t want create extra work for them for uncertain reason

I´d like to know WGs how we can help them with our horizontal review

<r12a> https://www.w3.org/International/review-request

r@: what is a recommended procedure?

ri: ^ is our documented recommendation

I suggest maybe the other horizontal groups might want to create a document like this

ap: Process doesn´t have many points

avoid pain by following techniques

ri: github labels allow us to get notification of things that specs tag

jb: there´s always requests to solicit horizontal review early and often

but those can be wishes

want procedures and tools to help reify that

js: need for explaining the IDL growing

we can´t impose some of our requests

want to explore what W3C-wide practices should be recommended

can TAG help with that?

jb: it can be hard for W3C to change practice even when there´s agreement on the changes

ap: I made some request in Process 2015

for a formal gate, before CR, to ensure we reviewed

absent the formal gate, chairs miss it and CR becomes the only one

which is too late

jb: what happened with that proposal?

ap: nothing

hope to re-raise it

there was a time for us when all we could do was emergency reviews

which compromised quality

ri: under new W3C structure, Ralph has responsibility for ensuring horizontal reviews happen

he´s not here but planning to work on that

PLH is already pinging I18N for reviews in his new role

so hopefully the new organization will help

want to continue discussion so we can have coordinated recommendations

to give to ralph

for process, guide, training

<Judy> +1 to document recurring HR hiccoughs

mc: I also want to ensure ongoing coord

maybe we want a list to collate our discussions, which sometimes are sporadic

ri: Ralph should be instigating that

jb: +1 to a list

ri: MC and I might be specialists, we need some from the other horizontal areas too

mc: can we go ahead with a list?

jb: take to Ralph

ri: +1

mc: ok, so we don´t know specific next steps yet, but expect there will be some

ri: also note Virginie Galindo updating the chair training

you should work with her on getting some thoughts in

mc: hopefully also through Ralph

so I hope we will be able to increase our coordination and announce next steps soon

Horizontal Review
21 Sep 2016

Attendees

Contents

Summary of Action Items

Summary of Resolutions