Revising W3C Process Community Group -- 20 Jan 2021

<scribe> ScribeNick: fantasai

Agenda Bashing

dsinger: Anything missing from agenda?

florian: Just slight reordering of items

Distinguishing Team corrections

github: https://github.com/w3c/w3process/issues/493

florian: We had introduced ability for Team, when there exists no WG to maintain a REC, can introduce candidate amendments to the spec
... One point we missed, when the WG introduces such amendments, it's considered WD for sake of Patent Policy
... PP has some clauses that affect WDs
... But Team isn't a WG, and is not covered by PP
... So that's the issue
... Solution is to clarify
... We mark Team amendments specially, and clarify they aren't subject to Patent Policy
... PR does this

https://github.com/frivoal/w3process/commit/1ff987214dcee1598983a3c8ce665ac2f22f0249

dsinger: idk if "non-normative" is the right word

fantasai: "non-normative" references the last section in the PP, which says what's covered vs not in the PP -- non-normative text isn't covered by PP

florian: We also note that the candidate corrections are notes about what the WG intends to do, not actually changing the spec

wseltzer: I haven't reviewed this yet, need to

https://www.w3.org/Consortium/Patent-Policy-20200915/#def-essential-requirements

plh: two requests for amended RECs in the past week
... We were talking about it earlier because not used in the past
... ??? didn't push to REC because of a dependency on ?????
... and just received comments on media type from IETF, REC from 2013(?)
... and will need to publish Amended REC to address
... maybe editorial though

dsinger: Sounds like just waiting on review from wseltzer, maybe wording tweak
... come back to it next time

Decoupling Notes and REC track

github: https://github.com/w3c/w3process/issues/342

florian: We've been discussing extending the Note track in issue 489
... But it's quite tricky to do, because Notes and REC track are tangled up
... There are two points of entanglement
... One is when you give up on a REC track document, the way to retire is turning into a Note
... The other is prior to publishing a Note, can publish an FPWD
... But WDs are defined to be on the REC track, and to invoke the Patent Policy
... Might have made more sense before Patent Policy, but now not so much
... So the PR introduces a "Draft Note" state
... equivalent to WD, except doesn't invoke Patent Policy
... and on the other end, when you retire a REC-track document, you don't retire it to Note, you retire it to a new class of document
... Untangling helps with the next issue, which was introducing AC-approved "notes"

dsinger: https://github.com/w3c/w3process/pull/488

jeff: Every time that we add a new document status, we add complexity to the Process document
... Adding Draft Note etc. I would want to do only if necessary
... Especially changing things we've had for years
... What's the problem we're trying to solve?

<wseltzer> +1 to jeff

florian: There's a combination of a practical and theoretical problem
... Theoretical is the one I started with, that we're trying to do more with the Note track. It's oddities make it harder to extend.
... A NOTE can be revised as you want. some groups do that
... But some groups start with an FPWD, then WD, then eventually move to NOTE
... But if you read Process, FPWD is the beginning of a REC track, and it invokes the Patent Policy
... Triggers an exclusion period even though the document will never go to REC.

jeff: Solving a theoretical problem isn't enough to add complexity to Process document

florian: The thing getting odd is when adding next level of NOTE
... If some of these notes were on the REC track in the past, then retires into a Note, then gets published as an approved NOTE even though has been on REC track before ...
... It gets very weird.
... Theoretically you could go FPWD -> CR -> NOTE -> Approved NOTE
... We could say "please don't use this path", but it's currently possible

jeff: What's the practical issue?

florian: First, it was a practical problem as a document editor. Trying to write it all to make sense, made it harder with the entangled tracks.
... Having the Patent Policy track and not mixed up also was complicated
... Having separate tracks makes it simpler to think through
... Another tweak... for the enhanced version we wanted the TAG to be able to publish these things
... If TAG wanted to create a draft of these things, can they do that? FPWD is on REC track and TAG can't publish things that invoke Patent Policy
... So splitting these tracks makes this clean

<plh> fantasai: diff between we added more terms and the complexity of the process. the cross over between the tracks is complex

<plh> ... more terms make it less complicated because we have a clear delineation of the tracks.

<plh> ... if you got one document labelled within each track makes things easier

<Zakim> plh, you wanted to plug https://pad.w3.org/p/clearspec2021

<scribe> scribenick: fantasai

<plh> https://pad.w3.org/p/clearspec2021

plh: shameless plug, one project I'm working on in 2021 is distinguishing better CG and WG work
... Still working on it, but started introducing to Team last week

<plh> https://w3c.github.io/tr-pages/documents.html

plh: One thing in that long list is, this document I drafted
... Lists all the types of documents we publish at the Consortium, including within CGs
... We have devrel people on browser teams who don't understand the difference between the types of documents
... We need to help community understand the different types of document
... Working Draft on REC track and Working Draft on NOTE track is confusing

dsinger: So distinguishing better between WIP and various other types of documents, notes vs recs, etc.
... All the differentiations are important

plh: Goal of work right now is to address the public, not the Process
... But in the long run, nomenclature and naming, might have to come back to Process
... Want ot help public understand what we're doing

weiler: I agree with Jeff about complexity
... When I think about Notes, I think about Informational RFCs
... Patent commitments attach to previous version of document, on the REC
... Patent commitments attached to previous version
... Could publish thing that says "be aware, previous thing that had patent commitments attached"
... helps untangle it!
... Commitments are about that version

dsinger: So you're talking about the Discontinued REC case

weiler: I think we can talk about it in a clearer way

<Zakim> jeff, you wanted to clarify that I am not only concerned about "adding terms"

jeff: fantasai said adding more terms would simplify Process document
... Agree that's a possibility
... but I don't know, could see it go either way
... Once we introduce terms, very hard to get out
... Also I think we'll have a lot of archaeology to do with existing Notes
... which would not match new nomenclature
... In last rev of Process document we introduced CR Snapshot etc.
... I think if we try to address the new requirements for AC-endorsed notes, if we try to address in two different ways and looked at the length of the document
... then I could be persuaded maybe it's better one way vs other

dsinger: If it makes life more complicated, then introducing term not a great idea

<plh> example of Patent Policy wording about previous commitments: https://www.w3.org/TR/2018/OBSL-widgets-20181011/

florian: To me, the complexity of the Proces,s more than the amount of words, is the number of edges in the graph
... If you can transitaion between many things to many things, that is hwat is complicated
... In Process2020 we added many new edges, many transitions
... Useful, so we did it, but that was compelxe
... What we're doing here is removing such edges
... Retirement from REC to NOTE is one part
... and when a thing is intended to be a NOTE fro mthe start, starts as FPWD, that's just weird
... You're required to send a notification to the WG "when this document reaches CR, will you be willing to issue a Patent licence for it? Even though we're not planning to turn it into one"
... Asking this question is odd!
... but it is currently required by the Process
... ALSo FPWD is made by a WG. Can an Interest Group issue a FPWD if they're planning to turn it into a NOTE?
... This is unclear!

<Zakim> dsinger, you wanted to ask (a) about pre-existing abandoned recs, and (b) whether we dare renaming WD?

florian: By making Draft Notes separate from Working Drafts, we clean up these problems

dsinger: If you want to resuscitate a discontinued REC, what happens?
... I don't want to see work done on it that didn't fall under the Patent Policy
... Bits that were subject to exclusions, others that weren't, sounds like a nightmare.
... If you want to work on a document, it can't be discontinued anymore. Need to move it into a state that's workable.
... ...
... pre-existing abandoned RECs, are we thinking of renaming those? Cleaning up?
... We have a track called REC that has these various stages: WD, CR, PR, REC.
... They're all called "recommendation" except for WD. Can we call it "Draft Recommendation"?

<plh> (we have a process for restoring a REC)

dsinger: and then have "Draft Note"?
... Might not be worth it, since we use WD temr everywhere
... so... lots of questions

wseltzer: There would be all sorts of fascinating PP interpretations on resuming a halted document.
... I don't think we've ever had that come up as a question

<Zakim> wseltzer, you wanted to discuss resuming discontinued doc

dsinger: Never revived a discontinued REC, huh.

wseltzer: Question has never been brought to me

<Zakim> jeff, you wanted to comment on Draft Recommendation

wseltzer: Interesting historical record of ppl willing to make patent commitments to it, but never had to interpret how they persist

jeff: I actually prefer "Working Draft" to "Draft REC"
... Reason is because we encourage groups to publish even when there's no consensus
... "Draft REC" implies stronger consensus that this will become the REC

florian: Other than ...
... "Discontinued Draft REC"
... Interesting question we didn't answer
... can you iterate in the document in DDR state?
... I think if you revive, I think you need to revive exactly as it was
... also, maybe if you retire a CR, you have to revive it into WD rather than back into CR.
... Currently the Process says if you revive, it goes back to old status. But probably needs to say you can't make changes.
... Wrt Draft Recommendation, not sure I agree with Jeff's point, but agree we do have intertia on "Working Draft"
... We don't have such on discontinued RECs, and didn't want to have different term for whether it was discontinued from WD/CR/PR/REC or whatever, so just made one term.

dsinger: ....?

florian: We were asked to clarify Process to explain what "discontinued" meant
... Having a state representing it seems good.
... IDK about mass-renaming everything that already exists though

dsinger: So, let's look into whether this is simplifying, or if it's not, how to make it more simplifying.

ACTION Florian summarize the points of why disconnection is needed into the issue

AC-approved Notes

florian: Currently calling them Memoranda
... PR depends on the previous
... It felt hard to write the Memorandum addition without cleaning up the Note track first
... so that's why dependent
... the idea is that there would be a transition, with AC review, etc.
... PR also explicitly allows all the groups, including TAG and AB, to publish NOTEs and to elevate their NOTEs to W3C Memorandum
... Question of how to amend a W3C Memorandum comes up as a result of having one, we basically duplicated the REC amendment process
... Request, if you're reviewing these PRs, please review commit by commit
... It will be easier to understand the changes step by step
... E.g. in the Memoranda PR, the first three commits are from the NOTE track disentangling

jeff: I would like to get a holistic picture of how they all fit together
... Is there a document I can look at?

florian: PR 489 has everything in one PR, but the PR is composed of multiple commits that are probably easier to read one by one

dsinger: Might help to have a flow chart
... show what it looks like in the current Process vs proposed Process
... Might help everyone understand

florian: In post-changes, it's very simple. Note track is
... Draft Note -> Note -> Memorandum
... If we don't take those changes, then it becomes much more complicated because it entangles with the REC track

dsinger: OK, we'll leave these hanging.

ACTION Florian Make flow charts

Tooling Policy

dsinger: fantasai and I have been discussing how do we balance having tooling policies vs innovation
... question is what are the minimum rules we need to ensure the viability of the W3C and our ability to work together
... We came up with 5 things to put into process, rest would go into /Guide
... concerning archiving, and accessibility
... both for discussions and also deliverables
... we can't be relying on an external service that will go away
... we also need our Members to be able to participate
... We need the tools to be usable without restriction and cost
... to the general membership
... and that they're findable
... The intention here is a minimum set of rules that covers basic operability of the Consortium as it is today
... and maintaining our records into the future

https://www.w3.org/wiki/W3C_Tooling_Policy

fantasai: think of a 2x2 table, considering deliverables vs tooling/discussions, and considering for each archiving vs accessibility requirements
... and lastly, tools and records have to be findable

florian: I like the proposal. Have to be careful when wording MUSTs

jeff: Thanks for doing this, and I like the direction going so far.
... Can't deliver a thorough review yet
... but 2 things I noticed
... "W3C requires that", usually we use MUST/SHOULD
... If it gets violated, what does that mean?
... If someone uses a tool that isn't perfectly accessible, what happens?
... On 2nd recommendation, following best practices for accessibility worldwide and for persons with disabilities
... I can't tell if it's about accessibility or what we call Web Accessibility
... and other topic about tooling has to be available in all countries
... famous case of certain tools not available in China

<weiler> https://github.com/w3c/w3process/issues/435

weiler: Issue I raised in the issue, 435, was about the accessibility in different geographies
... I don't want to see any one country's censorship choices the power to dictate our tooling
... the wording here does that
... I think this doesn't belong in Process
... Don't want ambiguous requirements here.

dsinger: If you pick a tool that has no provision for working in a language other than English, it's a problem

<wseltzer> [the list should be split, then, between requirements on deliverables and those on the tools]

fantasai: Be clear about which rule you're thinking about, two are about tooling and two are about deliverables. don't mix up requirements for one with the other.

jeff: The title of the section maybe needs fixing.

<weiler> [or, if you can't find the bright line, don't clutter the Process with it]

dsinger: I think weiler's concerns pertain to rule 4, need to find the right balance

<Zakim> fantasai, you wanted to ansewr that

<Zakim> wseltzer, you wanted to discuss recourse

wseltzer: We need to be very careful what the recourse is for a violation of a MUST
... Like Sam, I recommended against putting in Process, anything that's there should be very well scoped
... Recourse needs to be "order the group to use a new tool", not "REC is invalidated".
... Shouldn't give a hook for people to say the REC was invalidated because the tool wasn't appropriate

<jeff> qq+

<Zakim> jeff, you wanted to react to wseltzer

fantasai: If participant wants to participate, and needs to use a tool but can't, then group has to either switch tools or operate some kind of bridge or workaround. Can't say "too bad, you can't participate".

florian: Yes, it's annoying that China blocks gdocs. But if someone from China wants to participate and can't access gdocs, we can't say "too bad".
... We can't turn away actual people who want to participate.

- DRAFT -

Revising W3C Process Community Group

20 Jan 2021

Attendees

Contents

Agenda Bashing

Distinguishing Team corrections

Decoupling Notes and REC track

AC-approved Notes

Tooling Policy

Other Topics

Summary of Action Items

Summary of Resolutions

Scribe.perl diagnostic output