Meeting minutes
Slideset: https://
Slideset: https://
PLH: We try to sit down with chairs of horizontal groups at TPAC. Didn't manage last year :(
… I have some slides, and lets chat.
PLH: why do we care? We have a vision, of the web being good for everyone, safe, and one thing.
… that drives horizontal review to try and make those things true
Slideset: https://
PLH: we have two documents talking about horizontal review. The Process says "wide review", but it is understaood that our specific ideas of Horizontal review are a required part of that, as described in the /Guide
… We have been tracking a lot of issues to try and ensure we don't forget them
… Each group manages issues internally according to their processes, but it is all visible and trackable.
<Bert> How to do Wide Review
PLH: This also works on top of whatwg repos, and is based on standard labels.
… We have different views, to see what the status is for any given spec, across different types of horizontal review.
<xfq> https://
PLH: Different groups can mark some issue as relevant to horizontal review.
<simone> Horizontal dashboard
[Slide: discussion]
PLH: Are we missing anything that we need to make this work well? What are the pain points, are there ways to smooth them?
… We have principles and increasing expectations for them to be followed. We don't expect all groups to start as experts in all areas, but we do try to help them learn.
PLH: We review W3C specifications, some groups look beyond W3C specs (e.g. TAG, i18n, ...)
… Should we provide more effort for specifications that are produced outside W3C, despite the resource constraints we already suffer from?
… You are also welcome to bring up any other topics.
matatk: (TAG member, co-chair of Accessible Platform Architectures group). Speaking for APA we really love the github process, and documentation from i18n.
… We're using and developing a CLI front-end for this, and I want to thank Bert for helping with some programming.
… Historically we use a wiki to track all the reviews we have done of a spec, that in some cases goes back decades of history. Now the spec labels are super-helpful, so we shouldn't need to do the extra admin in the wiki
… except when a spec changes its name, we lose that history, and the spec labels don't handle that.
PLH: We don't do that, but the information needed exists. Note I cannot track review requests yet. We can track issues, but I would like to track requests.
matatk: couldn't we search issues with the relevant label? Can we just stick with the initial label?
jyasskin: You can rename the label
PLH: You have specs that merge, or split, as well as just re-naming
… that will be harder but we will see how we can build on the information, because at least we have it.
Roy: We have an annual report on how much we review, so making it easier to track that, and include times, would help
PLH: Issues have timestamps.
Roy: We don't have a principle to provide annual report. Some documents have review that go over more than one year.
… Would be nice to have more statistical reporting available. Wondering also if other groups want to be able to do that.
addison: Sometimes we do that but we don't have it as a formal procedure. We have tooling in our own review radar that we can use to get that. It can be interesting to look backwards, e.g. fnding out a spec hasn't been reviewed for years.
… There is also a pre-github history, and we have less insight into that.
<Zakim> jyasskin, you wanted to cover 1) Reviewing at FPWD or charter source docs, not just CR? 2) Distinguishing individual reviews from group-consensus reviews?
jyasskin: painpoints: If you file an issue on a repo, as a random community person you need an authorised person to add a tracker label.
… Would be nice if we can change that.
PLH: got a request to create a triage team, giving a wider group access to manage that. I will punish your good deed by invovling you in the work of improving it.
<Jennie_Delisi> * There is a person asking to be in queue who is not on IRC: Christine Runnegar
jyasskin: In TAG and PING, we need somewhere that a review can be written down before the group has consensus on the content.
… would be good for someone to write a review from that perspective that won't be confused with the group's formal review.
jyasskin: Officially wide review is required before candidate rec. If you do them around that point they might be shipped, and it is hard to change by then. SHould we be getting wide review earlier?.
<Zakim> chaals, you wanted to react to jyasskin
<Chuck> chaals: You have to have wide review to get to cnadidate rec, but you are encouraged to go through wide review for changes.
<Chuck> chaals: We want to know when you've made some substantial change, we'd like to look at it when you have shaken it into the spec but before it gets into business process.
<Chuck> chaals: This is ... chairs apply process that is laid out before them.
<Zakim> simone, you wanted to react to chaals
<Zakim> xfq, you wanted to talk about spec renaming
simone: We have in the FedID charter that we will call for horizontal review at FPWD, and we publish Working Drafts and look for horizontal review. So it is managed in theory...
xfq: (Working on i18n). Regarding spec renaming, if the repo changes, we use a "moved" label to help carry the info across (with some manual extra work)
christine: (Ping cochair) Thank you to all of the work done by Team to facilitate horizontal reviews. It can be painful, but it helps a lot.
<jyasskin> +1000
christine: Horizontal review is key to W3C standards' quality, and there are not a lot of us. Think we should be focusing on getting more commitment across the community, to help do the work.
… As well as documenting reviews each year, would be nice to document the improvements that are due to responses to horizontal review
<matatk> +1 thank you Team :-)
christine: Yes, we should have a robust discussion about reviewing all standards, not just the new ones that are coming through.
<Zakim> addison, you wanted to respond to jyasskin about 'pending' and timing
addison: (i18n chair). In our group we use a pending label to allow people to record comments, and keep them to the WG before we put them into the relevant spec group's repo. That way we can track what we do internally and keep a record. That is an approach to consider.
addison: Totatlly agree that early review is better. For years the challenge has been to get the review requests, but I would love to have more proactive calls for review from as soon as people have sketched a design, rather than assuming it's fine and waiting until the spec is baked before asking us when they can't realistically respond
… effectively.
… So far, the issue has been just getting review calls, and getting responses that we think are reasonable.
<matatk> Some docs from i18n on wide review: https://
janina: (APA co-chair). I am happy we have CGs, but I am starting to be concerned that there is no real review on their reports. If they move to WG we can pick up the work there. We don't review Notes or drafts, in general. But I was terrified when I learned a government was going to point to a CG report in a regulation - for me that is a bad
… precedent, and I don't know if we should be more strict about what we say about a CG report without horizontal review.
PLH: Short answer is "we don't want to have that happen, at all".
<xfq> how i18n do reviews: https://
PLH: We had a session on CG processes, we have people working on this question in W3C. We don't encourage CGs to ask for horizontal review - we could encourage more of it if you are ready to receive more review requests...
Janina: I understand the problem there...
<Zakim> matatk, you wanted to ask about change log best practices
<matatk> thanks xfq, that's the doc I was referring to - may go some way to answer jyasskin's query
matatk: One thing we find helpful is when a spec, especially a long-running one, has a human-written curated changelog (not just a pointer to github commits).
… These are so helpful.
[chaals: +1000 to matatk]
<xfq> yeah, CSS does a good job of recording changes
matatk: This isn't a coding/tooling issue, we really want some proper information that is curated. Maybe we should have some best practices about clarifying changes and writing useful changelogs.
<plh> w3c/
PLH: Issue 107 talks about promoting commit messaging conventions. That can start to help.
… There is educating editors, which is challenging, people can use github labels to help. We don't require good changelogs, some groups do it. We could do more to encourage that to simplify the life of horizontal groups.
addison: no horizontal meeting in Seville, but you and I talked to PLH there. We made some changes to transition request behaviour then, which I think are important to all horizontals.
… Things would go through CR with open horizontal issues, in return for a commitment to closing issues effectively. I thikn that is a good hygiene step.
… This also makes PLH's job easier too.
addison: How do we get earlier review requests and have friendly relationships to WGs, insterad of being seen as a drag on productivity. We can be seen as being a blocker to get through, rather than a support to get better.
vlad: Want to reiterate how useful the reviews were for us on Incremental Font Transfer spec. We started them when we produced FPWD, and the comments motivated us to redesign substantially
… and submitted that again, to positive review comments. The reviews uncovered issues that none of the group members had recognised, which led to substantial changes, that made the technology we produced much more web-friendly. If we had waited to the end of the process, the changes would not have happened and we would just have published
… something that wasn't nearly as good.
<Zakim> matatk, you wanted to ask about issue names/linking for tracker issues
matatk: Minor quality of life thing, for issues where there are issues across trackers, called something like accessibility review - makes great sense to the source repository, but since that's most of what we do it is not a helpul naming in our group.
… Do issue titles have to be the same, or can we rename them?
PLH: Rename away - the link between the two issues is the key, not the name.
matatk: Oh, Hooray!
PLH: Credit to i18n for getting that right. It will re-use the title automatically, but so long as you don't change the first link in the comment, you can change the title happily.
matatk: We are now out of excuses to be slow and will become more productive and efficient with fewer resources and more work to do.
PLH: Early review is always good. There are always groups we forget, until late. The fact is, when the groups release FPWD, that is a signal to know that something new is coming up.
… That can be a way to catch things early.
… We send those signals through tools, and can tailor them to send a singing telegram if that's what you need.
… Same thing with charters, and when you should look at a charter that is being developed.
… Getting a lot fo signals brings up a new set of issues about triage...
<Zakim> chaals, you wanted to react to plh
chaals: It's good to be sending those signals. It's important the chairs and editors understand the process.
chaals: fpwd's vary in maturity across working groups. It's not the horizontal review groups that drive that.
reillyg: (device sensor co-chair). I don't know if there is a process or expectation change, but I like the idea of a review before a group adopts something new as a deliverable in a charter.
… It's better than getting the review in form of an formal objection to a charter proposal.
… And less adversarial.
[+100]
Janina: Tooling issue, we have task forces, one joint with Accessible Guidelines WG which is COGA - people with neurodiversity. They REALLY struggle with github and how to make it work, and they are heavily reliant on google docs at the moment. They like the information you can get from github, but find it incredibly challenging and expensive to
… work with github.
matatk: With our dashboards we can give clear overviews, but there are real accessibility problems for people trying to deal with some of the interfaces we expect people to use.
<simone> CG/WG process
simone: When we are going to adopt a CG deliverable, there was an experimental process. We are trying to do that with FedID. We got an objection against adopting CG work. We had internal discussion about asking for review before adoption, but would be helpful to get more discussion earlier, in a somewhat systematic way.
PLH: Thank you all, I would still like feedback on going beyond W3C specifications.
<simone> +1 to go beyond
PLH: I will never be thankful enough for all the work that Horizontal review produces and the value it gives us. Now we are late, so...
[Adjourned]