Meeting minutes
W3C 2020: Living Standards and Reviews
plh: Welcome everyone, this is presentation on the new W3C process and horizontal reviews
… there was nothing wrong with the old process
… the recommendation track was working, but limiting
… making a substantive correction required going back to drafts
… new features had to go back to PFPWD
… royalty-free licensing didn't happen until full recommendation status
… some of the deeper stacks were based on algorithms, which required frequent updating
… versioning could be confusing
… especially to implementers
… some groups maintain built-in consensus in the draft
… some even have testing
… they fulfill the rec track requirements, just haven't had the director's checks
… it was creating lag between editor's draft
… don't look at the W3C doc, look at the github draft
… we have 37 WGs with different stories
… some are fixed and constant
… the WCAG is a good example
… it's referenced from regulations
… it needs to be stable
… on the other hand that are updated frequently
… Service Workers for example
… it never gets to rec status, there's always open issues
… everything in between
… some have implementations in between
… some don't have built in testing
… Process 2020 is a trade off
… all about balance between satisfying the needs of working groups
… and the needs of horizontal review
… who want to see issues resolved
… we still need some steps in the track
… there's a desire to see reviews at the end of the track
… desire to secure royalty-free committments
… getting implementations
… keeping standards up to date on the w3c website
… process2020 enables wgs to map their standards to what they need
… they know their communities best
… we are here to help them
… keeping current values that are useful for the web while embracing new ones
… previous work modes are fine
… Patent policy, make royalty-free as early as possible
… all of the working groups are under process 2020 as of September
… not everyone is under the new patent policy
… we will be contacting chairs and team contacts to ask them if they want to update the policy. It's a bit disruptive, because all members have to re-join the group
… if not this round, then it will happen in rechartering
… we do have checkpoints in the new process to ensure horizontal reviews still happen
… but without hampering the group's process
plh: Here is a graphic of the new process
… classic workflow
… FPWD to working draft, CR snapshot to proposed, to rec
… group decisions still required
… some groups gave editors blanket approval to update the specs
… using github hooks
… other groups have a more strict process
… CFC, etc
… the process of updating the WD could be more complex, but it is up to the group
… for CR, what's new is allowing groups to update with substantive changes
… CR drafts
… working group makes the decision
… WGs can publish snapshots, that triggers the director's approval and review
… on the right is the changes for recommendations
… allowed to constantly republish the recommendation
… to update with candidate changes, with proposals
… no groups have gone through that process
<fantasai> Candidate Changes mockups at http://
plh: If you publish your rec with candiate changes, you can move them to Proposed changes, and they will be reviewed
… the director will review, and decide if they can be added to the recommendation
… this could happen continuously
… nothing prevents you from adding new changes while review is underway
… if you want to add new features without going to WD
… you need to declare this intent in the PR
… so the AC can review and approve
… up to the WG to allow that process or not
… for any substantive corrections, its not an issue
… JSON-LD 1.1 are in this process, they are adding new features
plh: Living Standards model (similar to WHATWG), you can publish a series of CRs with snapshots
… the old model, with version numbers, going back to FPWD to publish new features, is available
… and the stable model, is a hybrid of the two
… a stable rec with chance for changes
… if your charter says you're publishing a rec, but you decide to publish a living standard, its fine, clarify in the next chartering process
… versioning: group can decide to obsolete old versions
… or supercede
… a good example again is WCAG
… our API supports versioning
… if you find errors please let us know
… the /TR is not using it per se, but the chair dashboards do display the information
… updating a rec: markup changes can be done in place
<fantasai> https://
plh: reach out to the webmaster
… editorial changes can be group-decided, date updated
… substantive changes, need a new dated version and proposed changes
… after review and approval can be incorporated
… it's a continuous flow
… a change that is rejected can be moved back to candidate status
… publishing and maintaining: use Echidna, helpful for automatic publishing
… instead of going through the webmaster
… as often as you want
… one publication per day
… if you're unsure of where you are in the process
… use the step finder
plh: I wanted to talk a bit about reviews
… check out the materials for the presentation on the importance of reviews
… the web is for all, we should preserve its social value
… horizontal groups are always watching, but there's a lot of review
… all WD have to be reviewed
… Sam Weiler and r12a released new information
… CGs can have reviews as well
<fantasai> https://
<fantasai> https://
plh: When should you review?
… earlier the better
<r12a> /w3c.github.io/documentreview///w3c.github.io/documentreview/
plh: wanted to get the spec perfect, delayed review
… the perfect is the enemy of the good
… waiting too long could mean you might have to make major changes
<r12a> s|https://
plh: the worst case is being told it's too early, come back later
… CGs can ask, WGs get priority
… get reviews regularly, and especially if substantive changes have been made
plh: how to request wide review
… several groups have questionnaires
… help to understand what they are looking for
… once ready, update the status
… the tooling will pick this up
… mentioning "wide review" is sufficient
… your charter will likely have dependencies
… make sure those are reached out to
… for proper review
… we want to make sure the group is offered a reasonable opportunity for review
… we do track horizontal issues
… raised by the review group or others
… we have a board for that
… gives you a view of all of the issues
… we track 285 repos
… looking for the labels
<fantasai> https://
plh: tracker for keeping an eye on an issue
… needs resolution for issues requiring a result
… we're tracking a lot of repos, like the WHATWG or DOM, beyond W3C
… facilitating transitions
… using GH to track transition requests
… have a public record
… subscribe to the repo if you want to keep track of these
… goal to provide a single form
… not quite ready but soon
… people open the issues, see the template, but don't look at the documentation
… ask for clarification
… goal is to reduce administrative and director overhead
… the director doesn't read all of the specification, only time for so much, broad reviews
plh: CR snapshots could be approved automatically
… if everything is done properly
… more information could be found in the guide
… dashboards, all on the website
… when in doubt, ask your team contact or me directly
<Zakim> nigel, you wanted to ask what the plans are for making it even easier to request HR?
nigel: Thank you for the presentation
… I noticed that things are clearer
… one of the things was horizontal review
… plans to make it even easier for groups to request
plh: We do plan to have a single form to request review
… which is then dispatched
… the biggest issue, how many questions is the reviewer allowed to ask
… I can't introduce all of the questions in the form
… it would be too long
… it would deter people
… UI problem
… what's the number of questions that is easy to fill out and gives groups what they need
nigel: If there are specific artefacts that are required
… then there should be a uniform way to provide
… the questionaire as a issue
… query checks if everything is in place, reminds the requester what they need to have in place
r12a: I don't think the i18n is expecting the answers in the self-review
… we have the ability for the requester to create the questionnaire in their repo, and we just need the link
… just wanted to reinforce that self-review because you'll likely find the issues yourself, and saves everyone time
… recommend a self-review on publication of a FPWD
… spot issues very early
… change track or adjust
<r12a> https://
plh: The idea is that people are pretty good at sending reviews to the TAG
… providing documents would be useful
weiler: The TAG often gets early design reviews
… earlier in the process than other horizontal reviewers might want to see them
… like you are ready for i18n before privacy
… if you think you're going to have privacy issues, you might want to go to them early
… there's a need for the review groups not to get immature docs, and groups to et review when they need it
… theym ight be exceptional cases too
judy: +1 to Sam
… there should be a process for people being able to approach when they need it
… most worried about delayed reviews
… concerned about the results, and they delay, but it's the opposite, if you're concerned, get our input
<Zakim> nigel, you wanted to ask about getting context in HR for granular features
nigel: This conversation gave me an idea
… the direction of this granular approach
… when it comes to review
… for people who aren't experts, the context required gets bigger
… how will the HR groups handle this
… no longer reviewing an entire spec
… like asking if the wall should be blue but they don't know how the rest of the room looks
weiler: Absolutely a problem
… I have been trying to solve it by involving the same person, but it is a problem
r12a: Again to reply, it's always been a problem
… it might get bigger
… it's why we ask specific people to do reviews
… it's why we also ask questions
… instead of just giving answers
… the self review is really useful, those questions go there
… that helps
Judy: One of the reasons I would like to leave HRs to flexibility
… TAG review, they have a specific explainer format, not the same as other groups
… I'm unclear whether the explainers are answering the essential questions
… I think that common formats might be helpful as a suggestion
… not a requirement
plh: I suspect I'm going to be repeating myself a lot
… it's tricky to implement
… at least to apply
… implementation is mostly done
… don't hesitate to reach out
… main question is "what are you trying to achieve?"
… based on that, here are the recommendations
… if you have really old documents on /TR
… you'll be having me at your door asking for updates
… no more pointing at ED's
… on that, I think we are done, thank you everyone!