See also: IRC log
Related:
<koaliie> Previous session (2015-10-13)
<scribe> scribenick: koalie
[15 people on call]
<koaliie> Slides
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??
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
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
Virginie: To ensure that the technology supports text in any writing system of the world
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
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
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
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
Virginie: Resources
[[
Draft best practices for developing specifications:
Web Technology Accessibility Guidelines http://w3c.github.io/pfwg/wtag/wtag.html Draft Checklist: http://w3c.github.io/pfwg/ wtag/checklist
• 7/24 irc channel for discussion (but not complete review)
– https://github.com/w3c/a11ySlackers
]]
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
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
Virginie: Privacy at W3C http://www.w3.org/Privacy/
... Ask review to Privacy Interest Group
Virginie: Resources
[[
(draft) Guidelines
– Fingerprint guidance for editors
• http://w3c.github.io/fingerprinting-guidance/
– TAG review questionnaire (covering security and privacy)
• https://w3ctag.github.io/security-questionnaire/
]]
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]
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
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
Virginie: resources
[[
(draft) Guidelines
– TAG review questionnaire (covering security and privacy)
• https://w3ctag.github.io/security-questionnaire/
]]
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
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!]