TPAC 2019 Internationalization (I18N) WG -- 16 Sep 2019

https://www.w3.org/wiki/I18N_2019_TPAC

Introductions

<addison> scribenick: DavidClarke

<addison> https://www.w3.org/wiki/I18N_2019_TPAC

addison: Agenda does not lookpacked yet, but will become so

r12a-again: privacy Ping group will be coming to I18n this afternoon
... work through wiki page and discuss notification, preferably straighh after
... also some discussion with accessibilty likely
... discussion on tooling after 4 pm meeting

PLH: warned that tooling may change version of XML - beware of consequences

r12a-again: Makoto-san should be invited for JLTF at 13:00 Tuesday , accessiblilty of Ruby, and how to move Ruby forwards
... ideally fantasia should be there, too

addison: what other groups do we need to talk to

<addison> ACTION: addison: ping rossen about time to meet CSS about text

<trackbot> Created ACTION-826 - Ping rossen about time to meet css about text [on Addison Phillips - due 2019-09-23].

addison: CSS 10am Tuesday, so ping Rossen (co-chair CSS) to confirm availability

r12a-again: Thursday - Marie-Claire I18n course development

Addison: What else do we aim to accomplish? Agenda backlog, and very old tracker issues
... needs to schedule time with accessibilty iso-639
... Should be invite ivan?

<addison> ACTION: addison: contact wendy reed regarding treatment of language in pub manifest

<trackbot> Created ACTION-827 - Contact wendy reed regarding treatment of language in pub manifest [on Addison Phillips - due 2019-09-23].

r12a: heis very busy, please talk to Wendy Reid on change of language in pub-manifest

addison: so probably 1 more cross over meeting. What about JSON LD?

r12a: what is current status of JSON-LD?

status update scheduled for 9:45

addison: Article on well formed versus valid rtl, and visit document development backlog. Charmodnorm has been published, others still need work.
... We have an HTML DOM spec review.

Bert: Not reviewed it yet.

addison: make time to talk about HTML this morning.
... AOB

<addison> -- exeuent PLH --

JSON-LD

jason: Here to see how WG works

addison: There are a number of specs that have ha lack of standardisation about language handling.

<addison> https://w3c.github.io/string-meta/#

addison: Created string meta issues to discuss
... Discussed with Ivan Herman about how to fix the problem generally. Result was to charter new WG for Linked Data with language and direction metadata.
... Not much support, as reluctant to reopen existing specifications
... That may not go forwards. There are some other proposals.

r12a: The current proposal is to start a community group.

duerst: Says IETF use an update scheme referring to specific paragraphs. This works but can be difficult to read. This may be the appropriate way for this problem. but W3C doesn't seem to have an update
... system
... CSS has gone to a module form which enable changing separate parts
... is this differntial spec viable in W3C rules?
... People don't like to reopen the spec. Why technical or editting issues.

addison: Limiting the scope often pushes back to I18n group

duerst: Who will do work and accept the result of changes

addison: Mostly and existion of existing specifications. Side effect is that the core spec is spread across many specifications concerns community.
... JSON-LD is seen as the spec for refernce and would prefer i18n to do the work on this. We need to talk to them about timelines and liaison

r12a: Ivan suggested I18n should do the work, but we do not have the RDF experience. We prefer to collaborate and it is inappropriate for I18n to force changes onto another spec
... Related to that, i18n needs to complete document on string-meta

<r12a> https://w3c.github.io/string-meta/

r12a: Occasionally we lose focus. We need better prioritisation.

addison: with only 2 people editting documents and having full time jobs it is difficult.

DavidClarke: Maybe try to do it Agile backlog style, with completion of some better than many partially completed docs.

r12a: We need better focus

addison: We backed off string-meta after meetings with other stakeholders
... String-meta needs to influence JSON-LD as this is a base core for many other specs. Is the document adequate, as it seems to need explanation after it has been read by other parties

r12a: It is a complicated topic, but we have rewritten it to take on some of these concerns.

addison: I use it at work for reference, even though not published, yet.

bert: It is longer than I expected

r12a: It grew as we tried to explain the concepts more simply. Reoganised it to allow ToC to lead to relevant sections easily.

<addison> ACTION: addison: ask group to read string-meta and provide feedback

<trackbot> Created ACTION-828 - Ask group to read string-meta and provide feedback [on Addison Phillips - due 2019-09-23].

r12a: i18n WG - please re-read it by tomorrow for comments and discussion
... In general, what else shall we do to propogate the bidi issues? Do we go to Ralph?

duerst: Talk to everyone, but then nobody may feel responsible

r12a: It would be useful to speak at the plenary, but we can't do that.

duerst: We could visit interested groups at the plenary and split up to cover more ground.

atsushi: could it be raised at the Chairs lunch or breakfast?

<addison> ACTION: addison: raise string-meta problem at chairs lunch

<trackbot> Created ACTION-829 - Raise string-meta problem at chairs lunch [on Addison Phillips - due 2019-09-23].

r12a: short demo of how it breaks with latin characters at the start of Arabic text
... Already has slide presentation which talks about it.

<r12a> https://www.w3.org/International/talks/1810-paris/#metadata

r12a: Summarize: Addison will look into chairs' lunch. I18n will read and finish off string-meta, subject to other priorities.

Addison: We are not the people to do the work for JSON-LD as they will not own it.
... all present agreed
... should we ping TAG about it.

r12a: They handed it off to Sangwhan et al. Menu is interested.

addison: adjourn for 20 minutes.

Info Share

<Bert> scribe: Bert

addison: We were scheduled tomorrow to meet CSS and WAI. Confirmed. Before and after lunch.

r12a: plh told me a11y folk looking at "bliss" symbols.
... He thought i18n might want to comment on it.
... it will put numbers in an "data-symbol" attribute that refer to bliss symbols.
... Can be applied to a word or phrase.
... Bliss symbols can be spaced differently depending on function.
... That might be a first issue.
... The symbols can be localized as well, e.g., switching verb noun order.
... Haven't thought it through, but might need some language labeling.
... "data-symbol" also seems kind of generic.

DavidClarke: "data-bliss"?

r12a: I have some links:

<r12a> --

<r12a> The symbol attribute in [1] identifies the concept for symbols, eg

<r12a> cup of Tea

<r12a> The numbers are the same references numbers used in Bliss (BCI numbers):

<r12a> http://www.blissymbolics.org/

<r12a> Looks to me that this is highly relevant for Unicode and would benefit from your experience. Make sure to take the first opportunity to talk to Michael.

<r12a> Philippe

<r12a> [1] https://w3c.github.io/personalization-semantics/content/#symbol-explanation

<r12a> --

r12a: The "Michael" is Michael Cooper, for a11y.

duerst: Spec says "copyright license from Bliss"...

R12a: Not sure how that works, but not sure that is _our_ problem.

duerst: Unicode might worry about that.

<addison> ACTION: addison: check with Unicode about the status of bliss symbol encoding

<trackbot> Created ACTION-830 - Check with unicode about the status of bliss symbol encoding [on Addison Phillips - due 2019-09-23].

r12a: There is a proposal for Unicode from several years ago. We may need to do some liaising with them.

<addison> action-826?

<trackbot> action-826 -- Addison Phillips to Ping rossen about time to meet css about text -- due 2019-09-23 -- OPEN

<trackbot> https://www.w3.org/International/track/actions/826

<addison> close action-826

<trackbot> Closed action-826.

r12a: As brief summary, bliss is a kind of language, the symbols combine into compound words and sentences.
... Idea is that you don't need to speak a language or its grammar, but on the other hand bliss does adapt to languages.

addison: Some 5000 authorized symbols, it says.

DavidClarke: Could it be used as a kind ALT text?

duerst: Yes, except that ALT is text instead of images, and this is images as alternative of text.

addison: Is a discussion with a11y already planned?

r12a: No, and we haven't read the spec yet. But could bring it up when we meet them on Thursday.

addison: OK, I'll put it on the agenda.

[Agenda planning, lunch scheduling...]

Ruby (with Makoto) is scheduled for 13:00, so lunch needs to be arranged around that.

So lunch at noon.

<atsushi> go through html: https://lists.w3.org/Archives/Member/member-i18n-core/2019Sep/0017.html

HTML issues in tracker

<addison> https://github.com/w3c/html/issues/553

addison: Issue was closed for W3C HTML5, because it was fixed. Is it not fixed in WhatWG?
... Seems it is not fixed.

r12a: I think it should be a question, rather than a request to fix. Need to study if it is actually a good idea to have two languages on the same page.

addison: Maybe for a bi-languagal page?

DavidClarke: Seen examples of pages in Welsh and English, with short descriptions in both.
... If your prefered language is Welsh then Google could return you the Welsh description in the search result.
... But of course, if your preference is Japanese, how does it select whether to show the Welsh or the English description?

jason: Wikipedia pages are strongly in one language. It's tied to the domain name.

DavidClarke: Descriptions with and without lang attributes.

Discussion about having multiple pages vs one page with multiple languages.

Bert: There can only be one <title>

People have vague memories of a discussion about <title>, too.

DavidClarke: In UK, trend seems to be to having two pages. Haven't looked recently what government pages are like at the moment.
... If you do multiple descriptions, multiple titles might make sense, too.

r12a: Need to look at what these elements are used for. Description is mostly for search engines, isn't it?

DavidClarke: meta description could be used as extended title, or for classification.

duerst: Wanted to add an issue about the language tag "-ez", which doesn't exist, but the spec says it was "archived" and I couldn't.

<xfq_> the current clreq and jlreq documents might be this kind of multilingual document

<xfq_> currently both languages are put in the title side by side, no meta description

r12a: We could also just ignore the issue, until somebody brings it up again.

<DavidClarke> bilingual gov.uk https://www.gov.uk/government/organisations/driver-and-vehicle-licensing-agency

<addison> https://github.com/w3c/html/issues/1292#issuecomment-377298715

addison: Discussion about in <title> ^^

<addison> ... or about <meta title> with spans allowed inside

addison: mentions multiple <title>s as well.

<addison> <meta type="title" lang="...">My title is something.</meta>

addison: These are very old issues, might be good things, but is it worth the fight. Note that we didn't raise the issues ourselves.

duerst: If you don't try, it won't happen. There might just be something else that suddenly makes this possible.
... The old argument for single string title was that the title is handed by the browser to the OS to put in the title.

addison: Current API's generally allow passing language info. Not nested spans with languages, but those might be done with Unicode.

DavidClarke: My Firefox doesn't have a title bar, it has tabs.

addison: a11y: screen readers need language info, too.
... What do we resolve? Could send a question, or drop.

r12a: I'm worried that we would have to formulate a proposal to go with it.

DavidClarke: Feels right to me to ask the question. There are people affected by this. Not sure I'd want to write a proposal, but I can think about it.

<addison> ACTION: David: consider a proposal on title/meta for whatwg and report back

<trackbot> Created ACTION-831 - Consider a proposal on title/meta for whatwg and report back [on David Clarke - due 2019-09-23].

[Lunch until 13:00]

Lunch

<atsushi> scribe: atsushi

addison: asking who you are and why you here

Naoki: from Mituerinks

Kawanabe & XXX: from Shogakukan

addison: talk on ruby and accessibility

makoto: more involved in daisy text book for accessibility
... speaking with accessibility people in Japan, and learning various things from them
... (start presentation)
... introduce six presentations on ruby and hiragana

(presentation file will be shared later)

makoto: these were simple representation, but there are more complexed examples
... like kanji characters which are difficult for 99.9% Japanese to write
... some concerns for six presentations from low-vision, dyslexia, japanese as second language
... we may need to provide one html markup which can present in different way

r12a: with current ruby elements, first (hiragana representation without kanji) is not possible
... you need to have rb element

florian: two levels of problems
... chrome to whatwg spec, firefox to w3c spec + css ruby
... firefox most are possible, but need css enhancement for replacement with ruby for base text

makoto: for dyslexia, making ruby annotation colorize is also important
... there are many alternatives to ruby, like speech

florian: whatwg html spec is not great, css drafts are also not perfect
... actual blocking part is implementation
... firefox has, chrome could have implementation soon
... chrome is working on rewritting layout engine

makoto: i would like to have priolitized list of requirements
... dedicated to ruby and also accessibility
... these could be an important information for browser venders

r12a: can we get these requirement information in gap-analysis

makoto: of course

florian: thanks to Kobayashi-sensei in APL JLReq, we have note on implementation/presentation on ruby, scoped to base cases
... if we could implement all in that list, that could be a good sign
... so that list could be the good starting point for gap-analysis

r12a: which is the way to publish? WG note?

<florian> https://w3c.github.io/jlreq/docs/simple-ruby/

florian: desire is to publish this as WG note, of course we need to fix if anyone found something to be fixed before publish

addison: with better title and good text, could publish as good practice article

r12a: wondering why to target 'Note'?

florian: to state output from APL (?)
... prioritize is useful for output

makoto: nat locked into double sided ruby, and his conclusion was that there are user requirements, but considering performance he dropped that

r12a: it shall depend on way of implementation, like what firefox did

makoto: indicating pronounciation or adding another presentation

florian: just passing text is not aceptable for sppech synthesis point of view

<florian> s/acceptable for sppech/sufficient for good speech/

makoto: japanese daisy people consider only kanji presentation is better for good speech

<r12a> cf ame vs ame which have different pitch

florian: if you have kanji it is good for speech, but only ruby is not

<r12a> which is visible in kanji

r12a: w3c have tabular model, whatwg is interleave
... better to bring w3c one into whatwg
... we have a spec partly written
... ruby position, chinese ruby is easy, double sided
... question is how we can get things to go
... koji is avaiable on Thurs, will find time to talk on this with him
... spec, document, chrome implementation, how to manage all?

makoto: how about tests?

florian: yes, also number is question
... in addition to test on ruby itself, also need interaction parts
... checking cross spec interactions, better to spent time for writting tests

HTML issues

<addison> https://github.com/w3c/html/issues/269

https://github.com/w3c/html/issues/269

https://github.com/w3c/i18n-activity/issues/126

https://github.com/whatwg/html/pull/3260

https://html.spec.whatwg.org/multipage/interaction.html#input-modalities:-the-inputmode-attribute

<Bert> scribe: Bert

atsushi explains original issue. inputmode mixed script and keyboard mode.

addison: inputmode select a specific virtual keyboard. Current list in HTML5 corresponds to current virtual keyboard types. Doesn't provide for modal keyboards, e.g.
... Rather geared towards western scripts.
... Not to Asian IMEs.
... But it is just a hint.

r12a: What is our actual issue with it?

addison: It's to do with i18n, but maybe we don't actually have an issue.

r12a: Maybe we need to do some research before we close the issue. Or close this issue and make another.

RESOLUTION: close #126; further investigation or work on inputmode, e.g. with IME modes, we will consider if raised independently or if the WG decides to pursue

<atsushi> https://github.com/w3c/i18n-activity/issues/518

RESOLUTION: close #518 as a dupe

atsushi: It's a dup of what we discussed this morning.

<atsushi> https://lists.w3.org/Archives/Member/member-i18n-core/2019Sep/0024.html

<r12a> Link from Murata-san: https://1drv.ms/p/s!An5Z79wj5AZBgqUIlh2vtsqXfyjNZg?e=BdYdli

XSLT is a REC already, and the link to the Bugzilla is broken. Might as well close the issue.

Discussing i18n-ISSUE-394

addison: I'd say close all issues in Atsushi's mail [above]

RESOLUTION: close all stale issues in https://lists.w3.org/Archives/Member/member-i18n-core/2019Sep/0024.html

<addison> https://lists.w3.org/Archives/Member/member-i18n-core/2019Sep/0018.html

<atsushi> https://github.com/w3c/i18n-activity/issues/697

<atsushi> https://github.com/w3c/i18n-activity/issues/678

RESOLUTION: close issues 697 and 678

Break

<addison> NOTE: 1600-1700 meeting about HR review is moved to room "YOH", which is where PING is sitting. They have ~40 people and our room won't hold it.

Horizontal Review discussion

<addison> scribenick: addison

https://github.com/w3c/i18n-activity/wiki/i18n-Horizontal-Review-ideas

<fantasai> ScribeNick: fantasai

r12a: Thanks for coming

Horizontal Review

r12a: We invited you here today because of discussions in issue 130
... discussion about Process document

<xfq> https://github.com/w3c/w3process/issues/130

r12a: discusisons on the CSSWG charter
... various places
... Those bits of wording we're putting together are a little aspirational, espeically the Process document
... as an i18nwg
... we're constrained in the number of people we have to do reviews
... so what we wanted to do was to look at how we cna manage the large number of specs that flows thorugh w3c
... doing reviews with small number of ppl available
... some practical ideas for how to do taht in the document
... would like to ehar comments on the ideas that we have
... and if you have suggests for improvements, ways to adapt for other groups
... trying to get away from Last Call or quality control approach
... we have had only one group that gave us more than 2-3 weeks before going to CR
... that group was a11y, btw
... this is really a problem
... firstly, scheduling review is hard when you only have 2 weeks
... already doing other things, have to clear table of other things
... and also consecutive reviews makes a bigger problem
... so trying to make process of doing horizontal "review" more collaborative
... during development of the specification
... starting as if it's possible
... rather than quality control approach
... review itself only takes a week or a few
... but need to understand the technolgoy well enough to do the review
... and then follow-up period which can be a long time
... educating you about the issues, approach, working to resolve
... in some cases significant amount of reword needed by those WGs

janina: hard to track listening to tts and listen to you, rather listen to you

r12a: :D
... was planning to read it all out anyway
... First concept, self-review
... starting at FPWD but at other points during the spec
... HR groups review these, checking for areas where the WG need to think about HR issues
... HR group needs to work on review checklists
... Here talking about fpwd
... my opinion is that groups did self-review before transitioning to FPWD
... so can make changes if necessary before FPWD
... Not saying they have to as i18nwg to review FPWD
... we may, we may not
... what I'm asking is that they do a self-review, and that we review the review
... one reason for self-review is WG to internalize some issues they need to focus on
... ...
... and puts the responsibility more in their court
... rather than "we have to get this group to shout at us a bit and then we move on"
... no, it's part of developing specifications
... I'll go through these and then we can discuss them
... 2nd point, WGs appoint Horizontal Champions
... to ensure contact with HR group happens at the right points
... Not saying these people are experts in HR topic, but people who know who to contact and when to contact them
... we did this in Xerox, where we did exactly what we're talking about now for the whole company
... we then also thought was very important
... It's about giving more responsibility to WG to take on these issues
... Not expecting ppl to be experts, just to know when to contact the groups
... and to make sure that review is planned appropriately
... as they do this work, they will also absorb technical knowledge which will help work on future specs
... unsure we cna do that in w3c, but we'd like that to happen if possible
... 3rd step, WG can ask HR group anytime if they know likely to have HR-related issues
... Process doc talks about continuous review
... but we can't review every three weeks every spec
... but we can be available to answer questions
... we'd like to have only just one major review after FPWD self-reiew
... maybe that will work for some groups, maybe some other won't

addison: We're still a resource for people not just a review group
... useful to work through problems collaboratively
... and when done, useful to review that as well
... this kind of thing also gives us ability to go out and talk with community at large
... talk to language community earlier, engage to find out e.g. what quotation marks look like or whatever

r12a: can do that in parallel while you're working on your spec
... we have a notification system, if you attach label i18n-tracking, then we get notified about that issue
... can have a look at that issue and see if we can offer advice; easy way to contact us
... one problem we have with that is that we have to manually set it up for your particular repo
... hoping in the future can enable that to happen for all W3C repos
... if we do it fo rall repos automatically, they will notify us, that will work
... next step, 4th, WGs ask HR groups to have a detailed look at their work prior to CR *with plenty of time to make changes*
... should not be too late; but also shouldn't be too early
... ideal for us is to engage no less than 3 months before CR
... we have weekly meetings, might take up to a month to schedule the review
... 3 months sounds like a lot but goes fast
... many WGs know their CR dates
... if that's not the case for your WG, then ...
... think of this more like quality control than collaboration
... detailed review of the spec
... again, this is only a small part of the activity
... the activity is about collaborating together and understanding issues
... after detailed review, communicate with HR to discuss significant issues not already tracked as result of review
... we do a review, fix some things, some time may elapse, might be new issues or regressions
... need to make sure we capture those
... would be really useful if we don't have to re-review the whole spec again
... but able to say, we changed these sections, please take a look at those
... I mean the WGs as "you" here
... finally, we would prefer to see that before proceeding to CR, WGs indicate resolutions to HR issues that are raised
... indicate whehter HR group is satisfied
... then Directory checks off
... would b enice to automate that
... we do have tracker for each spec we review
... we don't close our issue until we're satsified with the wg resolution, even if wg closes their issue
... would be nice to have automation
... If a WG is unable to predict date of transition to CR
... they will need to engage with HR for major review at a point where they beliee would be effective
... based on state of the spec
... failure to predict transition is not an emergency for the HR group
... if longer journey to CR, but WG should try to engage futher
... but not in a way to overburden HR grou
... 3-month window shouldn't be fixed period, if HR is done sooner, there should be no obstacle preventing an earlier transition
... btw, 3-month window is benefitial to focus review for HR group also not just WG
... if we don't have a date in mind, we tend to give lower priority to the reivew than to other things
... one last thing on tooling, if WG sets a date in the future for a CR
... if date is less than 3 months away, can advise to send review request
... so that's our ideas!
... shoot

pes: We've had some conversations very similar ideas
... what to do if WG doesn't do these things?

r12a: ideas?

pes: We have ideas!
... without endorsing any of them
... ideas are to work with other browser vendors to not implement things if didn't go through HR review
... Another is to advise AC status of HR review, whether satisfactory, unsatisfactory, or something in the middle

tink: should I go over Process proposal?
... In terms of Process, issue 130
... the proposal at the moment is to make it clearer in the Process what is expected by wide and horizontal review
... still under discusison, but current discussion is to amend Process to put some very clear minimal expectations

<addison> https://github.com/w3c/w3process/issues/130

tink: requirements that we rely upon when this doesn't work
... minimum required when this doesn't work
... encourages what i18n proposal is about
... basically says, objetive of HR is to ensure that W3C publications are robust in terms of [HR topics]
... we encourage ppl to seek it continuously
... but then there are some key minimum rquirements
... one is that a spec that is currently in incubation, as part of its request to migrate to REC track
... it should have either complete review checklist or get review
... if not simultaneous with that, otherwise at FPWD
... The two things may be clsoe neough to be one HR review
... but should be invovlement with HR at that point
... that HR should be at least 90 days prior to CR
... doesn't have to be 90 days, doesn't mean it has to take 90 days, but is minimum expectation
... also says that the whole spec, if major revision, e.g. key features added, then HR needs to be considered for those things
... then specified a process, still under discussion
... when a WG requests review or collaboration with HR group, HR grou pneeds to acknowledge the request and indicate whether can do within time requested, or negotiate timeline
... HR group needs to be able to raise issues
... WG needs to give each issue due consideration
... either agree and accept, or if not feasible or valid, or contention, spec editors,
... both groups need to make concerted effort to move forward
... as spec next transitions , evidence of this process will be expected part of the transition request
... Director/Team will look for documented requests, responses from HR, discusisons in issues, etc.
... look at any outstanding points of contention, open issues
... so in tandom with proposal, here's a wall to put our backs against, minimum requirements
... and i18n prposal is how to do in practice

tom: Sounds like the procedure outline attempts to achieve effectiveness through process
... without necessarily ensuring that any particular specification does meet the standards set by i18n

r12a: not quite
... we have a checklist and documentation
... so before you even start working on your spec, you can read abou tthe kinds of things that would be concerned with

tom: from perspective of privacy wg, there's a dynamic that we see from tiem to time where spec is propsoed
... "here are negative consequences of your specification, you can fix them like this" and spec author says "I don't really want to so I'm not going to"
... seems like the outcome of the procedure you describe would be that the Director is aware of that disagreement, rather than there is any particular resolution of it

tink: almost, if despite best attempt by both groups
... when the transition request goes through, that issue is clearly brought to the Director's attetion, including rationale
... so that he can make determination of whether spec should advance

addison: ....

MichaelC: I think overall proposal is good, my questions are

<chaals> s/…/It is always possible to make a formal objection to the transition as well.

MichaelC: where should Process come into play and where should best practices come into play
... What happens if these things don't happen, do we have Process sticks or carrot of best practices or what?
... I think certain aspects of this more difcicult
... Having an HR champion in every group will be difficult
... but would be great if possible
... if that doesn't happen in a group, what happens?
... overall proposal very well thought through

r12a: when we say horizontal champion, we don't mean people who are in HR group, but working with us

dsinger: I like the collaborative way you're designing this
... what you wrote and not said, was too much ppl-oriented and not tooling automated
... what you said about tagging is crucial
... that HR champion should be makign sure that if an issue or PR has i18n or a11y or privacy aspect to it, issue is tagged
... not getting it righ tall the time,
... but when final review happens form that cross-functional group
... architectural problem found at Last Call is hard to fix
... real incentive to fix earlier
... I think getting insistence that REC track document are using tags and applied early
... key way to make this incremental and workable
... also would like when transition, there is summary traffic lights from each HR group
... three-color scheme, green - it's fine no problem go ahead
... yellow, some concers about it, please look
... red, this we don't think document should be published in current form
... formal objection
... if AC and Director saw that, much easier ofr us to take HR and cross-functional review more effective
... If three yellow flags, look more quesitoningly at the spec
... This is going in the right direction, but need help with tooling

Judy: Overall good, but I suspect some parts of what yu described, r12a, might be optimized for i18n and some may not
... to some that are not
... one concern I have is not every HR group may want or be able to enage early in every instance
... and therefore I'm concerned that becomes an absolute expectation
... so great to encourage that, but don't know if that's something that works across the board
... second is ditto on Michael's concern about embedded HR champions
... I think it's great when it can happen, but do have some scalability concern
... based on what we've tried in the past
... so great, but may not be possible, even when designating someone within a group
... also possibility of misunderstanding in a group
... also if someone willing to self-designate as champion on an issue
... agrees to liaise that issue
... may or may not do it effectively
... if effective, can catch architectural disconnects early on
... maybe they give impresison that there is sufficient liaison
... worry about appearance of liaison but not actually happening sufficiently
... might be a helpful mode, would be careful about over-relying on it
... third thing, from some discussions Team-side
... I share the perspective that improved tooling is essential
... I would really like to see that as a stronger piece of this proposal
... particularly as we move towards a more agile approach
... capturing granular changes like feature changes
... requesting changes discretely
... please let us know if we broke osmehting

r12a: about champions not functioning correctly, expect that
... but better than what it is
... if someone does a good job or half good job, better than nothing

Judy: we tried this with a11y early on, and in some cases was more harmful than not
... so be careful
... that champion needs to be well plugged-in to the relevant center of expertise
... and not give impression than they can give the check off

<Zakim> cwilso, you wanted to describe tie-in to incubations

Judy: we have used this model and it failed significantly on multiple specifications

cwilso: Hi, Chris Wilson, Google, co-chair WICG and Immersive Web WG
... Horizontal champions in a WG is going to be really hard to get work
... really hard to get it to work
... large group like CSS, might want to appoint someone
... but generally going to need to make sure chairs and editors do that
... everyone needs to do it

r12a: if chair or editor is the person?

cwilso: Pushing onto a role, can be improtant or not
... making sure chairs and editors take it on as a responsibiltiy, more likely to happen
... ties with previous conversation with PRivacy
... emphasis on tooling, totally agree with
... more you can give developers of the standards the tools, principles, training to do this work themselves
... have it be part of the process
... that's more effective
... particularly education
... not replacement for engaging with HR groups, but will help be more productive
... side comment from WICG
... In process of migrating to WG, we request HR, particularly self-review
... so triggers even before FPWD
... ask for a11y review, maybe ask for help on that
... even earlier might be a good plan to have that conversation
... not blanket true for all HR, but for some is appropriate

r12a: didn't think we should do HR at that stage, mainly because we don't have bandwidth to do it

cwilso: My concern was be careful what you ask for

r12a: the self-review seemed a good compromise, be prompted where to ask for help

cwilso: as a chair...
... had a really illuminating conversation in TAG about a11y and what it might mean in WebXR

<Zakim> weiler, you wanted to respond to Leonie re: "best attempt by both groups" and to comment on "review champions"

cwilso: not that I've ignored a11y in my career but havne't thought about it in that way, and hard to capture sometimes

weiler: Two things
... firs tis about review champions
... IETF has "document shepherd" whose job is to push the document through the process
... when I hear you talk about HR champions, sounds like micro-managing
... unless you're saying that's the contact person

r12a: yes

weiler: need tooling
... tink said, if can't reach consensus, and groups have made best effort
... I've seen in PING, groups don't make a good effort
... I've seen firm positions and not much effort at consensus
... often because review requested too late...

tink: how is that different from other disagreement?

weiler: I think because we're an outside group
... lack of consensus within WG is more likely to get resolved

tink: So in cases like that, we'd trust the Director to look at the issue and say "not acceptable"

dsinger: Wg writes the transition request, so it can downplay the disagreement

addison: If you feel that the WG is not listneing to you
... and historically there's this issue
... where we had to speak up about it
... it's rare in our case, we usually do a good job of workign out misunderstnadings
... but if group says nevermind, and we say we minde

dbaron: Bunch of what TAG does these days is design review which is similar to HR

<dbaron> https://w3ctag.github.io/explainers

dbaron: we get about 2 review requests per week
... one thing we found very helpful is asking for explainers
... we want not just a spec, but a document that says why it's doing what it's doing, how it helps users
... in many cases we're only reviewing the explainer and not the spec

<weiler> [perhaps docs should be self-explaining?]

dbaron: because we don't have bandwidth to read eveyr spec in W3C
... sometimes we do ask for more info than initially in the explainer
... but seems to work well
... Different TAG members have different opinions
... Some ppl think explainer should be in document, some that it shoudl be separate; I don't care much personally
... we've started aggressively using labels to track these things
... one thing we started doing recently is labelling them as "Resolution Satisfied" "resolution unsatisfied" "resolution timed-out"
... In many cases we asked some questions, and two month later no reply
... We're trying, more than other groups, to do review at an early stage in the process
... we're doing it early enough in the process that ppl might abandon work on the project
... in case where questions weren't answered, we assume they stopped working on it
... and in case continuing work, we hope they'd get back to us

<Zakim> hadleybeeman, you wanted to comment on explainers and why they help us

hadleybeeman: Worth saying, explainer is not just summary the spec, but thinking behind the spec
... we look at their explainer, shows alternatives they considered and why decided not to pursue
... we also are looking for how this particular or feature will interact with others
... useful to see that author has thought through implications for other areas of work
... so explainer is thinking, how I ended up with this as a spec
... contextual information vs longer technical spec
... thinking of conversations I've had with colleagues about i18n and a11y
... you have asked parallel types of quesitons
... are you aware that this has effects for another type of user, are you aware this increase fingerprinting surface?
... other questions can put into a template, save you a lot of work at beginning of reviews

r12a: can we get your explainers you get?

dbaron: you can set up a bot to watch our repo?

martin: Can TAG forward us issues?

Dan: You can look at our repo. All of our review requests come in our design review repo
... we're struggling to keep up with this
... I really like idea of dashboard, btw
... where we track how different HR reviews have taken place
... one problem we have right now is

<Yves> https://github.com/w3ctag/w3ctag.github.io/blob/master/explainers.md

Dan: we're not getting enough, although we're swamped with reviews, we're not getting enough requests from W3C WGs
... good case study with WebXR
... WebXR put review request, TAG came back with feedback, good discussion
... Just attended the WG meeting, feedback was resolved, and we had good feedback from editors andchairs
... They wrote a great explainer, wrote a great checklist on securit and privacy
... We hope most W3C WGs can do
... Not because we want to have power, but because we want to help the W3C WGs
... But we do have an explainer explainer, which explains how to write an explainer

<dbaron> https://w3ctag.github.io/explainers

Dan: We have run into problem where some people think that the explainer is only for the TAG review
... and we're very explicit that the explainer is for you, and to help you document what your thing is for the developers you're building for
... Not for the TAG only

tink: Question about tooling
... i18n uses very useful GH labelling system
... thoughts about using that or something similar?
... from WG co-chair with lots of spec, useful for getting incremental flow of getting review and help

<Zakim> MichaelC, you wanted to suggest I interpret horizontal champion role as procedural

MichaelC: we've been talking about that, and expectation of somebody with experties

Janina: I think that status dashboard would be very valuable
... Tail end of process is improtant
... Are our comments incorporated, we don't know
... If we have some way discoverable in dash board, that would be sueful

<addison> ?

Janina: if Director is aware, that's important
... strong +1 to explainers
... especially for a11y, if there is no explanation in plain English what this API does
... Does group even now if they satisfied their goals? How can they tell?

MichaelC: back to HR champion, my intepretation was that is was procedural that it would make sure that HR was done and outreach happened at the right time
... remind WG that they have to do this
... chair or editor could play that role, but doesn't have to be chair or editor, sometimes useful to not be

<weiler> [IETF's description of the document shepherd: https://tools.ietf.org/html/rfc4858]

MichaelC: goal is just to make sure the review happen, not to be the expert doing the review
... I think that might address some concerns that were raised about

r12a: could be editor could eanybody, just a concept
... issue is WG too busy doing their work, forget about HR until last minut

<Zakim> chaals, you wanted to ask for usable change tracking to be emphasised more

r12a: just having somebody who takes responsibility for keeping this in mind

chaals: On the having a champion, editors are often quite experienced, chairs are often experienced
... we should push W3C to help chairs get better at doing this
... chairs to understand process and get good at it
... there are different magic points for review for different groups
... Privacy, very early in design
... and very valuable to be very early in the thing
... like TAG saying this is wrong way to fit in with other things
... for large specs i18n and a11y issues, can be easily localized
... can work on them later, as features going in
... DID WG expects a feature freeze about 6 months before CR
... it's a roughly appropriate point to look at and see which bits worth tracking
... consequent request is we should push really hard for readable human-friendly change logs
... what actually changed?
... a GitHub record of every commit is totally useless for a review request
... groups that come with such things, should be told to go away and build a change log

dsinger: tooling can help

chaals, not really a substitiute/tooling should help a lot. But we can and should work out the things people need to do, without *needing* tools to make it possible - they make it more efficient so more effective not really a substitute

Judy: combining these
... going back to status dashboard

<weiler> [change logs are most useful when manually (and thoughtfully) generated]

Judy: tie to granular tooling
... review whole spec
... some team side discussion
... any new feature commit should have its own very succinct explainer, this is the meaning or intention of the feature
... tying dashboard with feature with explainer could help things alot
... say for the record, a lot of the discussion leading to this meeting
... was listed under a bad title
... would like to relabel under a more positive title
... goal is to not have a delay due to HR

plh: Wrt tooling, want to fix sooner rather than later
... what I can help, would be welcome
... NOth everything can be resolved by tooling
... Changelog e.g. is not something that can be automatically generated
... payments group labels edits substantive/editorial, for example
... can go through commits to see ones that are not substantial
... sometimes not good enough
... Ralph and I sit down to look at transition requests
... 30min to several days / week
... we have to figure out e.g. was there a horizontal review, how long, sometimes we get it right sometimes get it wrong

<Zakim> dsinger, you wanted to mention standard tags for ‘degree of change’

plh: so ehlping to understand status would be veyr helpful in our day-to-day work as well

dsinger: putting together what plh and chaals said
... I get automated reports
... not very helpful
... want to know is this adding a new feature, is this clean up, is this fixing a bug, etc.
... chairs can take that and summarize what happend since last review
... won't get done or won't get done well
... small amount of tooling can make a major difference

r12a: If we're doing review of incremental features, I don't want to be reading GH change commits
... I want to read the document, be able to scroll up/down and see the context
... if there was a way to get labels into document itself, and show hwich part of document is major change or describe why that feature was added by clicking ab utton... I don't know
... that would be more useful for a review group than looking through code

weiler: change log + diff tool?

<chaals> fantasai: HTMLdiff can get pretty hard to read over a solid body of changes large and small. Gettgin usable changelogs is hard- we do it manually in CSS, and they are more broad as we make big changes early on, later tehre are more details.

<chaals> … don't know of a way to get something useful that is automated.

MichaelC: We do feature development in branches, and do squash merge for the feature
... and write a changelog-appropriate entry
... but not work for everybody

<chaals> [I don't know of a changelog that is generated by tools and is helpful]

addison: a lot of ideas here, would be more heavyweight for WGs if we did all of these things
... I struggle to get just on a regular basis good checkpointing and acknowledgement of our system
... given limitations of our tooling, it's reasonable
... we have to manually track after the fact
... major work in TPAC is going through all of our open issues
... I'm very concerned about getting to a point where we can have reasonable handoffs and reasonably clean reviews
... work through issues with WGs, because WGs want to get to done, and we want them to get to done in an effective way
... we're past time, btw

Judy: what are you wanting for outcomes?

r12a: we need to pull out various suggestions and circulate to all the groups
... wasn't looking to work everything out here, just wanted to share ideas, and think we've been doing that successfully

chaals: Suggest sharing to chairs, and framing as open discussion
... please, as a group of chairs, provide a horizontal review of this horizontal review propsoal

dsinger: I'd like to work out next steps
... don't want to keep talking forever, make some concrete improvements in the area

plh: next steps, some tooling that needs to be done

<chaals> fantaasai: we need te checklists all in one place, and it needs to be clear this is part of each transition.

<r12a> need a central location for self-review checklists etc so that people can fihd it

<chaals> … so the transition checklist needs to mention them at each point.

<chaals> … and I want actual checkboxes, rather than having to copy and paste stuff from place to place.

<chaals> … and there is a lot of material there. Don't stick it at the bottom of every spec.

r12a: I showed a process that we want to use in i18n and fits our resource levels
... you might come up with differnet processes
... shoudl we try to homogenize?
... atm just need to get things done, but woul dbe good to have an overarchign framework

Judy: think your model has a lot of good stuff in it
... one concern is that good encouragements not become absolutes for groups that would not benefit
... but how do we make sure something happens and there's some accountability
... when tink was working through process, think it assumes some of those as absolutes so may be wrong
... so need a process that gives multiple paths towards the same goals, but ensures that there's some accountablity to have the right outcome
... supported by really good tooling

chaals: I don't think that we will homogenize completely
... let's have each group come up with how they want to work
... and then figure out commonality
... as editor/chair, want some consolidation
... much easier
... so let's make these lists and see how far apart they are

tink: came up when I did HR review of HR for the Ab
... found there's hardly any commonality among HR groups

plh: 3 components of HR
... tracking labels pinging each other, tooling can help
... 2nd component is asking for wide review
... I tell Team Contacts where to send email / file issue
... sometimes doesn't get done, because WGs forget
... if there's one point to send people, much more likely to happen
... 3rd component is actual review and engagement itself
... those are 3 main components that we need to improve

dsinger: not hearing any push back that we have sets of standard labels
... that when you go to FPWD they are in your repo
... HR groups will get issues tagged with their labels
... maybe automatic reports can filter by lables
... seems easy to do

<Zakim> Judy, you wanted to suggest a few other potential common elements

plh: i18n-tracker we can do for all repositories that we track

Judy: other elements of commonality that are possible
... so let's discuss and find
... I think idea of self-review, having materials to facilitate self-review
... all reviews should have this

<chaals> [chair training]

Judy: supports scalability and efficient use of resources
... and having a clear contact point to follow up with once groups think they're finished with self review and want to shout out for help
... make that as homogenized and centralized as possible

fantasai: +1 to that, I can never remember which mailing list to ask for a11y review

r12a: so this far exceeded my expectations in temrs of ppl who showed up and engagement
... quite big and quite important, but things won't move forward if we just go away and continue as usual
... need more regular communication among the groups
... how do we do that?

christine: Question, one of the things I don't think we've discussed, survey
... sometimes when we're doing PING reviews, the different WGs ask for issue sto be raised in their repository
... which makes sense
... also want to keep track of them ourselves
... so we discussed doing mirrored issues
... you can do this ovely dashboard thing if it's all within the same repo

chaals: plh just promised to duplicate the i18n tools for you

r12a: you create one tracking issue, and it links to the actual discussion in the WG repo

addison: It might be useful for us to do a demo of what we do at some point (not now)
... Also useful to see how other groups operate

plh: a11y is also quite advanced

addison: this is a closed circle, behooves us to think about what chairs and WGs reactions will be
... know that some participate in no-horizontal groups, but most people here are HR
... so also listen to their concerns
... I haven't made any progress in changing their behavior

MichaelC: I was made aware of this meeitng by team-horizonta
... if we set up public-horizontal
... invite chairs, maybe that's good to continue discussion

Judy: ...

r12a: need some way to congeal and continue

dsinger: Process CG willing to host discussions

plh: Chaals mentioned chair training, happy to do it if I know what to train them for
... All I can say to Team contacts today is to point at /Guide
... so proper chair training session on HR, something that won't change 6 months later

chaals: point people at /Guide which doesn't say what to do
... then tell them to edit to say what to do

<xfq> https://github.com/w3c/Guide

fantasai: There's a lot of documentation on w3.org, hard to be aware of what exists

r12a: all done?

Meeting closed.

<chaals1> [plaplapla]

<addison> Meeting: Internationalization WG 2019 TPAC

<addison> Chair: Addison Phillips

- DRAFT -

TPAC 2019 Internationalization (I18N) WG

16 Sep 2019

Attendees

Contents