W3C

Publishing Maintenance Working Group Telco

04 August 2023

Attendees

Present
Avneesh Singh, Brady Brady Duga, Charles LaPierre, Dave Cramer, duga, George Kerscher, Ivan Herman, Masakazu Kitahara, Matt Garrish, Shinya Takami, Toshiaki Koike, Tzviya Siegman, Wendy Reid
Regrets
Gregorio Pellegrino
Chair
Wendy Reid
Scribe
Brady Duga

Meeting minutes

<Ivan Herman> Date: 2023-08-04

Wendy Reid: Welcome back! We have a big agenda

<Wendy Reid> https://github.com/orgs/w3c/projects/37/views/1

Wendy Reid: we have to maintain all our doucments
… they are spread out over multiple repos, and we have carried over issues from previous groups
… we can make errata, and some new changes on some types of docs

<Wendy Reid> https://github.com/w3c/pm-wg/wiki/Publication-steps

Wendy Reid: We need to agree on the classification of changes
… some of the issues have been assigned a class, but we need to make sure there is agreement on those

Ivan Herman: Short summary
… class 1 and 2 are insignificant changes, no big difference between the two
… markup, css, metadata, spelling, etc
… jump to class 4, this is new features
… we cannot do this for class 4, but we can for audiobooks and pub manifest
… class 3 is more vague, signinficant changes in the document
… e.g. maybe we need new tests, and RS may need to think about whether the implementation will change
… If it doesn't really force that, then we can consider it class 2
… bad thing is we don't have a great algorithm for class 3 vs 2, it is up to the WG to determine
… issue 2560 is an example. There was a report of referencing webp, and we need the final ref to it
… so is that 2 or 3? Text changed, so definitely 2, but what about 3? Are there significant changes to webp that make people look at implementations
… Just one example of a borderline

Wendy Reid: Need to keep this short (lots of agenda items)
… so let's jump to those and see if we agree on the assigned classes
… Next item, pub schedule
… Matt and Ivan have been busy with prep work for class 1 and 2
… If we move to merge those, we should republish
… But going forward we should consider timing and cadence

Ivan Herman: Need to understand that when we make a change it does not mean we change a WD and go through the original process of publishing
… instead we publish a new rec, not a big deal for small things
… but bigger things need a little more work
… but what we publish is immediately a new rec
… too frequently might be burdensome

<Avneesh Singh> +1 to 6 months interval

Ivan Herman: we should not publish more than quarterly, and maybe even every 6 months
… Publishing now may not be a good idea, since we will discuss things at TPAC
… for instance issue 2412 (webtoons) may need more discussion at TPAC

<Tzviya Siegman> +1 to wait to publish until we have more issues

Ivan Herman: so probably better to pile up, and publish in Oct or Nov

Wendy Reid: Our community is change averse
… so let's do fewer
… 6 months is predictable

Charles LaPierre: I agree generally
… but editorial changes maybe go out sooner?
… just to make the doc as accurate as possible
… For instance, a bad link that is causing confusion may want to be updated quickly

Wendy Reid: By end of year seems to hit those points

Wendy Reid: any oppo to 6 month cadence? <crickets>

<Wendy Reid> w3c/pm-wg#4

Wendy Reid: On to TPAC agenda planning
… We have 2 sessions over 2 days, ~7 hours
… would like input on topics
… speak up now or add it to the issue

Ivan Herman: Will we have enough info to make the ISO decision?

Wendy Reid: Still waiting on the European commision

Tzviya Siegman: We need to ask Cristina directly
… We need more coordination between business, cg, and this group
… we need more cross coords

Shinya Takami: Gregorio suggested a11y

<Charles LaPierre> Charles is attending TPAC in person

Wendy Reid: Yes, I will handle that

<George Kerscher> George virtually

<Toshiaki Koike> koike virtually

Wendy Reid: [summarizing who is attending TPAC physically/virtually]

Tzviya Siegman: Anything on audiobooks or pub manifest?
… invite Laurent to discuss his work on TDM
… what about Hadrien?

Wendy Reid: We will do some reach out

<Wendy Reid> https://github.com/orgs/w3c/projects/37/views/1

Wendy Reid: Let's go through issues
… mostly epub issues due to carryover
… Matt or Ivan Herman, do you want to go over things?

Ivan Herman: I leave it to Matt

Matt Garrish: I have put in pull requests for everything in epub that could be fixed
… just webp left, due to timing issues
… do we want to go over them one at a time? Or something else?

Wendy Reid: Let's do one at a time

<Wendy Reid> w3c/epub-specs#2578

Wendy Reid: 2578 looks easy

Ivan Herman: For each one we have to officially decide if it is an errate

<Charles LaPierre> +1

Wendy Reid: This looks like errata, forgot to remove a note when we published

<Tzviya Siegman> +1

Ivan Herman: This is on record, that is fine

Wendy Reid: Oppo to calling it errata? <no>
… reolved it is errata

<Wendy Reid> w3c/epub-specs#2567

Wendy Reid: 2567 looks like an obvious error, class 1, make it errata

<Tzviya Siegman> errata

<Wendy Reid> Brady Duga: Raising this on GH and in issues, it's been reviewed by the group.

Brady Duga: Github is bringing it to the group

<Wendy Reid> w3c/epub-specs#2556

Tzviya Siegman: Is there anything on the list we need to discuss?

Wendy Reid: 2556 is class 3 (maybe), there is currently a restricton on epub:type in svg content docs for anchors
… this should be better defined

Matt Garrish: We have 3 classes in svg where it is allowed
… but it turns out there is another element that also needs it

Ivan Herman: But it is an obvious example of class 3, e.g. epubcheck at least will need to change
… is it ok to be errata?

Matt Garrish: Should we leave these open or close them?

Ivan Herman: depends

Wendy Reid: Editorially it is hard to keep things open due to merge conflicts
… if we are accepting the PRs we don't need to leave things open
… The editors draft will just be more up to date

Ivan Herman: Are the PRs changes directly, or updates to the text?

<Wendy Reid> w3c/epub-specs#2569

Matt Garrish: class 1 and 2 are direct, class 3 has full edits (ins/del/etc)

Ivan Herman: Ok, lets merge

Wendy Reid: 2569 summary

Matt Garrish: 2569 and 2570 are similar
… Just need a note to say use "none" for a11y

<Wendy Reid> w3c/epub-specs#2570

Matt Garrish: and the other change is to note exemptions
… mainly for data tracking to identify which allows for tracking a11y exemptions and understand why
… so this is class 2 clarification and suggestions
… The exemption value can live in a note, don't need to add it to the spec itself
… We can decide if we do a 1.1 or 1.2. WG note is fine now

Wendy Reid: Comments or oppo?

Ivan Herman: That means we need to define a new WG note

<Avneesh Singh> +1 from me

Matt Garrish: Yes

Charles LaPierre: Do we need to point to the note from 1.1?

Matt Garrish: Yes, the informative section needs to ref the note, so we need to get the note out first

Avneesh Singh: Just want to say this was incubated in the CG and brought to the WG
… want to encourage more of that

George Kerscher: Anything that would trigger an epubcheck change would be class 3, right?

Ivan Herman: Yes

<Avneesh Singh> anything that will trigeer error in EPUBCheck or remove an error from EPUBCheck

Tzviya Siegman: It has to be, anything that triggers a change in epubcheck changes our must/may statements, so that is a real functionality change

Charles LaPierre: With some other things like webp that is being updated which is just changing the ref, couldn't this cause a functional change?

Matt Garrish: We need to wait for the RFC change first
… How much changes in the RFC will impact how substantive our change is (2 or 3)

Dave Cramer: But unlikely they will break the web with updates to webp

Ivan Herman: In the current spec we ref a Google dev page, the only thing we had at the time
… It is an odd normative reference
… this means we move to an ietf ref
… slightly more than have a good ref to a format
… it is also removing a company doc reference out of a standard

Wendy Reid: Actual doc changes are still minimal

Ivan Herman: But it has symbolic meaning
… so we might want to make it class 3 to call attention to it as an important change
… probably implementations don't change, but would support class 3 to call attention to it

Wendy Reid: Don't mind be prudent to call attention when it could be signficant

Charles LaPierre: It will be in the change logs
… so could call out the importance in the change logs

Ivan Herman: You are right, but there is a little more to it
… publishing a rec with class 3 changes is a several change process, there is an AC review
… editorially it is a pain, esp for Matt
… it needs to be presented with the changes marked clearly to the AC

Matt Garrish: Draws people attention
… not sure how to even do it

<Wendy Reid> Brady Duga: One thing to consider, if we're going to point this out, it will call people's attention to it, and people might spend half a day reading WebP RFCs they don't need to.

<Tzviya Siegman> +1 to Brady Duga

<Dave Cramer> +1000 to Brady Brady Duga

<Wendy Reid> ... I understand it's an important change to the spec, but not necessarily to implementers.

<Wendy Reid> ... I would suggest caution

Ivan Herman: I personally have no idea if there is a difference to the ietf version vs google one

<Wendy Reid> Brady Duga: Agreed, but we can be cautious, someone here could spend that day and we could highlight that. Or we might look and say it's identical, it's not a big deal

<Wendy Reid> ... not highlight it as much

<Wendy Reid> ... we don't need to tell every implementer to read it

<Wendy Reid> Ivan Herman: Action item for Brady?

<Wendy Reid> Brady Duga: I am happy to ask someone from google to review it

Charles LaPierre: If epubcheck reports an error, will it ref the RFC??

Matt Garrish: No, it won't point people at specs

Wendy Reid: Let's leave it where it is now
… and we can leave it to Brady to tell us if anything significant has changed?

Ivan Herman: editors job is different for class 2 and class 3

Minutes manually created (not a transcript), formatted by scribe.perl version 221 (Fri Jul 21 14:01:30 2023 UTC).