Meeting minutes
dsinger: Forgot to include recording meetings in section 3
Tooling Policy
dsinger: CFCs out to the AB, making various comments on policy. Trying to get agreement in principle
dsinger: Question about MUST vs SHOULD
plh: One reason for SHOULD is we don't know how it will be received from WG and how much work to make it happen
plh: For some WGs, not very simple to move over
plh: Need to collect data from Team Contact, and I'm working on a questionnaire on that
plh: This has side-effect of making Team look more closely at the guidelines
dsinger: Would be good to hear about the hard cases
<florian> fantasai: I agree with Jeff about mking the guidelines shoulds for now
<florian> fantasai: so that we can take time to get ready before making them into musts
<florian> fantasai: we'll then know what needs tweaking, what can be made MUST
<wseltzer> +1 to "should"
<florian> fantasai: I think this approach avoids a lot of the problems of doing it in 2021, given that it's a lot of work for some people/grtoups
cwilso: fantasai and plh said what I wanted to say
jeff: We've had very good experience in W3C socially by instituting changes gradually
jeff: e.g. liberal document license, first we allowed it only if there was no dissent in the group
jeff: and then ppl got more comfortable with it, and started using for everything
jeff: I imagine a similar circumstance here. Socially-mild way to start doing it, everyone will see it's the right thing to do
dsinger: I think transition is a poor reason to put SHOULD into the Process
dsinger: if there are good reasons why they shouldn't comply, then we can write a SHOULD
dsinger: but we should write what we intend, and just allow a grace period
dsinger: don't need misleading Process text
dsinger: Are there legit cases that need exceptions?
dsinger: then make should
<weiler> -1. ; don't fight these battles now
+1 to weiler
<weiler> s/Tantek//
fantasai: dsinger is arguing for MUST, multiple ppl arguing for SHOULD
fantasai: is anyone else arguing for SHOULD?
dsinger: let's wait for survey
<jeff> Fantasai: AB has lots of discussion
<jeff> ... David you are the only one arguing for MUST
<jeff> ... David, can you live with SHOULD
<jeff> David: Then we should be willing that it might be indefinite
<jeff> ... let's not delude ourselves
<jeff> Fantasai: I think it is fine if it is indefinite
<jeff> ... soft powers are powerful
<jeff> ... if Team is onboard, that's what we need
<jeff> David: Acid test is the practice
<jeff> Fantasai: David, you are the only dissenter to SHOULD
<jeff> ... can you live with that?
<jeff> David: I want to see the results of the survey
<jeff> Fantasai: Some people think SHOULD regardless
<jeff> David: At the moment I disagree
<jeff> ... willing to see discussion and survey
<jeff> ... haven't heard from the whole AB
wseltzer: My concern with MUST is the unintended consequences of giving new objection rights
wseltzer: I think a SHOULD that is indeed strongly followed by the Team, as in you need a really good reason for an exception, is better
plh: different between MUST vs SHOULD is in how the Team applies it
plh: We had MUST publish every 3 months in the Process for years, and in practice WGs were reluctant to follow
plh: Team didn't enforce because puts WGs in limbo
plh: We should go with a SHOULD to make it apply
plh: if we want to revisit later because believe it's not propertly followed
plh: we can revisit then
dsinger: OK, let's see what comes back from the AB CFCs
jeff: There were a few other points, and maybe they were minor, but for example on the internationalization point where we require best practices
jeff: raised concern that not defined what those best practices were
jeff: Not that there weren't other issues raised
florian: I suspect we used to [audio broken]
florian: We can wait for survey before diving into details
Separate Note Track
dsinger: Good support from AC, should we land it?
florian: Yes, two nuances
florian: One is bikeshedding on name of the discontinued/abandoned/draft thing
florian: Something like "Inactive Draft" might be more useful than the DDR term
florian: There's also some discussion of switching tracks other than copy-paste into a new document
florian: but basically suggest merging PR and then follow up on those quesitons
dsinger: Inactive Draft might be more useful than implying permanent abandonment
florian: I'd prefer "Discontinued" because existing word in Process
dsinger: that also work
dsinger: In absence of better ideas, we'll call them "Discontinued Draft"
dsinger: for discontinued REC-track documents (since they'll no longer be Notes)
fantasai: There's some longstanding confusion over NOTEs used for terminating REC-track work
jeff: Could have a document that starts on REC track and shouldn't be normative?
dsinger: If was intended to be a spec, but later realize don't intend to finish it, then that's a "discontinued" REC-track document
dsinger: but if it's something you want ppl to look at, but decide it should be non-normative advice, that would be a Note that's alive
<tantek> not seeing a link here about notes
<Zakim> tantek, you wanted to ask if someone has made a list of current use-cases for notes?
tantek: Definitely interested in the outcome
tantek: what does a Note mean?
tantek: has anyone started list of use cases for Notes?
tantek: e.g. use case document, TAG guidance, something else?
dsinger: plh can you give us a list?
plh: To look at every single one to figure out why it's a note, is it because abandoned or retired? that's a bit of work
<tantek> lol no, no one asked for every single one
tantek: nothing comprehensive, just want a start on the list
fantasai: to be clear, we're not trying to subclass NOTEs
<plh> https://
fantasai: just want to pull out the use of NOTEs for abandoned work on the REC track
<tantek> wow did we even try to list use-cases?
fantasai: in order to disentangle tracks
<tantek> is there a GitHub issue on this?
fantasai: ...
dsinger: If you have a better idea than "Discontinued Draft" for abandoned work, bring it to GH
<tantek> is there a reason we're only clarifying that case?
tantek, https://
tantek, yes because it's the only one that ties together the tracks in a confusing way
tantek, please read the issue
<tantek> reading
jeff: I don't care if we do sync or async, but if there are many use cases that can land in Notes and some deserve to be discontinued and some need to move to other tracks, and some still a Note, before we write Process text we have a good understanding of where we expect this to go
<tantek> thanks for the link fantasai!
dsinger: we're not changing anything about Notes except giving them their own track
jeff: What I heard is that discontinued drafts are now called NOTEs, and in the future won't be, but could be?
dsinger: If WG thinks should be published for current consumption, but not normative spec, should be a NOTE
dsinger: and can switch tracks into NOTE
dsinger: But what we don't want them to do is to publish historical abandoned work as NOTEs, that is a "Discontinued Draft" and it sits on REC-track as such
dsinger: We're not taking any capability away, just clarifying status of such documents
<Zakim> tantek, you wanted to note political motivations and how that'll result in folks not using discontinued draft
jeff: OK, that makes sense. Unsure about the name
tantek: There's a lot of strong political motivations for labelling things a NOTE
tantek: I think a key dynamic to consider is, how will WGs try to use this process and be pressured one way or another
tantek: I think it's good to make a decision up front whether NOTE or REC
tantek: so that's helpful
dsinger: Next question is if you want to move from NOTE to REC, how do you do that?
florian: Currently there's nothing preventing copy-paste from document X into a new document on the new track
<tantek> +1 florian just copy paste as you would from anything informal to a brand new WD
florian: the only question is , do we want to switch track without doing such copy-paste
florian: Should group be able to start with WD and decide, this was a mistake, let's switch NOTE
florian: There's support for this
<tantek> right, no back/forth please
florian: There's not really support for switching back and forth
florian: My suggestion is that we take the PR and then tackle that as a follow-up
dsinger: Concern about switching from REC to NOTE, then iterating under NOTE, and then switching back to REC
dsinger: So I think copy-paste is better idea for switching from NOTE to REC track
<tantek> I think a REC-track document MUST NOT be able to terminate as a NOTE any more, that it must terminate as a REC or Discontinued Draft
dsinger: So would have no transition into REC track other than from the beginning of it
weiler: Think about my experience editing documents (though not at W3C), some documents want to do that
weiler: We want to publish as not-REC now, and then ppl get interested in it later
weiler: as an editor not interested in rewriting what I wrote 3 yrs ago, just going to copy it i
weiler: ... maybe I don't understand
dsinger: you had someting iterating as a NOTE, and then group realizes wants normative, and should be REC
dsinger: You changed your mind, where do you go back onto the REC track?
dsinger: is there a path back onto the REC track other than at FPWD?
weiler: I'm not going to go start with text from 3yrs ago.
dsinger: You'll start with your current text, and you'll publish as FPWD, and then go down the REC track
<jeff> Fantasai: We want to allow jump from WD or CR into Note
<tantek> no
<jeff> ... can we resolve on allowing that?
<tantek> especially with the short name
<jeff> David: Three states in Note track
dsinger: So NOTE track is "Draft Note", "WG-approved Note", "W3C-approved Note"
dsinger: not sure there's a practical problem
florian: Seems we haven't explored the question, maybe we should have some async discussion
florian: My suggestion is take in the PR without that part, and can only do copy-paste restart on track
florian: if we want something else, let's come back to that in a call or two
dsinger: ping chairs?
fantasai: I posted to ac-forum, chairs, and spec-prod already about these changes
dsinger: Let's make sure we don't forget any use cases
dsinger: Should we get agreement to pull this?
fantasai: I'm happy to pull and iterate once pulled
tantek: just realized there's a PR. I'm not going to block because haven't read yet
Resolution: Accept the PR, file issues for follow-up
Upgrading NOTEs to W3C-approved SOMETHINGOROTHER
dsinger: Current word is "Memoranda", unsure anyone loves it
dsinger: but we're not coming up with great alternatives
fantasai: Can we resolve on accepting the PR first?
<tantek> what
<fantasai> s/RESOLVED: Accept the PR for Memoranda//
<tantek> for the Discontinued Draft track right
<tantek> er, termination, not track
<jeff> Fantasai: Can we accept the PR before we bikeshed the name
dsinger: AFAIK the only open quesiton is the name, is there anyone with any other concern?
<tantek> please stop asking for resolutions without links
<tantek> seriously unacceptable
https://
dsinger: I assume ppl have the agenda on hand
<tantek> it's worth capturing in the flow of the minutes for folks reading afterwards
dsinger: I try to write agendas with extensive cross-linking
florian: PR does two things, first it enables the AB and the TAG to do NOTEs as well (in addition to IGs and WGs)
florian: and it also enables NOTEs to be elevated to a to-be-named status with AC approval
<tantek> +1 on Discontinued Draft
<tantek> -1 on Memorandum
<tantek> so I'd reject this pull request
fantasai: The PR includes the commits from the previous resolution, btw
dsinger: Any open questions other than the name?
<Zakim> tantek, you wanted to note (so to speak) about the longevity / redirection aspect
tantek: I would suggest breaking up the PR into the parts that have consensus and the ones that don't
florian: You want the PR merged with the name replaced by quesiton marks or what?
florian: I can't merge a PR describing a thing without naming the thing
[discussion of PR mechanics]
<tantek> this is why #489 is confusing
dsinger: Seems we can agree that we can merge as soon as we conclude on a name
<tantek> I'm opposed to another "special name" that needs explanation
Proposed names so far include: Report, Memorandum, Position, and Statement
<tantek> I'm starting to think the entire attempt to come up with a special name is useless
jeff: I suggest Communiqué
dsinger: ...
<plh> +1 to merge with Statement
florian: I suggest "W3C Statement" and then if someone has a better name we can change it later
<jrosewell> Statement seems reasonable
dsinger: Anyone opposed to Statement?
dsinger: we want a broad name so that many things can be categorized under them
dsinger: so agreed on Statement as the name du jour
dsinger: and agreed we can execute PR, yes?
<tantek> if it comes from the TAG it should be a TAG Position Statement
we're not subclassing
<Zakim> plh, you wanted to ask a question once we agree to merge
Resolution: Merge PR #489 with s/Memorandum/Statement/
plh: To become a Statement, don't need Director's approval. Just need AC review?
dsinger: if community wants this as a W3C document, gets to be a Statement, FOs handled as normal, etc.
Registries
florian: We ran a survey
florian: A number of useful answers, and a number of confused answers
florian: I'm only going to speak about unconfused answers until we get clarity
florian: There seems to be preference for a dedicated Registry Track
florian: and there seems to be a preference for no distinction between CR and PR
florian: Third question of whethe Registry Tables should be possible to publish separate from Definition
florian: we got answers that need them and those opposed
florian: that's the interesting open question
florian: Anyone disagree that we have consensus on separate Registry Track with merged CR/PR phase?
dsinger: Anyone disagree? It makes the Process text a bit longer, but more straightforward
dsinger: and also you can include your registry inline into a REC eithe rway
Resolution: Separate Registry Track modeled on REC track, no CR phase
dsinger: open question
florian: There seems to be both support and discomfort with having the tables in a separate document than the definition
florian: My main concern is with the complexity that introduces
florian: we need more rules in process doc if they can be separate
florian: example
florian: we have a final, approved Registry Definition
florian: we have a separate publication of Tables
florian: everything is dne
florian: Then we decide we want to add a new column
florian: If everything were in a single document, you can mark it as a proposed change in the Registry document
florian: but if they're in separate documents, then can you add the new column to the Regsitry Tables document before the Registry Definition changes are approved?
florian: It's not clear what should happen
florian: The general principle is, if we have more moving parts, we have more complexity to manage
florian: The second thing is, separate publication is an additional feature from what we have
florian: My suggestion is that we start without it, and if ppl continue to ask for it, do it next year
florian: I don't think it's impossible to define, but it's more moving parts
florian: We have two definitions of the Process, one which has this definition bu thas ambiguities
florian: Another issue is, if we have separate parts, then we need names for each part
florian: In the existing branch of Process where separate publication is allowed, the Definitions must always be on the REC track
florian: but now that we have a Registry Track, if we have separate publications for Definitions and Tables
florian: I'd rather not answer all these questions and keep it simple for now
dsinger: I think we need the set of questions
dsinger: My read of the situation is that this is the common case, we shouldn't ban it
dsinger: Let's see what questions need and try to resolve it
florian: I can try
Fantasai: It's common outside of W3C
… but in W3C they tend to incorporate the definition and the registry into a single doc
… unless they are not allowed to update the REC
… Florian's concerns about complications are relevant
… Process Doc is long
… we can avoid that here
… if it becomes an issue we can do it next year
… survey results in detailed showed
… (both those that needed and those that considered harmful) confusion
… they want easy update which is exactly what Registries give you.
dsinger: If allow publication together, Team needs to check that you didn't modify the wrong parts of the document
fantasai: need to do that anyway, because allowing that already
florian: We have two branches for registries edits
florian: I suggest on the editor's side, we change the two branches of the Process so that they're only different in this specific quesiton
florian: and as part of doing that surface what the remaining issues are
dsinger: Sounds good
Recording meetings
dsinger: Didn't get to Recording meetings
dsinger: Can we prepare a PR?
florian: I'll try
dsinger: Some discussion about public/perpetual recordings, unsure about banning them, unlikely to get approval from group though
dsinger: anyway let's look into those
Follow-up
<tantek> we need to take steps on recordings towards being more inclusive of diverse realtime participants IMO
dsinger: We need to work through those
dsinger: for issue ?? , if can resolve by accepting PR would be nice
dsinger: wrt Wide Review issues, I think we need some help?
dsinger: suggestion in the issue that it can be closed
dsinger: next meeting March 10th
Meeting closed.
dsinger: Thanks everyone for the hard work