See also: IRC log
<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
This is scribe.perl Revision: 1.144 of Date: 2015/11/17 08:39:34 Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/ Guessing input format: RRSAgent_Text_Format (score 1.00) Succeeded: s/Renata/Renato/ Succeeded: s/es/yes/ Succeeded: s/oe/one/ Succeeded: s/agenda order 8, 1// Succeeded: s/agendum 1. "Techniques for effective horizontal review" taken up [from MichaelC_]// Succeeded: s/agendum 8. "Impact statements" taken up [from MichaelC]// Found embedded ScribeOptions: -final *** RESTARTING DUE TO EMBEDDED OPTIONS *** Found Scribe: MichaelC Inferring ScribeNick: MichaelC Found Scribe: MichaelC Inferring ScribeNick: MichaelC WARNING: No "Topic:" lines found. Present: Janina_Sajka Addison_Phillips Richard_Ishida Eric_Eggert Renato_Iannella Shadi_Abou-Zahra Francesco_Martino Peter_Linss Gottfried_Zimmerman Joshue_O_Connor Matt_King Katie_Haritos-Shea Alex_Russell Wilco_Fiers Alastair_Campbell Travis_Liethead Judy_Brewer Joshue108 Regrets: virginie Got date from IRC log name: 21 Sep 2016 Guessing minutes URL: http://www.w3.org/2016/09/21-horizontal-minutes.html People with action items: WARNING: Input appears to use implicit continuation lines. You may need the "-implicitContinuations" option. WARNING: No "Topic: ..." lines found! Resulting HTML may have an empty (invalid) <ol>...</ol>. Explanation: "Topic: ..." lines are used to indicate the start of new discussion topics or agenda items, such as: <dbooth> Topic: Review of Amy's report[End of scribe.perl diagnostic output]