– DRAFT –
W3C Process Community Group

Pull Requests to Review

Consolidate similar parts of REC revision

Github: w3c/process#878

Florian: we're makingtweaks to an already approved charter

TallTed: you can use "in" or "as" but not both

Florian: or use therein

"may be annotated therein as candidate additions"

"tentative new features may be annotated therein as candidate additions"

"tentative new features may be annotated there as candidate additions"

Florian: I'll take the rest and we'll go back to GH for the rest

Shift most discussion of Workshops to /Guide

Github: w3c/w3process#876

plh: sgtm

RESOLUTION: Merge #876

Making the Council's short circuit a little more flexible

github: w3c/process#852

florian: Discussed the rigidity of unanimity for the short circuit.

florian: even if not everyone has responded, should be good enough if almost everyone

florian: AB suggested clarifying that there must be a minimum time period

florian: not close the poll right after reaching the minimum threshold, but allow those with a negative opinion to have time to respond potentially

florian: If at the end of the poll enough people have responded and the respondants are unanimous, then we take it

florian: I went with 80% and 2 weeks

florian: but we don't have a firm resolution about timing and threshold

plh: I'm fine with the PR except for "must be open for two weeks"

plh: should say "at least"

plh: to allow for a longer timeframe

<fantasai> +1

florian: if you don't get to the threshold, then you extend.

fantasai: Still worth allowing an extension of two weeks

florian: if we extend, who decides?

plh: you have to rely on the Team

florian: so, "at least two weeks, at the discretion of the Team"?

fantasai: There's still the clock running for convening the Council

fantasai: so you can't go for, e.g. 7 weeks

florian: So proposal is to accept with "at least two weeks"

plh: if AB or TAG wants to argue about timing, can have that conversation with Team

florian: I think AB was mainly concerned about being too short

florian: not a short circuit if it takes too long, but as fantasai pointed out the Council will start

florian: OK works for me

florian: Is 2 weeks good? is 80% good?

plh: I'm fine with them. Did we inform TAG about this change?

florian: didn't specifically, in general they leave process stuff to others

plh: Merge with "at least", and discuss next week to confirm

RESOLUTION: Merge w3c/process#885

with addition of "at least"

Retire Proposed Recommendation

github: w3c/process#861

florian: [short explanation of the REC track]

florian: PR is odd because it's not a state at which the document is edited. It's just a way to mark the spec version that's being voted on.

florian: we had a similar phase called "Last Call Working Draft", which we removed

florian: for similar reasons, we're proposing (now with support of AB) to drop the Proposed Recommendation stage.

florian: This doesn't change any of the requirements to go from CR to REC

florian: but just removes the intermediary PR phase

florian: Drafted up at w3c/process#868

florian: some comments to discuss

florian: First comment is that "proposed recommendation" no longer exists in the Process, so if you get linked to the Process there's no explanation

florian: Nigel suggests an Appendix that lists stages of the process that used to exist

florian: Seems like a good idea, maybe in a separate PR, add as a glossary that points to the versions of the Process that defined the term

plh: In terms of linking from /TR, we use dated versions of the URL already

plh: because publication is anchored within the Process as it was at the time of publication

plh: so that solves most of the problem

fantasai: I think it's a nice idea to include, even if we don't have a linking problem, people will have heard about these terms and good to be able to find them in the process

florian: so I can take an action to draft as a separate PR

https://www.w3.org/standards/types

ACTION: Florian to draft appendix of defunct Process terms

plh: maybe that document also needs an appendix...

florian: Next comment is from Ted suggesting editorial rephrasing... but I think the text is moved, not new.

florian: Nigel doesn't like the rephrasing

TallTed: fine either way

plh: let's drop it

florian: Thanks to re-ordering of things, something that was true already became more apparent:

florian: once a spec reaches REC, you can no longer add new features to it. Going back to CR doesn't change that.

florian: to add new features, you need to go back to FPWD

florian: We did add the ability say "this REC can add new features", which allows it. But if you didn't have that the first time around, you're locked.

florian: Nigel suggests a note to highlight that you would need to start a new FPWD.

florian: but note would be as long as the thing it's pointing to, so I'm worried about the Process getting wordy...

TallTed: wouldn't be the first if you revert

florian: No, you'd need to start a new document -- can't revise the existing one

[some discussion about wording]

<TallTed> https://www.w3.org/policies/process/drafts/#rec-track

fantasai: I think maybe if we move the definition of expandable REC into the "revising" section, this paragraph can be simplified into a pointer to that paragraph

florian: You can go back from REC to WD, but you can't add new features.

TallTed: But currently from PR you can go back and add new features.

florian: [explains what's allowed again]

florian: Point of this is that if you are an external consumer of a REC, you can assume that the REC will never have new features.

florian: and that's not new

florian: So could either link sections better, or move the paragraph elsewhere.

florian: Felt it worked better in this section because it defines a type of REC, not something about the publication process

<florian> fantasai: we should try to move most of the paragraph

<florian> fantasai: I get the idea of having the definition of different kinds of recs upfront

<florian> fantasai: but the rest of the details should go into the "revising a rec" section

florian: sounds good, let's try

plh: wfm

<TallTed> at https://github.com/w3c/process/pull/868/files, the diagram needs something that points back to FPWD, possibly labeled "when adding new features to RECs that aren't marked as accepting such"

<fantasai> TallTed, no because that's not the same document. You need to start a new draft for that.

<fantasai> The diagram represents the transitions of a particular technical report

florian: Next point, we have a bullet list and "after all criteria are fulfilled, the Team does things"

florian: Nigel suggests that the verification things are initiated by WG request to advance

florian: We already require that in the bullet list

plh: I'm for simplicity

plh: It's a requirement for advancement. In practice, we're keeping the transition request just a different transition request

plh: The Guidebook will remap everything

fantasai: I think Nigel is just requesting that we clarify that the WG request is a WG Decision.

florian: [quotes document]. Add "This is a Working Group decision"?

TallTed: "may *decide* to request advancement"

florian: fewer words, I like it

ACTION: Florian to clarify that the request for advancement is a WG decision.

ACTION: Florian and fantasai to shuffle expandable REC text around

florian: OK, I'll work on those. If you want more changes, comment!

fantasai: Should we give the AC a heads up about this change?

florian: Maybe wait until we have slightly more solid wording?

fantasai: Should give enough heads up that they have time to absorb the idea before TPAC, and if we wait until next Process call then we're in the middle of August

fantasai: I'll post to AC Forum, as an informal heads up.

florian: Include chairs@

ACTION: fantasai to post FYI about removing PR to AC Forum and chairs@

Interaction with AB

florian: Does this group have things we should raise to AB?

[AB F2F is next week]

florian: We've put the chartering PR on the AB agenda. Conversation was a bit confused last time, so hoping it goes better this time.

plh: TAG nomination process might be discussed also, but need to discuss there first before here.

plh: So we might get stuff from AB/TAG after the meeting

plh: I hope AB will make progress on incubation and 3 I's (independent interoperable implementations)

Issues to Discuss

Adjust AC appeal vote threshold based on participation

florian: We discussed having a recall procedure for AB/TAG (separate from CEO disciplinary)

florian: and how it would be similar to AC Appeal

"5% or more of the Advisory Committee support the appeal request"

florian: and also similar to Bylaws

florian: Interesting point is that the threshold for passing changes depending on quorum

florian: If < 15% of Membership participats, you need 75% majority

florian: 15-20% you need 2/3 majority

florian: Above 20% quorum, use simple majority

florian: For AC Appeal, and also for other momentous decisions like that, would make sense to have something similar

florian: I think it's a good idea to adopt this concept -- and for simplicity, use the same thresholds as the Bylaws

Scheduling

plh: Going to miss the next few meetings

fantasai: I can probably handle the 24th

plh: Thanks for progress, it's slow but progress nevertheless!