<scribe> scribenick: Ralph

Michael: security and privacy aren't represented among us but we should include it in our conversation
... A11Y and I18N weren't marketed in this morning's [TAG] session
... on tools
... in APA WG our tooling isn't as good as we'd like
... we look at /TR weekly to see what's been published in the past week
... every FPWD gets a tag in our repo
... and we discuss in the WG whether it is interesting for us to review
... if it is, we assign someone to review
... if not, we mark it as not needing a11y review
... future WDs then won't get review (this might be a bug)
... when the reviewer proposes comments they get WG review and possibly modification before sending

R12a: how do you record a prospective comment?

Michael: an email is sent with a draft
... so it's in our email archive
... the wiki will have a pointer to the draft
... there's no working draft of the comments

Janina: at a previous rechartering the WG decided to run a formal consensus process before sending our comments to the destination group
... I use a standardized subject line for those emails
... using a call for consensus template
... at the end of the CfC window there's a decision recorded in the same mail thread
... and the comment is sent with a pointer to the decision in the archive so that it is clear the comment is a WG consensus comment

Michael: for some FPWDs we discover that this process has not completed fast enough before the WD gets to CR
... we do try to follow the destination WG's preference for filing comments

r12a: I18N prefers to file its comments in the WG's github

Michael: we won't close our comment until we've received a reply that satisfies us
... a comment will remain open if we never receive a comment
... we have a bunch of those
... sometimes we're asked to explain our use case
... and some questions we decide are really good and we have to think about them

Janina: those sometimes lead to joint WG meetings

Michael: in our wiki or github I will always include pointers to the resolution(s)

r12a: I'd like to see your wiki

<addison> www.org/wai/apa/wiki

<addison> https://www.w3.org/WAI/APA/wiki/Main_Page

https://www.w3.org/WAI/APA/wiki/Main_Page

<addison> (caps matter)

Michael: see "spec review category" on that page
... we use the wiki's category feature

https://www.w3.org/WAI/APA/wiki/Category:Technologies

Michael: there's a list of specs we aren't yet tracking and need to discuss in a telecon
... a category for things in review
... a category for reviews awaiting a reply
... we maintain a history of everything that has happened in reviewing a given spec

Addison: my frustration is that the Process doesn't involve us
... as a chair I monitor two or three places to see what new specs have been created
... we go through a process of tracking specifications
... whether we've reviewed them or not
... we still find some specs that reach CR with no review request
... we find some specs that ask for a transition despite having open comments
... Richard and I have to chase and nag people
... we do reasonably well but it's not satisfying to have to be in this position constantly
... instead of being the friendly, supportive WG we sometimes have to write unfriendly emails at transition times

r12a: I'm not sure we're doing well
... it's sometimes painful to resolve things

Michael: we'd been considering a transition where we had a comment open for years and the WG had forgotten about it
... we appeared as the bad guys when we pointed out that they hadnt answered us

Addision: the big problem comes when review requests don't come in the right cadence
... it's a particularly uncomfortable position for us to appear to have our foot in the door when a WG asks for a transition

<addison> https://github.com/w3c/i18n-activity/projects/1

Addision: the i18n process ...
... we use the github 'card' feature
... so we have multiple categories
... we make an issue for every spec, containing the due date if there is one; the publication date for a FPWD
... states 'requested', 'in review', 'review completed', ...

r12a: when we move a card from one category to another everyone sees the update in realtime

Addision: everything becomes an issue in our i18n github
... with a great deal of text and other structure

<r12a> https://github.com/w3c/i18n-activity/issues/new

Addision: we have a template
... that includes instructions for the reviewer

<scribe> ... new issues get a 'pending' label

<addison> http://w3c.github.io/i18n-activity/reviews/

UNKNOWN_SPEAKER: we have a separate tool for tracking individual comments
... to look by spec in date order
... to find comments that are not yet closed
... our consensus process is much like a11y
... an 'approved' comment in our telecon removes the 'pending' label and creates an issue in the other WG's repo with an i18n label

r12a: when we create an issue in the CSS repo we add an i18n-comment label
... and expect a response before the next transition

<addison> Example of an issue in *their* repo: https://github.com/w3c/input-events/issues/72

r12a: the 'i18n-tracking' label is used by anyone in our WG to send us notifications

<addison> Example of the same issue in our repo (after we reviewed it, of course); https://github.com/w3c/i18n-activity/issues/211

r12a: anyone in CSS WG can put the i18n-tracking label on an issue to notify us that they believe it should have our review

Michael: you need special permission to add labels to another WG's repo

r12a: yes, though any Team member has this permission

Michael: so you see the discussion proceed in their repo

<r12a> http://w3c.github.io/i18n-activity/reviews/

Addision: yes, and when they feel they are done we mark it "close?" and discuss
... eventually we'll mark it "closed"

r12a: we can filter so that prior to our meetings we can fetch a list of issues that are candidates for closing
... in our page we can click on the issue title and get to the issue in their repo

Michael: any issues with groups not using GitHub?

r12a: hasn't been a problem; if they ask for our comment in email we'll ask if we can file in GH and so far none have refused

Addision: we also produce a daily digest so people don't have to track issues individually

r12a: that digest includes everything we're tracking
... actually there are two: one tells us about activity in our tracker repo and the other tells us about activity in the other WGs we're following

Michael: your process for managing the maturity of comments is similar to ours, just different tooling

Janina: before everyone was on GH

r12a: we use the GH API to pull reports

Michael: I'd like us to be able to share those tidbits

r12a: you could take our pages and tweak the data and it should work

Janina: that might be worth trying
... I like the idea of the other group being able to see our activity

Michael: I come from the [old] days when comments were filed in email

Addision: I can show you my scars from those days

r12a: the big problem with email threads comes when people start subthreads and you get spaghetti

Addision: there can still be a long discussion on a GH issue but they tend to stay more or less on target
... and if not, at least the spaghetti is in their repo
... and we can still decide if/when we're comfortable

r12a: other i18n labels include those subgroups who are interested in Chinese, Arabic, ...
... these subgroups get their own notifications
... and get digests as well
... they have their own repos
... with notifications to changes in their issues
... we apply an i18n-alreq label to any issue in any repo that should be exposed to the Arabic Language tf
... so they get notifications from many places

Michael: the similarity in our processes includes getting group consensus on comments [before sending]
... what other challenges and frustrations are common?
... algorithmic specs; written without explanation of what they do

r12a: we have the same challenge

Ralph: canonical recent example?

Janina: the API specs particularly

Michael: sometimes our comment is "please explain what this spec does"
... in the previous breakout on evergreen standards we noted the problem of knowing when the right point to [start] review is
... one of our categories is 'spec review deferred'
... I create an action on myself due in t+6mos to check again

r12a: we recently started using a 'recycle' label to indicate issues that we have closed but need to come back to later

Michael: sometimes comments come so late that they won't be addressed until the next version

Addision: there will be a moment when you'll need to Formally Object
... I try to avoid that

Michael: right; it doesn't make us friends and I worry that it may compromise our future friendly relationship

r12a: another strategy we use to try to avoid this is the self-review checklist

Michael: yep; the i18n one seems to be fairly complete and mature

r12a: we're not satisfied that ours is either complete or mature

Michael: but how has it worked for you?

Addision: it can be helpful, especially at FPWD to get people to start thinking
... I looked at all the issues we've raised and collected them in a document for consideration as potential checklist items
... Richard generated a tool to paste a checklist into a GH issue
... this doesn't necessearily cover all the possible checklist entries

David: it's helpful for us to get people to think about things they might not have thought of before

r12a: we don't have much experience with groups completing our checklist yet
... we haven't aggressively pushed it

Addison: there are challenges with checklists
... we understand the intentionality but sometimes people think they don't have any natural-language text
... and we say "well, what about these ...?"

David: and there's the possibility that the group may think an area doesn't apply to their spec when it actually does

<addison> https://w3c.github.io/bp-i18n-specdev/

r12a: we might ask "does your spec have any natural language text?" and direct them to a part of the checklist
... similarly for dates

Ralph: and Lukasz described the TAG's self-review security checklist as a starting point but not the full task
... @@GH transition tracking

Michael: we have limited evidence of utility of the self-review checklists
... do we think they are worthwhile?

r12a: you can point them to specific sections for their self-review
... and you can use it to remind yourself
... it also helps bring new i18n staff up to speed on how we're reviewing specs

Addision: it's important to have a written record of what you look for in review
... and as we review things we often come up with new things we want to note

Michael: perhaps the appropriate use is a checklist, not necessarily for self-review?

r12a: it's still useful to ask people to self review

Michael: I'd like to have a cohesive story that we can sell together

Janina: we may need to send something more high-level to groups and have our own more detailed list

Ralph: if you suspect they may have answered a self-review question incorrectly, you can still look at it in more detail
... I will remind Lukasz that for his new checklist it would be good to have it GH-based so similar tooling can track it

r12a: it's now much easier to take the i18n tooling and reuse it for a11y

Michael: in APA we're finding we want an Accessibility Impact section more often
... sometimes there's an implementation gotcha that we want the spec to note

Janina: an example is the WebAuth WG
... we had a wonderful discussion with them a couple of TPACs ago
... we all agreed that a11y didn't have an issue with the spec
... we all also agreed that when the spec is implemented there are things that devices may get wrong
... a 'Considerations' section is one place to note those things for the implementors
... also other cases where something could be mis-implemented
... sometimes a WG will say that their spec doesn't have a UI so it won't have a11y issues
... but there are still things they should think about

r12a: the TAG were asking for explainers
... part of our problem is that we have to learn about a technology quickly

Janina: we spoke about that in the last breakout too

Michael: in the Architecture and Technology group we want to orchestrate a regular conversation on horizontal review

r12a: plus Ted and Shimono-san and Bert

<addison> for the record, I'm generally not in favor of "penalty boxes" for I18N considerations, although the occasional health warning is called for. I recognize that Janina's comments are completely valid

This is scribe.perl Revision: 1.154  of Date: 2018/09/25 16:35:56  
Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/

Guessing input format: Irssi_ISO8601_Log_Text_Format (score 1.00)

Succeeded: s/DavidClark/DavidClarke/
Succeeded: s/teh/the/
Default Present: addison, David, Clarke, r12a, swick, michael, david_clarke, MichaelCooper, JaninaSajka, RalphSwick, RichardIshida
Present: addison David Clarke r12a swick michael david_clarke MichaelCooper JaninaSajka RalphSwick RichardIshida AddisonPhilips DavidClarke
Found ScribeNick: Ralph
Inferring Scribes: Ralph

WARNING: No "Topic:" lines found.


WARNING: No meeting chair found!
You should specify the meeting chair like this:
<dbooth> Chair: dbooth


WARNING: No date found!  Assuming today.  (Hint: Specify
the W3C IRC log URL, and the date will be determined from that.)
Or specify the date like this:
<dbooth> Date: 12 Sep 2002

People with action items: 

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


WARNING: IRC log location not specified!  (You can ignore this 
warning if you do not want the generated minutes to contain 
a link to the original IRC log.)