Meeting minutes
David: anything to add to the agenda?
[none heard]
Issues and PRs
https://github.com/w3c/w3process/issues/418
https://github.com/w3c/w3process/issues/312
https://github.com/w3c/w3process/issues/432
florian: those are still suggestions. didn't look further lately. don't think we're far however.
Jeff: didn't have a chance a look at it yet. hard to follow the context
[discussion about the clarity of the changes]
<fantasai> https://github.com/w3c/w3process/pull/432/files
<tantek> I have to admit the interspersed diffs and comments are confusing
<tantek> can we see a cleaned up diff please?
<jrosewell> Note: For another time. Document changes are generally better done with document collaboration solutions like Google Docs or Word Online. It would make handling these sort of issues easier.
<tantek> this is not normal for pull requests
<tantek> jrosewell, I strongly disagree
https://github.com/w3c/w3process/issues/455
Fantasai: we don't really use the term "maturity level"
… was thinking about changing the second part of the term to "stage" or something similar
<jrosewell> +1
Fantasai: it would be easier to use the term outside of the process
<jrosewell> Making the work of the W3C easier for others to follow is very important change.
Fantasai: I avoid using "maturity" outside of the process geeks
<tantek> +1 fantasai, "maturity level" is process wonk jargon and should be dumped
<tantek> +1 for "stage"
Tantek: +1 to drop "maturity level" from the guide etc. and to adopt "stage"
Jeff: [looking around for instances of mautiry level]
<jeff>
fantasai: if we just use "stage" that will cause confusion, but "maturity stage is an improvement
<tantek> drop "maturity" completely please, it's jargon in this context
David: ok, let's expect to move to maturity stage
Fantasai: we have existing documentation talking about maturity, so we can't drop it. but outside of the process document, folks could use "stage" as a shortcut to "maturity stage"
<chaals> [ -1 to dropping the "maturity" - which is pretty much used according to its natural language meaning. Whether we say level/stage/whatever is something I personally don't thinik really matters.]
<tantek> would prefer just "stage" (like TC39), but can live with "maturity stage" (expecting the "maturity" will be dropped like a vestigial appendix eventually)
Superseding
<fantasai> github: https://github.com/w3c/w3process/issues/324
david: we saw recently a survey to supersede JSON-LD 1.0
… that's something the WG can decide
… my suggestion is to allow groups to supersede their own spec with a new spec
David: (read his proposal)
florian: I dont' feel the urge as strongly but support the proposal
<Zakim> chaals, you wanted to speak against the proposal
chaals: don't think we should do this. this seems procedural.
… there are cases where WGs might think the world moved to change a new version and the world disagree
… the AC is moderately a reflexion of reality in this case
… it should still be an explicit review
… in your PR review, you may do this
<fantasai> plh: There were two aspects of the proposal which helps with chaals's concern
<fantasai> plh: One is if ... and we forgot to task the AC as part of its review.
<fantasai> plh: Second, it only allows WG to do that if there is a newer version
<fantasai> plh: There's no newer version if you don't have a REC that's been approved by the AC
<fantasai> dsinger_: We're talking about superseding, not obsoleting
<chaals> [Yeah, I do want the AC to have that specific review]
david: we're not talking obsoleting, just superseding. both versions remain available and there is always a long transition for the market to update
… it is just a statement of the fact that there is a newer version
chaals: unconvinced but won't block consensus if I am the only dissenter
<Zakim> dsinger_, you wanted to respond to chaals
florian: if the AC feels strongly about something
<jrosewell> Agree with @dsinger that there is an established norm to transition from one version of a specification to another and it's up to implementers to decided when to transition from one standard of interoperability to another.
florian: you can state that in the charter
david: yes, and you can always object after the fact
fantasai: can we require an announcement to the AC list. give a 2/3 weeks to allow for objection, otherwise it passes.
david: yes, that would work
<fantasai> s#2/3#2-4#
florian: you can't apply it today since it calls for an explicit AC review
[some wordsmithing]
<dsinger_> acj jeff
david: ok, will leave it open for cycle but we're converging
<chaals> [One reason I don't think this is a critical issue is because we have gone a couple of decades without solving this minor part of the versioning problem, so taking a couple of years to normalise superseding doesn't seem like a terrible problem.]
<fantasai> [I could go either way. I neither feel strongly that we need this, nor that we should not have it.]
jeff: today, we do an AC review and if no one objects, it goes through. we're now proposing a notification now. looks like we're adding a new process because of a mistake
david: there may be a long tail of things that should have been superseded but too much process to go through
florian: for the notification, it heard it was just announcement but giving the opportunity for folks to object
david: asking trivial questions, we diminish the visibility of other surveys
jeff: seems like we want to fix a mistake by process
<tantek> +1 right we don't need anything now for this, just more practice with superseding and obsoleting
david: ok, then maybe we don't need the second sentence
florian: we're already doing the first sentence by practice
… so, we may not need to add the first sentence
jeff: close the issue?
david: I'll leave it open but it's now a candidate to close
… with no action
Process 2021 milestones
<dsinger_> https://github.com/w3c/w3process/issues/38
florian: chaals was objecting to the concept being proposed. I'm leaning towards closing it while we look at the broader question
… so close it with no action
<fantasai> https://github.com/w3c/w3process/issues/38#issuecomment-658794831
fantasai: what about updating the process to ack the current practice?
florian: ok, I can make an editorial proposal
Action: Florian to propose an editorial update for #38
<dsinger_> https://github.com/w3c/w3process/issues/63
<tantek> Is there a vision / motivational summary paragraph for Process 2021? Or are we trying to extract meaning from the weeds of specific issues? (yes, besides Registries, I realize that's a big goal for 2021)
david: #63 is now a duplicate of #38
… we'll close both
Clarify the Voting Process
<fantasai> github: https://github.com/w3c/w3process/issues/60
jeff: we're missing the folks who were objecting to discuss this
<tantek> issue 60 has better chance of being resolved in the AB than in ProcessCG
jeff: this issue is getting hidden greater issues.
… we have layers of confusion. would be good to find out if the AC supports the council
… and then comes back to this issue
james: council is meant to replace the Director?
david: for the formal objection only
florian: only one role of the Director
plh: and the AB is conducting an experiment with the council
david: I'll propose to close this issue at the next meeting
<dsinger_> https://github.com/w3c/w3process/milestone/6
david: we have over 35 issues on P2021....
florian: not all of them are priorities. if we don't get to the others, we'll push them along to the next version
david: looking for specific proposals
david: for wide reviews, we need to progress
plh: I'll take #130
james: for my part, I expect to make proposals/issues at the middle of November
<chaals> [Thank you James for planning that effort]
david: ok, so post-TPAC we should look back the progress
https://github.com/w3c/w3process/issues/167
florian: it overlaps with the Director free process
… not sure if it will solve it however
jeff: good chance that things will get worst giving the number of engines
… but, in the absence of a proposal, I'm not sure how to solve it
… something vague to give the Director flexibility to use their judgement
… maybe we close the issue and re-open if things change or we get a proposal
… it pushes us to make more definition where it doesn't seem necessary
florian: maybe a guideline?
jeff: maybe we should push the work on guidelines to somewhere else
… as a way to avoid cluttering our agenda
<chaals> [I think there would be a need to think about how you are going to run such a group. There is already an open github repo that can be used for the work, but it isn't clear how changes get taken in…]
florian: it will clear the agenda but won't reduce the work
<jeff> [Good point Chaals. I was thinking of proposing PLH to chair the guidelines group and have them meet at the frequency that he thought would make sense.]
https://github.com/w3c/w3process/issues/236
fantasai: "Draft Notes" ?
https://www.w3.org/TR/?status=ret
florian: concerned about the mixing of documents on the REC track and those that are not, due to patent policy implications
david: we can do some clean-ups
Next meeting
<fantasai> Strong +1 to separating the tracks by adding "Inactive Draft" & "Draft Note" or whatever
David: November 11
[adjourned]