Chair Training - Fifth episode: "Horizontal Review" (session 2)

20 Oct 2015


See also: IRC log



Coralie Mercier, Florian Rivoal, Wendy Seltzer, Judy Brewer, Richard Ishida, Virginie Galindo, Natasha Rooney, Yoav Weis, Andreas Tai, Renato Ianella, Adam Crofts, Adrian Hope-Bailie, Kevin Gavigan, Daniel Peintner, Nigel Megitt, call-in_user1, call-in_user2
Nick Telford-Reed, Jeff Jaffe
Virginie Galindo


<koaliie> Previous session (2015-10-13)

<scribe> scribenick: koalie

[15 people on call]

<koaliie> Slides

Objective of that hour (slide 1)

Virginie: horizontal review are important for the web
... Horizontal review is about support of privacy, security, accessibility and internationalization
... all deliverables of the W3C are concerned
... wonder if it's OK in terms of accessibility, security, privacy and so on
... goal: Make a trustable web for all, that scales for business
... so we're spending some time with education and have identified some materials

<renato> help: should I be seeing the slides in the WebEx window??

Why, when and how should you horizontally review ? (slide 4)

Horizontal review mechanics (slide 5)

Virginie: contact the appropriate reviewer
... share your timeline for your spec
... you may have an initial feeling of what you need some help on
... share that
... you know the technology so you probably know where you need attention
... another good practice: identify a champion in your group to deal with the horizontal reviewer

<renato_> got it: http://www.w3.org/2015/10/W3C-transversal-review-101_13OCT2015.pdf

Florian: with regards to the champion, isn't that naturally the editor?

Virginie: The objective depends on how heavy the work will be
... your editor can be the champion
... but someone in the group with a special interest in a11y, i18n, security or privacy, that might be that person
... It's important this person doesn't have thousands of things to do wrt the spec

Florian: Bandwidth: my impression is that groups are heavily loaded already; is it practical to ask for review earlier given that things may change significantly?

Virginie: earlier review is more to ensure the Group has on their todo list to care about horizontal review
... and raise awareness
... you don't want to have to change the whole spec if you seek review too late
... early review should not overload the expert, but start initiating the dialogue on awareness, education and accurate shaping of the technology happens when the spec matures

Richard: you covered what I would have said
... as a representative of a review group (i18n) we're happier to do earlier reviews
... we'll have problems of load at each step anyway
... if we can intersect at FPWD, we can spot areas that need to be worked on
... it's a quality principle
... do things up front to avoid problems further along in the process

Virginie: review has to happen along the life of the spec you're delivering

<Zakim> Judy, you wanted to also support Virginie's reply with an example for accessibility

Judy: There is a bandwidth problem at any point
... but often we find people who thinks accessibility problems will arise as spec matures, but we find it's better to intersect earlier

Reviews... (slide 6)

Virginie: You have 4 reviews to conduct
... in addition to business as usual
... this is the guarantee of Open Web consistency
... so be brave
... you won't be alone
... ensure that those reviews happen with your champions
... What I suggest is that we review in next slides the horizontal domains
... let's see what is at stake and what materials will be at your hand

Internationalization : I18n (slide 7)

Virginie: To ensure that the technology supports text in any writing system of the world

I18n structure (slide 8)

Virginie: Internationalization (i18n) is part of the Interaction Domain
... i18n IG, WG and Tag Set IG and some community groups
... ask your review to the Internationalization WG

I18n support (slide 9)

Virginie: resources

<koaliie> Internationalization Techniques: Developing specifications

Virginie: slide 10 has the list of people to contact in i18n
... Richard, would you like to add anything?

<r12a> www-international@w3.org

Richard: Yes, please do not write to me. You'll get better answers if you involve more people; www-international@w3.org

<r12a> public-i18n-core@w3.org

Richard: if you want to engage the i18n WG before the review: public-i18n-core@w3.org
... Addison will schedule a review for you

<r12a> Internationalization Best Practices for Spec Developers

Richard: today we'll publish a FPWD of Internationalization Best Practices for Spec Developers

<r12a> http://www.w3.org/International/techniques/developing-specs-dynamic

Richard: hoping this will be a useful thing for you
... consult yourselves before talking to us
... we organised DOs and DONTs by task
... We're in the early stage of committing this to electronic paper, so you should feel free to discuss this with us
... but a checklist of this kind is useful for you in the early stages

<r12a> http://www.w3.org/International/reviews/openissues/

Richard: another thing: if you interact with us, we'll raise issues on your list and our list; keep both lists copies
... one more thing: designate champions for horizontal reviews, but don't leave all the work related to i18n to that champion
... the whole of the wg should learn and next time they write a spec they have that knowledge

Accessibility : A11y (slide 11)

Virginie: Accessibility allows anyone – including the ones with disabilities – to access the Web
... Web accessibility supports social inclusion, but also improve SEO and device independence
... important for making a good web
... Accessibility targets web content, user agent, assistive devices, authoring tools, and evaluation tools

A11y structure (slide 12)

Virginie: WAI is responsible for accessibility at W3C
... keep in mind that as chair and editor, you'll need to ask your review to APA WG Accessible
... Platform Architectures (APA) WG
... formerly Protocols and Formats Working Group

A11y support (slide 12)

Virginie: Resources


Draft best practices for developing specifications: 

Web Technology Accessibility Guidelines
 Draft Checklist: http://w3c.github.io/pfwg/ wtag/checklist

• 7/24 irc channel for discussion (but not complete review)



Virginie: Slide 14 has the list of people to contact in accessibility
... send your requests to wai-xtech@w3.org mailing list
... Judy, would you like to add a few words

Judy: Thanks for the introduction, Virginie
... there are different groups in WAI
... two main contacts for accessibility review are Janina Sajka, chair of FPWG to become APA WG
... and Michael Cooper is the team contact
... there are a few mailing lists associated with APA

<Judy> public-apa@w3.org: ordinary Working Group discussion;

<Judy> public-apa-comments@w3.org: public comments on publication;

<Judy> wai-xtech@w3.org: Working Group discussions involving a wider audience than the WG membership, and where specification review announcements and submissions are copied;

<Judy> w3c-wai-ig@w3.org: announcements of Working Group activities including publications, key events, and specification reviews.

Judy: there's one of the WG regular discussion, for comments on the work. wai-xtech is the one we recommend for horizontal reviews, as well as the WAI IG list
... there is a document: web technology accessibility guidelines (provisional name)
... about requirements for specs; that has a checklist
... this is a priority to complete this document in the next few months
... to allow self-checking for implications
... before asking review to APA
... but don't hesistate to contact us directly
... in addition, that group is to better liaise with other groups
... Groups, work with us, develop liaisons, ensure to coordinate back with APA

Privacy (slide 15)

Virginie: User activity is considered something that could be private
... privacy domain helps W3C ensure the web platform doesn't harm the user's privacy
... includes tracking user, fingerprinting of the machine, and the API design

Privacy structure (slide 16)

Virginie: Privacy at W3C http://www.w3.org/Privacy/
... Ask review to Privacy Interest Group

Privacy support (slide 17)

Virginie: Resources


(draft) Guidelines

– Fingerprint guidance for editors


– TAG review questionnaire (covering security and privacy)



Virginie: slide 19 has a list of contacts
... you should contact Christine Runnegar runnegar@isoc.org and Tara Whalen tjwhalen@gmail.com the co-chairs of PING
... Nick Doty is the team contact
... sending an e-mail to Christine or Tara initiates your review

Nigel: I wonder if all the reviews are needed only when APIs are being specified?

Virginie: As soon as you're getting a technology specified, you should ask reviews
... chaals raised a good question during session 1 last week
... if my privacy review demonstrate that my technology isn't good, what happens?
... Wendy said the spec may not go to REC

<Florian> unlike i18n, for privacy we should raise questions to the chairs directly, not to the IG mailing list?

Virginie: so have in mind that technology that doesn't go through review or has negative feedback is at risk of not being finalised

[Coralie: Florian, yes]

Security (slide 18)

Virginie: this is about making sure to prevent security leaks on the Web
... security activity aims to adapt the web security model with new features and special care in the API design

Security structure (slide 20)

Virginie: Security at W3C http://www.w3.org/Security/
... Reviews must be asked to Security Interest Group and TAG
... at the moment, the TAG is active on security aspects

Security support (slide 21)

Virginie: resources


(draft) Guidelines

– TAG review questionnaire (covering security and privacy)



Virginie: This is a draft but a good starter to raise questions and trigger discussions in your group(s)
... slide 22 has contacts


Web Security chair

– Virginie Galindo virginie.galindo@gemalto.com

• TAG co-chairs

– Dan Applequist appelquist@gmail.com – Peter Linss peter.linss@hp.com

• Security team contact:

– Wendy Seltzer wseltzer@w3.org


Florian: We have been using the TAG self-assessment questionnaire in the CSS WG
... I wasn't aware that the TAG wanted people to engage with the TAG
... we have TAG members in the CSS WG but I haven't heard about that

Virginie: experts in security are more in the TAG than Security Interest Group
... e.g. Mark Nottingham, Yan Zhu
... I'm trying to get more expert to the Security Interest Group
... but that the moment, security is a "poor" domain, lacking volunteers to perform reviews

Richard: I wanted to say two things; we're restricted in the number of people able to do i18n reviews
... if you're aware of anyone in your companies willing to help, please let us know and we'll be happy to have them on board
... Another thing is that we'll read your specs with our understanding. Some specs are hard to read.
... if you put things in algorithmic form without adding a description, this makes it hard for us to understand it well enough
... if you have examples in your specs, that is extreeeemely helpful for us
... try to make your specs as readable as possible
... we'll make better reviews.
... thanks.

<Zakim> nigel, you wanted to ask, if the spec isn't readable, is your review response "do more work"?

<Judy> +1 to Richard's request to consider readability of your specifications; this can even reduce the number of times that a specification may need review. It saves time for horizontal reviewers, as well as for the eventual implementers of your specification(s).

Nigel: coming back to Richard's point, if we're asking someone to read and understand a spec, readability is very important.
... what is the appropriate response from a review group to a spec they find hard to understand?

Judy: Great question
... this is going to become more specific whether a group has secured a review

<virginie> +1 to schuki, I read mike west specs as novels :)

<renato> URLs for Mike West's specs?

Judy: and decide whether there are features that could become a barrier
... typically, we'd send back a request for clarification
... that may cause lag in getting accessibility feedback to the group

<virginie> exemple of security spec edited by Mike West : http://www.w3.org/TR/SRI/

Judy: right now it's a practical concern
... as we come up with clearer systems for director's review and more mature document stages
... implementers would benefit from a clear writing as well

Florian: It's genuinely useful feedback if my spec isn't clear; do tell me

<r12a> +1 to Florian's point

<virginie> +1 to Florian

<r12a> ie. that if horizontal review groups can't easily read specs, how can we expect the wider public to review

Thank yous (slide 23)

Virginie: Thanks to all the people who made that presentation possible

Virginie: Coralie Mercier, Judy Brewer, Léonie Watson, Wendy Seltzer, Felix Sasaki, Richard Ishida, Keiji Takeda, Nick Doty, and... you

Virginie: please, don't forget to evangelise in your own group(s)
... that there are 4 reviews to conduct
... Thanks for your time and listening

<AdrianHB> thanks

<nigel> Thanks!

<yoav> Thanks! :)

[no audio recording this time; sorry!]

Summary of Action Items

[End of minutes]

Minutes formatted by David Booth's scribe.perl version 1.140 (CVS log)
$Date: 2015/10/20 12:39:06 $