Meeting minutes
Pull requests to review
<joshco> the liaison issue: w3c/
Requirement to publish formal objections should include a timeline
<plh> Github: w3c/
<plh> Florian: Process requires FO to be made public but not when
<plh> ... we experienced delays in the past
<plh> ... fantasai proposed "as soon as"
<plh> ... downside: if the FO can be made away, it might expose it unnecessrily
<plh> cwilso: Jeffrey is completely correct, the "registration" definition means it waits until the end of the voting period; I retract that comment
<plh> ... it would be best to have some leeways for the Team to make the FO public
<plh> ... if we feel strongly about something, we still can formally object to things
<plh> .... if someone says "charter is 5 years long", I would object to this but no need to blow things out of proportion
<fantasai> s/expose it unnecessarily to the press and cause a kerfuffle, even if it is easily resolved/
plh: We can't necessarily make the FO public as-is, because if it was Member-confidential, we need to hide the company that made the FO
… we thought it was always appropriate to do that
… so public except for the affiliation
florian: There is a specific section of the Process about how to change confidentiality levels, covers what you said
<florian> https://
plh: from Team perspective, I want to give some guidance
… don't want to put requirement in Process, prevents Team applying judgement
… so prefer to update Guidebook
… our Process is complex enough, prefer to avoid adding more
… but would welcome guidance on how to implement that part of the Process
florian: I think I might be favorable to idea of guidance
… in particular because this is context-dependent, and may need judgement
… e.g. if some people have made public, and multiple objected, might be better to make public so all conversation can be in same space
… [missed]
… allow Team to handle in a timely way, but some flexibility seems useful
plh: +1, can think of some cases that are opposite
… when it's about technical stuff, my advice to Team is make sure you raise an issue on GitHub
… that will take care of making FO public
… there's still a question of "where do I find all the FO", but that's a separate question
plh: when issue is about charter, those can often easily resolved
… editorial to some extent
plh: then there are FOs that concern legal matters
… those shouldn't be pushed to WG, because they wouldn't be able to answer
… those tend to take longer than expected in terms of making them public
plh: Welcome guidance. Wrt checkpoints, we have 90-day limit for starting Council
… so that could be one anchor, if you start Council need to make FO public
… it gives us a deadline
… can advice Team on how to make this sooner
cwilso: I think it's good to have guidance, don't Jeffrey was trying to say instantaneous, but that it should be predictable
… there's a balance, I think this particular situation was unfair to Mozilla
… but nobody had any intent to stick them with that problem
florian: Maybe we need nothing in Process, and everything in Guide
… or in Process put FO deadline of Council start
… or if the objector themselves asks for it to be made anonymously public
plh: We could say "No later than starting the Council"
… and in the Guidebook elaborate on how soon
… saying that in Process wouldn't address Mozilla's case, need to say more, but in Guidebook
florian: So we put that in GH and circle back to Jeffrey?
plh: I can start a PR in /Guide to make more concrete
cwilso: Should probably also get Tantek involved
… wouldn't be as much of a problem if he didn't post his responses as public
… not that he shouldn't
… but if he had just left it Member-visible, he wouldn't have gotten all the flak that he did on Mozilla's behalf
… idk if he finds that important or not
… not sure what's a good solution here, certainly didn't want to hang him out to dry
florian: That's probably enough for this topic for today
… we have a PR for strictest version, so we at least know what that looks like
<plh> fantasai: one of the guidance: dependencies/similarities between FOs
<plh> ... "no later than starting the council" could be reflected in the PR
florian: sounds good
ACTION: fantasai update the PR
ACTION: fantasai to update PR
ACTION: plh to make sure Tantek the PR
ACTION: plh to propose a PR for the Guide
RFC2119
github: w3c/
florian: meant to be editorial, there are some notes/examples that use must/required/etc
… this is a PR to resolve those
… many easy, a few got some discussion
… several patterns, e.g. quoting normative text as an example of normative text
… just fixed some markup there
… a few notes commenting about the fact that there exists a normative requirement (defined elsewhere), so rephrase to make it clearer that note doesn't introduce requirement
… then a few commenting about something being possible, rephrased to not use "may"
florian: two cases to review, one discussion with Jeffrey, and one that wasn't in the PR
florian: There is a note where we comment that when a recommendation is obsolete or superseded, it's still active and PP applies; but is not "recommended" for implementation
… reason to keep 'recommended' is that it reflects "Recommendation"
… but could use an alternative word like "endorsed"
Note: For the purposes of the W3C Patent Policy an Obsolete or Superseded Recommendation
has the status of an active Recommendation, although it is not recommended for future
implementation; a Rescinded Recommendation ceases to be in effect and no new licenses
are granted under the Patent Policy.
TallTed: I think "endorsed" has a very different meaning, maybe "suggested" or "endorsed"
… also really important to add comma in first line
florian: I think "advised" or "suggested" works less well than "endorsed" as a replacement for "recommended"
… we can also just leave "recommended" in place
fantasai: I'm ok with recommended or endorsed
plh: I'm fine with leaving recommended
fantasai: actually I think I agree with TallTed, don't think we should use "endorsed"
… re-reading again, I think "advised" is the best replacement if we want to replace
<plh> For purposes of the W3C Patent Policy, an Obsolete or Superseded Recommendation
<plh> has the status of an active Recommendation, although it is not advised for future
<plh> implementation;
<TallTed> +1
<plh> +1
RESOLUTION: Replace "recommended" with "advised" in the note quoted above
florian: Another question where I think jyasskin is confused, would like the group to check
https://
fantasai: [explains the conversation up there]
florian: Most common case is FOs that happen after requesting advancement
… if FO is filed after the request, then of course that's OK, still have to resolve before actual advancement
… but if there's an FO to a group decision, you can't advance your spec while ignoring the existing FO
… so you should resolve that FO first before requesting advancement
plh: And this is only for advancement
florian: If we agree, I think we can explain away jyasskin's comment
… the rest of the feedback on the PR was addressed
plh: Team is not allowed to approve advancement if there's an unresolved FO
florian: Anyway, I don't think this is anything new, this is just clarifying
plh: Anything else to look at on this PR?
florian: nope
plh: OK, with the substitution of "advised" for "recommended", any objection to PR803?
RESOLUTION: Merge PR803 with above edit
Clarifying definition of W3C Decision
github: w3c/
florian: W3C Decision is made as result of AC Review
… in area where we discuss AC Review, we didn't highlight this term
… which made it harder to spot what's happening
… so this PR from fantasai makes that clearer by adjusting the titles and wording
… it's editorial, helps with clarity, would accept
… also would accept TallTed's fix AC-> Advisory Committee
RESOLUTION: Adopt PR 802 (with AC expanded)
Team Update on TAG Appointments
plh: We are struggling to implement this part of the Process
… Process tells us that we should announce by beginning of new term (Feb 1)
… also says we can only do our selection after vote results
… which will be announced tomorrow
… one thing we didn't do was start call for input prior to that
… we are about to correct that
… because this is end of year, losing time from winter break
… need to check with candidates if they're willing to serve
… for the call for input, says we should invite from W3C Community, especially TAG, AC, AB, and chairs
… there was some worries on our side, if we receive 200 messages for input that could take even longer to process all of that
… because this is first time to do it, will be an experience!
… Process does say "should", it's not a "must"
… we'll see if we're getting late on that or not
… but for us to be ready by Feb 1st, we have to propose those names to AB/TAG by mid-January
… because we have to run a secret ballot
… I'm asking Team to not complain about the Process being complicated yet, just to run it first and then run post-mortem
… and then see if anything needs to change in the Process
fantasai: I think this will be easier if you issue call for input along with announcing election, because at that point at least you know the candidates
florian: you have to wait to decide because point of appointments is to balance diversity of the TAG, need to know who gets elected
… but you have some hints, knowing already the existing TAG and the candidates
plh: We're working internally to figure out what skills we need
… and also who should be able to see the input; concluded that entire Team can see it
… also decided who in the Team would make the decision, that was an internal matter also
plh: ok, let's move to other issues
Liaison
<joshco> w3c/
github: w3c/
joshco: At TPAC we had breakout for WAT group wrt home automation
… building implementation/integration that supports WAT
… in those discussions, one thing that because obvious, is that ? adopted by a lot of commercial devices in smart home mark
… does it make sense to see how W3C WAT can co-exist with MATTR?
… asked if we have a liaison with CSA, and apparently there isn't
… so what do we do? Can a CG do? what's the process to enable those kinds of discussions
florian: Originally I opened the issue
… in my view liaisons are a good thing
… having documentation about how we manage them would be good
<plh>
florian: but what Process says right now is not very useful
… so I was tempted to remove it
… it doesn't strictly define what a liaison is, just says that they must be coordinated by the Team
… but it doesn't say what they are!
… if instead of deleting we can make this useful, that's also OK
… as far as documenting liaisons in non-normative way
… we have a page on the website that does a reasonable job of it
… but significantly more useful than Process
plh: I do believe liaison needs to be coordinated by Team
… don't want CG to open a liaison that might be harmful, to claim to have an official liaison
… group can reach out to other orgs, but not on behalf of W3C
… in practice, we rely on our WGs to deal with technical liaisons directly
… our web page talksa bout activities, should say groups specifically
… that way know to go to chair of a group
… keep in mind that staff, even though listed there, doesn't necessarily mean liaison is active
… or tracking what the other org is doing
… just a point of entry -- that person would know status, at minimum
<joshco> for ref: https://
plh: if some of our Members involved in that liaison, they would know as well
<joshco> for ref: https://
plh: coordination with Dingwei last week, would be nice if we can list Member particpatns involved in those conversations
… e.g. have experties in ISO
… I'm open to it, didn't think through yet
… idk if the Process needs to say more at this point, but open to ideas
joshco: agree, CG, shouldn't go off and randomly create liaisons
… but what would be needed to make liaison happen?
… Links I posted in IRC
… DSP4003 is process for its alliances (liaisons)
… for each alliance, a work register is laid out
… things that would need to be presented to Team
… blurb on organization it's liaising with, area of work items, etc.
… a bit more detail than W3C's table
… I would say for Process, it might be helpful to be more specific about what groups should do to create a liaison
… put this in the document and send to apropriate people
… in this case, maybe understanding [missed]
… we had discussion in CG and didn't know what to do
florian: wrt CGs, a MUST statement in Process, process doesn't apply to CGs
<Zakim> fantasai, you wanted to suggest a link
fantasai: Doesn't apply to CGs, but liaisons are defined here, so CG can't make them without following this process
<plh>
fantasai: maybe just the link to this page is enough, seems to define the various details
joshco: where are CGs defined, ifnot in Process?
florian: I guess we can keep the text in the Process, if the requirement about organizing through Team is useful
florian: if you all think we should reject my issue to remove the text, I won't complain
… but what do we do about documenting further, where does it go? Process or that web page?
plh: The must should stay.
… and joshco, you might want to contact Dom to ask for guidance for liaisons through CGs
joshco: or ?? activity could establish liaison
plh: yes, can establish liaison on our official page, regardless of whether involved in a W3C group
… not required to be through a group
RESOLUTION: Close 422 (remove paragraphs about Liaisons) with no change
plh: if we need to add more documentation, let's open a new issue