Revising W3C Process Community Group Teleconference -- 22 May 2019

<scribe> ScribeNick: fantasai

dsinger: Adjustments to agenda?

jeff: What are we going to do to get things done other than go through issues?

dsinger: Generally send it for informal review to the AC, then formal ballot after TPAC

jeff: Big question is how are we going to wrestle consensus on separate Evergreen modification to the process as an experiment
... Which we've been talking about for some months
... There's some folks who say we shouldn't do that, instead merge the Evergreen thoughts into the REC track
... The latter position is what I agree with, it's just a practical question of
... experiment can get done in a few moths
... merge into REC track would require more work
... not an experiment, could take years...
... Don't know how we're going to conclude on that

dsinger: My personal vision is that we'd do it as an experimental thing first
... groups would have to choose
... I think Mike and fantasai have a different opinion

cwilso: I have a strong opinion that we shouldn't add another complex path

fantasai: make incremental changes so we can do these kinds of updates

<inserted> scribe: florian

fantasai: I think we should just start making incremental changes
... the one thing we can do is address the case of registries
... and there are also a number of small things that can be done to the REC track
... and then streamlining the maintenance of REC documents
... in terms of the handling the patent commitment for incremental changes, we should add that to the Patent policy
... these are incremental changes that we can do
... doing something like a full living standards process like HTML has would be harder
... but it's not clear that we need that right now

<dsinger> so, in summary (a) Registries (b) Maintenance of Recs.

<inserted> scribe: fantasai

fantasai: We should first make these improvements to the REC track, then we can see what's the actual difference between REC and ER, and start to address that

florian: The first phase of the REC track, up to and excluding CR, is just as flexible today as anything we've proposed in ER
... So the need for ER certainly doesn't come from that phase, we wouldn't gain any flexibliity
... Then there is the transition *to* CR
... which I think is not heavy due to the Process, it is heavy due to lack of tooling
... At that point point we verify that we've followed the rules
... this is checklist time
... but the checklist process is very manual and takes a long time
... That's the first area where we start feeling the heaviness of the REC track process
... This is not addressed by the ER proposal
... They just "trust the editors" that they did the right thing, but there's no verification
... If our standards are standards rather than just good idea, it's because there's a process and verification
... This is what we verify at transition
... But there's no need for process changes, but for tooling
... The difference is after CR
... The process is very heavy for incremental changes
... There, the process can be made more flexible
... to allow small changes to REC etc.
... One thing that troubles me about ER proposal is
... it's unclear to me, what is the things that bother people?
... If it's the difficulty of incremental changes in CR+, I understand and we should fix this
... For previous things ...
... Are people saying we *shoudln't* fulfill CR criteria? I would worry about that.
... IF that's not the concern, then what matters is REC maintenance
... So I agree with fantasai that if we fix the IPR problem and REC maintenance
... either the problem will go away, or the essence of the remaining problem will become clearer

fwiw, I don't think it'll go away entirely...

dsinger: Should we adopt it post-REC or post-CR?

florian: ...
... I don't think CR->REC is that hard, it's mostly hard because of implementations
... It takes some work to demonstrate criteria have been fulfilled, but that's due to us having criteria not fulfilling it
... But once in REC, changes have too much process

tzviya: I agree with fantasai and florian
... But maybe separate issues a bit
... Many ppl have expressed concerns about maintenance
... Not just about ER vs REC, but also which group is working on maintenance
... We have to integrate this a bit with how charters work
... How does maintenance happen from a realistic perspective -- not just process, but who is doing the work?

<Zakim> jeff, you wanted to comment on folding in registries

tzviya: I doubt we will have many specifications that are WHATWG-style living standards

jeff: I agree with fantasai and florian
... in terms of all of the enhancements that are needed for REC track
... I also think that fantasai provides a very logical way to introduce them
... solve registries now, that's a burning problem
... then move to maintenance
... and also make sure that we have the changes to the Patent Policy
... that will clean up some of the patent issues
... I think they're not strictly related to REC maintenance, but improving CR time
... so I hear what they're saying
... But how does that address the broader set of requirements for Evergreen?
... If we do those enhancements, maybe that's enough for CSS
... But in the list of specs that plh posted that are looking for Evergreen
... There are vocabulary specs where folks are saying that the entire REC process is too heavyweight, we need a lighter process overall
... There are specs like CSP, that want to track what's going on in HTML
... and as HTML is on a Living Standard regime, they feel they need that as well
... I don't disagree with what you're saying, but these needs need to be met
... The other things not addressed by sequential things
... concerned with the time it'll take to get done
... We've been talking for two years
... we have a comprehensive proposal for Evergreen
... we barely scratched the surface with REC maintenance
... This is holding us back
... Third thing we need to be cognizant of is
... we are still a consensus-based organization
... there might be opposition to REC track updates or patent policy changes
... Recall that when we changed the document license it was very controversial
... got it through by making it experimental
... now everyone is happy
... we should do the same with the ER process

nigel: Would like to make a proposal
... This taking what Florian said and experimental side
... maybe what we can do here is not change the Process at all
... but introduce per-label feature labelling or CR
... this would be an experimental feature
... to say whether the feature has passed criteria for REC
... every so often can take a snapshot
... effectively a living CR
... It's not a change to the Process at all
... It seems to do kindof 80% of what people want
... and that Evergreen standards do

dsinger: hasn't been, thank you

plh: We've been there before
... Yes, it is true that everything in ER can be moved to REC track
... Can we do all those things this year? no
... We're not going to change patent policy for REC track between now and next year
... We're also not going to ship implementation that's partially implemented either
... Evergreen is way to experiment with new features of Process
... If we apply everything on Evergreen track to REC, then great
... But we can't
... And we have groups that right now need better process
... Might not be fully implemented, we have markers in Evergreen to say whether implemented or not
... Trying to do that to CR today is possible
... But you can't get to REC
... because process requires 2 impls
... Evergreen relies on chairs to evaluate work rather than Director
... Right now you can't publish update to CR without Director's approval
... As long as the chair estimates that editor is behaving within work mode of the WG, then no need to actually intervene in the middle

<inserted> scribe: florian

fantasai: I'm not saying we shouldn't do evergreen
... I am saying that we should incorporate the changes as much as possible in the REC track, so that we can see the difference
... I don't want to have a separate track where we haven't thought through the implications
... we should understand each difference, and the differences should be intentional and minimal

<jeff> +1 to understanding each difference and making them intentional

<Zakim> florian, you wanted to respond to jeff

<inserted> scribe: fantasai

florian: Jeff said earlier that the proposed approach will not address all requirements by all ppl who want Evergreen
... If the needs of these people are difficult of updating REC, then it would adress them
... If the problem is the maturity criteria is too onerous, then we must discuss that
... Do we need to reduce the maturity criteria?
... If what ER does is reduce the *checks* of those criteria
... Then not verifying is a weakness
... So are ppl satisfied with maturity criteria of REC track?
... and just want it easier to demonstrate that we've fulfilled them?
... Or do they want to reduce the criteria
... It seems there's a desire to call something a REC that is not as mature as a REC is today
... and that concerns me

<Zakim> plh, you wanted to answer fantasai

<nigel> +1 reducing maturity required for a Rec would disturb me too, as florian said

plh: I agree with fantasai, everything we can apply to REC track we should do so
... The part of Evergeen we want to apply to REC track from day one
... tooling for horizontal review
... We would look forward to deploy to REC track simultaneously
... marking to identify implemented features
... we would also want to apply to REC track as well
... I also believe, the more I thin about this, it might be good to restrict the experiment at first
... To either docs that are not on the REC track
... or documents that have already been published as REC in the past
... I do concur with Florian
... e.g. service-worker ppl would switch to ER right away if they could
... But I don't think it would be beneficial to switch to ER without first getting a REC of it
... My thinking is not apply ER to documents that haven't become REC yet
... and we have plenty of cases of such .next specification work

<Zakim> jeff, you wanted to clarify what he was saying

jeff: Florian asked two questions, so perhaps I misspoke
... so like to clarify
... First question was of the form, why do I think that the fixed REC process won't satisfy people that want something more lightweight
... I probably should not have been so definitive
... I actually don't know
... whether it will sasisfy those ppl or not
... So I don't know what that fixed REC process look like
... fantasai and Florian and nigel have a view of what that looks like
... Maybe once we have streamlined this, I don't know how it will turn out
... Not so much that I was saying that these specs will never be satisfied by REC track
... My opening marks are that we want to get to a merged process ultimately
... I just don't know if we'll getthere, it's too early
... And I think it'll take a long time
... Is this Evergreen process going to shortcircuit review and consensus required to become a W3C REC?
... I think that's a fair questions
... I'd like to get ppl raising issues against the parts of the ER where it's an issue
... But we're having this meta-conversation instead of raising issues

<Zakim> mchampion, you wanted to agree that "maturity criteria" is the key question to focus on for all flavors of Evergreen

jeff: Hasn't gotten a lot of issues, if no issues let's move forward. Otherwise let's raise issues

mchampion: That was exactly what I was going to suggest. Way ahead is to focus basically what florian said
... What is the entrance criteria for ER? How do we fit it into experimental process?
... How do get wide review to become credible standards?
... How do we move from ER to REC at some point?
... Those questions are independent of a lot of things we've been arguing about
... If we focus on definition of what ER state looks like
... and see if anything approaching consensus then move forwar

<Zakim> nigel, you wanted to respond to plh that if you want to add labelling and features to Rec track anyway try doing that before introducing evergreen

nigel: plh said he wants to bring feature-labelling to REC track anyway
... If goal is merged proposal is the end goal
... Maybe ER track isn't something we don't need at all
... It's odd to give micro comments on something you don't think should exist
... Why not add some of these techniques, labelling, tooling, etc.
... Move the Process towards the actual desired end-state, not some mid-state
... If you create a bifurcation, it's very hard to bring things back later
... What you end up doing is having a fight later
... I don't think anyone wants that

nigel++

<dsinger> I see two “high nails” and an undefined area. (a) the pain of wide review, and the wrongness of its timing and (b) maintenance. Registries are undefined.

dsinger: The thing that ? about Evergreen
... It's very painful to document wide review

<jeff> [Jeff notes to Nigel that the bifurcation already happened; it's called the WHATWG and we should find ways to prevent further bifurcation.]

dsinger: and idea that you can ignore spec until it's in CR and then say it's flawed is problematic

fantasai: getting rid of LC was suppose dto fix that

dsinger: Should do ongoing review
... We know we have a maintenance problem
... Causes specs to languish
... Don't define how to manage registries
... So we need to work on this
... I don't want to keep losing specs to WHATWG

<dsinger> we need a (the same?) review process for Registries (ongoing)

dsinger: So for registries, I think we need the same kind of incremental review
... Obviously

<dsinger> note on contribution license. we need to formulate the question for PSIG.

<nigel> [Nigel notes to Jeff that is exactly the situation he was trying to avoid repeating]

dsinger: contribution licens, I thought we need to modify membership agreement?
... We need someone to ask PSIG, we'd like ppl to contribute license for contributions
... How is the easiest way to get there?

florian: ...

<dsinger> Is this an alternative to revised rec., or replacement? if it’s post-CR, how does one do the CR-Rec. transition? Maybe easy if the group feels it’s easy to add post-Rec.?

dsinger: I'm unclear form Florian and fantasai if we have an alternative or replacement of REC?

fantasai: ...

florian: We would fix the process so that the act of revising a REC isn't that painful

<plh> qq+

dsinger: Evergreen standard is only expected to have implementation commitments, not actual implementations
... I think that in some sense is similar to IETF RFC
... My request is to Florian, fantasai, mike, chris, can you write up in the wiki
... a non-alternative approach?
... What specifically would we do to make this work

<cwilso> sure

dsinger: We might want to go this direction, but need to see it written down

sure

plh: Want to make one last point on Evergreen
... So, I don't know if ppl remember when we updated our document license, how long it took us
... took 2-3 years to do that
... We were only talking about the license of the document
... Took a long time bc if we allowed to fork, would be end of the world
... I think we will face similar opposition
... I can't see happening within 12 onths at minimum
... patent policy...

florian: My problem with ER are the ways it is different are undesirable
... Yes we get something faster, but it allows us to drop the quality. Why go there?

dsinger: Let's not rehash argument, cuz running out of time
... Can we get a writeup of the alternative approach to an alternative track?
... Who's going to take the lead?

fantasai: Florian and I can take the lead

dsinger: Other issues?
... PSIG told us to go ahead and delete sentence about TAG in the process
... anyone disagree?

<dsinger> https://github.com/w3c/w3process/labels/Agenda%2B

dsinger: Anything you're blocked on?

RESOLUTION: delete sentence about the TAG

florian: Someone to ask Wendy to respond to issue 243, we're 1 comment away from being able to close

<dsinger> https://github.com/w3c/w3process/issues/243

ACTION jeff Ask wendy to respond on the issue

<trackbot> Created ACTION-52 - Ask wendy to respond on the issue [on Jeff Jaffe - due 2019-05-29].

jeff: I don't actually understand where we ended on the ER meta-question?

dsinger: fantasai &co will write up for the next call what they mean by an alternative approach
... what specifically do we need to do
... for the revising process approach
... We have 4 people who push that, asking to write it up -- what exactly do you mean by that

jeff: So next call we'll have "fix the process" proposal and we'll have the "evergreen experiment" proposal
... An we can look at both of them, see how they solve use cases and what time frames seem possible
... and then figure out what to do next

dsinger: we won't eliminate all choices, but roll a lot of evergreen aspects into main process
... evergreen plus snapshots, or rec track, choice for maintenance
... I think we need to see what they look like, A or B?

florian: I think direction we characterize is good, might take more than 2 weeks for all details

dsinger: Please read the issue on Registries
... There's some proposals there, should be relatively straightforward
... Other ppl need to give input
... Read what's in the wiki, read what's in the issues, and give input
... Any other agenda+ issue for today?

fantasai: Next telecon is 3 weeks, not 2 weeks from now

dsinger: OK, yes, it's the 12th

We have this Webex for every wednesday, so all calls will be on this number

(and we can schedule additional calls)

<dsinger> https://github.com/w3c/w3process/issues?utf8=✓&q=is%3Aissue+is%3Aopen+milestone%3A%22Process+2020%22+no%3Aassignee

[dsinger said]

Issue 270

<dsinger> https://github.com/w3c/w3process/pull/270

nigel: No notes on group decisions by vote
... does that even make sense?

florian: Yes, appeals of decisions by vote should be possible

dsinger: Yes, this is important

nigel: OK, will add comment on review comment

dsinger: If there's a debatable decision at any point, regardless of how arrived, should be able to take it to a higher authority

<Zakim> nigel, you wanted to ask quick q about #270 if there's time

Meeting adjourned

- DRAFT -

Revising W3C Process Community Group Teleconference

22 May 2019

Attendees

Contents

Issue 270

Summary of Action Items

Summary of Resolutions

Scribe.perl diagnostic output