Meeting minutes
Administrative
plh: Not meeting during TPAC
plh: Any topics to add?
Pull Requests to Merge
Add REC maintenance to diagram
github: w3c/
PR: w3c/
plh: Any objections to merge?
RESOLUTION: Merge
Explicitly mark figures as non-normative
github: Explicitly mark figures as non-normative
PR: w3c/
RESOLUTION: Merge
Deal with procedural disagreements within the Council
github: w3c/
florian: This has happened once. I was chair of a Council, where Council could not agree about what it was allowed to do.
… disagreement wasn't about the merits of the case, but whether we were allowed to rule on the question
… as a chair I had no way to resolve, and no one to appeal to
… if we all agree after some discussion, it's fine
… but if we can't find consensus about what we're allowed to do, then what?
florian: Proposal is to have the council vote on this, and then write it down as part of the decision, and AC can appeal if necessary
… could do without writing into the Process, but when it happened to me as a chair of the council, I failed to unlock the situation without a rule to base that resolution on
… luckily in that Council we found a workaround
<cwilso> -1 to Florian being a bad Council chair. :)
plh: One thing is what do we do in this case. Other is where do we document it.
… in a WG, when there's disagreement about the Process, the chairs turn to the Team and ask Team to interpret the process
… the Team is tasked to provide interpretation of the Process, which allows us to move forward when Process is not clear etc.
… if you disagree with the Team, we say raise an issue against Process
… We do this all the time; the Team interpets the Process.
… sometimes we even disagree with the Process editors, but we discuss and find a consensus
plh: The Team doesn't really participate in the Council. Have a Team Contact, though, so can ask the Team Contact to provide an interpretation. Could have a discussion, but can do the same.
… other solution is to have a vote to resolve the matter
… my worry is consistency among the councils
florian: Required to write it down, so at least precedence is documented
plh: Those are the two paths. I suggest instead of documenting in Process, document in Guidebook
<plh> fantasai: having the Team making the call makes more sense than doing a vote in the Council
<plh> ... will give more flexibility
<plh> ... and we should document in the guidebook
plh: Team would be having a conversation, not just making a decision.
… and will likely end up in Process or Guidebook issue, to document the question better
florian: I'm unconvinced that asking the Team will help
… but what if some members of the Council don't accept the Team's advice?
… However putting it in the Guide is a reasonable place to start.
… Not certain it provides enough gravitas, but might.
… if disagreements, then chair can decide what to do
… but either way, should document in the report
… But anyway, put it in the guide so it's not the chair making things up seems reasonable
plh: Regarding the Team, can only involve if it's about interpreting the Process.
… as it applies to operations of the Council.
… if it's about the material of the FO itself, then that's different
florian: Example is, FO against a decision. If you sustain the decision, it undoes the decision.
… but might not be clarity on what the decision is, or what the consequences of upholding vs overturning the FO means
… Council has a limited scope in what it can do
plh: Maybe Team is not seen as sufficiently neutral in some of these cases.
fantasai: I think the Team and the chair together would be sufficient for resolving questions about interpretations of the Process
plh: I would be OK with putting Team in the guidebook. Can make a recommendation to the Chair, and then it's a Chair Decision.
florian: Yes, let's just document that this is something you can decide about, and if you do mention it in the report
plh: Yeah, let's document this in the Guide
[dicussions about drafting Guide stuff]
RESOLUTION: Put something in the Guide
Tighten the how subtantive changes are handled post AC-Review
github: w3c/
PR: w3c/
florian: Practice isn't too far from this
… areas of difference are that if you increase the scope, you must go to AC
… also bring clarity about when people disagree with changes that are proposed after AC Review intended to resolve an objection
… most people happy with those changes, a few are not, then it's a weird situation
… people who disagree with the proposed changes can disagree without making an FO, and then what?
… what does that mean?
… can we overrule their non-formal objection?
… makes it clear that if you disagree, it counts as an FO, and existing Council gets to rule on it
TallTed: the "may only" phrasing, is usually restrictive
… to entirely clear if that's intended
florian: I intended a restriction. If you don't have consensus, you cannot adopt.
TallTed: then suggest "only if" instead of "may only"
florian: sure
plh: wfm
fantasai: wfm
[haggling over wording]
fantasai: For the second one, agree that it reads "better" in an absolute sence with it moved, but the reason it's pulled forward is to emphasize that phrase since the sentence is about this particular timing of the FO.
RESOLUTION: Accept PR with only in "may only" moved to "only if".
Issues to Discuss
Should member submissions be removed from the Process?
Github: w3c/
florian: People complain that the Process is too long. Most of the text needs to be there, but some of it maybe can be removed.
florian: Member Submissions seem like that kind of thing.
… They don't need to be in the Process, really.
… Team could retain ability to put stuff on the W3C Website
… Putting these in the Process guarantees the right to make a Member Submission
… ~4 pages of text, seems like a lot for what it does
florian: Once upon a time, this was how you started work at W3C. But CGs largely make this redundant.
… One thing that makes Member Submissions interesting is that Members are required to say whether they would license relevant patents
… Not sure we need to keep this, suggest to delete this section.
plh: If we remove from Process, no longer guaranteed. Up to Team what they do about it.
… I would be ok with moving to Guide
… but would want to ask others about it
florian: We could simplify the section. Say that you can do this, Team says how you do it. The current formalism is very heavy
… there's a lot of formalism about it
plh: We would want to keep the formalism. We've had situations [missed]
… if it moves into Guide, becomes responsibility of the Team
plh: Member Submissions is a Member right, so unsure.
TallTed: my experience of Member Submissions is that historically they were a way to skip a level of incubation and proceed directly to a WG.
… not so much being used as a turf declaration, although that is an aspect of it
… Member Submission becomes a tacit admission that this is a valid way to handle a thing, rather than just spitballing
… I don't know that they're completely useful today given CG
… but also not sure they're entirely useless
ACTION: plh to ask around about removing Member Submissions
florian: The maintenance cost isn't very high. Mainly changed only by e.g. introduction of the Council
… but there's the cost on the readers, makes Process longer
fantasai: What if we move most of the formalism to Guide, and just keep the minimal bits in the Process
… like the patent commitments, and which decisions can be objected to, etc.
florian: Note that Member Submissions are mentioned in the Patent Policy
cwilso: I'm in favor of just dropping Member Submissions as a thing.
… don't seem to add anything over what you can do in a CG
… and despite the text saying that publication implies no endorsement, probably is taken that way
tantek: I have actually some experience with this
… when Social Web WG formed, there were a number of submissions by organizations offering in theme of "please base on this work / be compatible with this work"
… these submissions were all offered royalty-free
… none of those organizations participated in the WG
… the effect the submissions had was a whole bunch of IP that those submissions covered were given to the WG
… E.g. OpenSocial was submitted, it was huge across many companies
… idk if it impacted specs, but it gave people some level of confidence and less fear that the stuff we were designing / speccing would overlap with existing IP
… idk if that's worth keeping the whole section of Process, but that was a positive use of Member Submissions
… idk how often it occurs, but having Members who aren't interested in participating in WG but want to enable them to build on their work, it's useful
<plh> fantasai: we don't have to remove Member submissions. we could narrow it down to what really needs to be there and push the rest in the Guidebook
florian: so we keep that it exists, patent policy applies, any disagreements get kicked to council
<tantek> +1 fantasai, florian
plh: ok with me
plh: Sometimes easier to do a Member Submission than spin up / join CG
… for the purpose of providing IP
<tantek> +1 plh agreed, it was easier for these orgs to do the Member Submissions than join the IG/WG (and get review for that)
florian: OK, so we have an action item to replace the text with something minimal and push the rest to Guidebook
ACTION: florian and fantasai to create minimal Member Submissions section and push non-critical text to Guide
<plh> https://
TPAC
plh: No meetings scheduled for ProcessCG
… and no proposal for breakout so far. Could make one if you want.
… two breakouts relevant to us
Simplifying the Updatable REC Process
Registries for W3C Specifications
florian: Wrt simplifying updatable REC process, 3 buckets
… 1. not actually about Process. About improving tooling or practices
… 2. let's simplify steps in the Process, without changing end result
… e.g. like removing PR stage
… still have same requirements, just the path is a little different
… I think there's some amount of process we could make here
… but different from "look at how simple things could be if didn't need consensus" or "look how simple could be if we didn't need implementation experience"
… which would change what a REC is
… 3. simplifications we could make if we change properties of a REC, e.g. don't need consensus / horizontal review / patent protection / implementation experience
… no reason we can't explore that space, but don't disguise that as procedural adjustments
<plh>
plh: Thread on Chairs list about Charter Refinement Phase
Proposed W3C Process Change: Charter Refinement Phase
plh: we're going to trial this for CSSWG and ???
plh: Also [missed], which like CSS is huge, and new WG
<Zakim> tantek, you wanted to suggest if someone wants to discuss "How to make living standards work at W3C" since no one has gotten this right yet AFAIK
tantek: wrt TPAC ideas, could ask how to do living standards at W3C. Have yet to see it done in a way that works. E.g. charters try to do this, but have nonsense exit conditions, etc.
plh: see breakout about updateable REC
florian: There are a few small-scale successful applications. don't know about any large ones.
plh: agree we still need to prove we can do it successfully; that's what this session is about
tantek: simplifying process would be really boring
fantasai: breakout is about making updatable REC more workable, not about redesigning the Process
plh: I think we need to still learn from our current Process, and try to make it work
<TallTed> I'm very interested in the topic of living/evergreen standards and/or updatable recs. But must jump to next call.
plh: if we can't, then we can go back to drawing board
Meeting closed.