<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.)[End of scribe.perl diagnostic output]