<scribe> ScribeNick: fantasai

Agenda-bashing

dsinger: Changes to agenda?
... PRs?

florian: Unrelated to ET, no, but related to ET, have several issues.

Scheduling

jeff: AB intends to review and hopefully approve Process 2020 at our F2F 3rd week of February
... That gives us enough time to send it to AC review in March
... prepare a final revision in April
... and send for final review in May
... We have 3 Process CG calls between now and then, one is today
... we made a commitment to our membership that we would revise process in open CG
... accodingly, highly desirable if prior to AB meeting that there is a CFC in this CG
... and consensus that we have a document that CG believes is suitable to forward to AB, and ultimately AC
... If CFC is 2 weeks, hard to put CFC on the 12th, because ends during or after AB meeting
... so that means we should have CFC sent out to ourselves, this CG, two weeks from today on Jan 22nd
... Hard part: we have a lot of work to do if we want to be able to do that
... I listed in a private email to dsinger 4 major categories
... One is EverTeal, but did Process CG ever formally validate this direction?
... was editorial copyedit of document

fantasai: Copyedit vs editorial edit are different things

jeff: I mean both
... Third is Registries
... Fourth, nice if Patent Policy, effort with PSIG, hopefully incorporate
... Those are 4 big things we should just see if we're all aligned on, can we get it done in the next week
... if not, what does that mean for ultmate schedule?

florian: Wrt registries, I think dsinger and I need to meet and discuss
... beyond that I don't think we can say much on this call
... Wrt edit run, as far as I'm concerned
... there is some work that needs to happen once the edits stabilize
... beyond that, we could tweak wording forever, but I'm good
... Jeff has provided a significant amount of feedback
... I think most of it has been addressed
... unsure about consensus on a few points, hard to evaluate with few people
... anything left should be raised as individual issues to track

jeff: I think they've been sufficiently addressed for P2020, address in next revision is fine

florian: This group was tasked at last call with accepting the refactoring of Section 6
... and hopefully also the process itself
... At this stage, if someone disagrees with the whole idea
... need to say now
... if not the case, I think we should merge the branch
... and oepn issues on the remaining bits
... Not saying there aren't any, but we need to merge the main text
... note, leaving registries aside separately
... If there are raised issues, we can address, but blocking issues that aren't raised aren't possible to address!

jeff: So goal is for Jan 22nd is cleanup, aside from registries

florian: That's my hope. Would not be surprised if there are one or two other issues, but hope there are not many undiscovered problems.

dsinger: I printed out the various branches to review over the break, but didn't get around to it
... At this point, right to time me out on refactoring
... Looking at issues against EverTeal

<dsinger> list here https://github.com/w3c/w3process/labels/Everblue%2Fteal

dsinger: Issues raised by Florian, fantasai, Wendy, jeff -- that's the inside team
... I'm afraid we aren't getting AB views on this, or even AC
... Our CG workmode is good for small incremental changes
... This kind of very large change on the Process is not suited to this modus operandi
... If this was a spec, we would be asking people to implement and make sure we wrote it right
... Looking for a thorough review
... Don't think we're getting that from outside the core group
... and that's a problem
... Lastly, are we in sync to have Patent Policy and Process to approve together?
... So these are my concerns
... Do we need an F2F of the Process CG? Do we need an appeal to the AC for review?
... What do we need to do get more review?

florian: Agree too few ppl involved
... but don't have a time machine
... but we can get those who are involved in consensus
... resolve the various sub-issues

<plh> +1 to collapse

florian: and declare, "as far as people who've been involved, this is the proposal"

<Zakim> jeff, you wanted to partially agree with David but suggest that we can't address it at this point in time.

florian: being in a stasis, with various open PRs etc., is hard for people to review

jeff: I agree with both what dsinger and florian said
... Wrt whether right way to revise process in this new decade, that's on the AB F2F agenda
... but for Process 2020, I think ship has left the port
... F2F would be harder even to show up than a call
... Agree we don't have substantial review yet
... But proposal has been well-socialized
... Been on last few AB F2F agendas
... Been on AC agenda
... Imperfect, but it's where we are
... We'll have another opportunity for substantial review
... send it to AC in March, requesting 4 weeks review feedback
... Then we can revise in April
... and send for actual approval after

tzviya: I tihnk there's been more feedback than you're realizing
... Been discussed in AB numerous time
... Feedback from ppl who work extensively in specs
... Have been additional comments
... Jake did a testing of the revised process, which is more than we expected
... Recognize there has been feedback, and move on
... Wrt CEPC, the CFC got more feedback than I was expecting
... Lots of editorial nits
... But won't see as much feedback as you want until later in the game

dsinger: Not suggesting we stop the train, but how do we get more people on board
... So sounds like, Jeff, we should write an email to AC and urge ppl to review early and often
... Please get involved, this is a major rewrite of our fundamental process

jeff: Can time with CFC
... when we send for approval ourselves, we can CC AC, chairs

<Zakim> dsinger, you wanted to suggest Jeff and I send a message to the AB and AC saying where we are, and it’s time to look (after the section-6 re-factor merge)

florian: I generally agree with what dsinger said, but I would want to do more than just the refactoring merge first
... Do the whole merge
... and set up diffs
... Because as long as main proposal are in a side branch, changes to it are pull requests on top of pull requests
... which is hard to manage
... This is what we're moving forward with, let's put it as the main branch
... and file issues againt that

dsinger: If people comment now, we can change more easily
... harder to know if comment gets addressed
... In side branch, can take even minor edits

jeff: Florian, are you proposing that we get all the changes into the main branch by the 22nd?

florian: I'm proposing that we resolve today to merge what we have now
... and between now and the deadlines you have on the calendar, we solve remaining issues
... based on resolution of AB that we are going in this direction, and the amount of review, we should merge this into the main branch

<jeff> Fantasai: Side branch makes it harder to edit and raise issues

<jeff> ... PRs on top of PRs

<jeff> ... more confusing to work with

<jeff> ... we should merge all the changes and take issues against what's there

<plh> +1

<florian> +1

<jeff> ... we have one item we are working against

<jeff> ... more people will then work on it

<tzviya> +1 to merging

<jeff> ... merge refactoring, ET, other issues

<jeff> ... not have multiple forks of process

dsinger: I can't work out why I'm uneasy about merging, so I'll defer to majority

jeff: I don't think you should feel bad about being uncomfortable, there's a lot going on, but agree with Florian and fantasai we have to merge and move forward

florian: and worst comes to worst, we're in source control, we can always back out

<wseltzer> no objection

dsinger: So proposal is to merge section 6 refactoring and EverTeal branch into main working branch

+1

<jeff> +1

RESOLUTION: Merge section 6 refactoring and EverTeal branch into main branch

<florian> https://github.com/w3c/w3process/labels/Everblue%2Fteal

jeff: Now we just need to make as much progress as we can on the open issues

Issues on EverTeal

florian: I think our resolution closes Issue 344

fantasai: Yeah, I think we did just close that, should we close the issue?

dsinger: any objections?

RESOLUTION: Close 344 as accepted

https://github.com/w3c/w3process/issues/344

florian: Next issue is https://github.com/w3c/w3process/issues/358
... Seems that Jeff and I agree we can address in next revision of Process, so suggest we defer this one
... Issue is, since previous edition of process this structure, separating different types of edits to a REC
... We added section titles to these, and added the EverTeal provisions
... Jeff suggested some degree of merging
... I pushed back on this
... that even if possible, not do this year

dsinger: jeff?

jeff: Haven't managed to convince Florian I'm right, and this isn't most improtant thing, so fine with deferring

RESOLUTION: Defer 358 to P2021

Next is issue https://github.com/w3c/w3process/pull/359

florian: Minor editorial changes to stop using word "contributor", because Patent Policy wnats to use it
... PR approved by chaals
... and fantasai

changes at https://github.com/w3c/w3process/pull/359/files

wseltzer: Philosophically, not sure why, if we're using the same naming, shouldn't use the same term

florian: Not using the same meaning, that's why changing

wseltzer: ah, go for it then

florian: [explains changes]
... So that Patent Policy can define contributor as it wants to. If the same, no harm done, but currently it's different, so let's not conflict

jeff: Contributor License Grant section?

florian: Yes. But Patent Policy 2020 is looking to define contributor as subset of WG participant
... whereas here it's a not

<wseltzer> [to clarify, in PP, "contributor" may or may not be a WG participant]

jeff: Question to wseltzer and plh, today when we try to get a license grant, I assume we have some form somewhere?
... do we need to change?

wseltzer: Don't think we need to change, even to match that

dsinger: No problem with this particular change, so fine by me
... AB meeting when we discussed in Paris, I realized after the meeting, we never discussed whether we pursue idea of getting contributor grants from WG members WHATWG-style
... wondering if we should drop idea?
... discuss with PSIG?

<Zakim> dsinger, you wanted to ask about contributor

florian: Suggest avoiding deep dives into Patent Policy

dsinger: So this approve to merge, objections?

<wseltzer> [PSIG is currently looking at draft that includes copyright commitment]

RESOLUTION: Merge https://github.com/w3c/w3process/pull/359/files

florian: We're left with two meaty issue and an editorial one

Edited Recommendations

github: https://github.com/w3c/w3process/issues/362

florian: We have a thing called "Edited Recommendations"
... In previous Process, slightly conflicting definitions
... either way these things exist
... EverTeal has multiple ways to edit a REC
... Afaict Editorial REC in new process is just a REC with editorial changes since the previous REC
... Suggest removing this distinction

plh: I'm fine with making the change
... As you said, it's only an artifact of the Process
... On /TR, we never expose that
... If you're into transitions, well, which path are you taking
... but again, it's an artifact of the Process, and not shown in documents themselves

dsinger: I agree, don't think they should have a label of how they got to where they are
... By the time it gets there, it is a REC
... Agree not having label
... not sure to merge yet

florian: OK, at least we all agree, I will make a PR

<dsinger> Notes this is only 8 hours old, so we should allow wider/longer review

RESOLUTION: Remove distinction "Edited Recommendation", Florian to produce PR

Rethinking CR Snapshot/Drafts

github: https://github.com/w3c/w3process/issues/346

florian: I would like to close this as WONTFIX, because, roughly speaking, this is rejecting EverTeal and adopting EverGreen

wseltzer: I do not object
... Whether or not there would have been an alternate direction to go, nobody else is pushing strongly

<dsinger> I lost this argument at the AB, so though I agree with Wendy, it’s probably too late

florian: I would like also to mention that if later we realize this is a better direction to go in, we can make that change

plh: I do believe it's a significant change and changing later will be difficult, but no alternatives

dsinger: I lost this argument at the AB, so while I agree with Wendy, I don't think it's productive to keep pushing on it
... However a long discussion a month ago, a lot of contributors, good to review to make sure we didn't miss anything
... ...

florian: Suggest to close it, and if anyone thinks a side discussion yielded a relevant issue, we open a new issue for that

dsinger: I'd like to leave it open until the next call, with a comment that we plan to close it on the Jan 22nd call

florian: If we were to accept this, we'd have to do a major rework of everything
... so I don't think we can accept this

dsinger: agree
... Just check for comments
... Would like to address issue of naming?

fantasai: Currently renamed to "Candidate Recommendation Draft"
... Hooks in nicely to Patent Policy, which needs us to define it as a "working draft" for the resign clause to trigger correclty

RESOLUTION: Mark #346 closed on Jan 22nd call

jeff, that's cool, file an issue? :)

REC vs Extensible REC

github: https://github.com/w3c/w3process/issues/345

florian: There was a vague but broad consensus that having the distinction was nice for consumers, but slightly more confusing for producers
... But some concerns raised
... One was whether declarations in a Status section about intentions constrain a WG?
... and also what about existing RECs?
... I don't think we have a conclusion for this
... Various paths possible:
... 1. Keep proposal as-is
... 2. Erase the distinction entirely
... 3. Say that by default REC can't accept new features, unless Status section says they can
... 4. Say that by default REC can accept new features, unless Status section says they can't
... If other alternatives proposed, don't know of it
... Last time ended discussion as an open question

fantasai: if we make any distinction, even in Status section, would need to hook into Process to make it binding

<Zakim> dsinger, you wanted to comment on reverting in place

fantasai: ...

dsinger: Reverting REC to CR can be done, but deeply confusing, should never do that
... Also, should not do these major revisions to something that's currently a REC, not expected

jeff: I think there are two fundamental issues
... One is what do we call different amalgam of RECs?

<wseltzer> [I think any Rec should be able to version itself]

jeff: Other is how do we distinguish amogn them?

<wseltzer> [and the way you distinguish, if you care, is by a datestamp]

jeff: I think we're best off to have a single designation which is Recommendation
... whether came through Process cleanly, or whatever
... all of them should be Recommendation
... I think it's helpful by past history, and SOTD is very convenient, to have all sorts of metadata about history etc.
... we can stuff anything we want into SOTD
... that may not even need to be done in the Process document, can move all to pubrules

<wseltzer> +1 to Jeff

florian: I think what fantasai and Jeff said appear to be contradicting, but isn't
... I strongly agree with Jeff that documented where a spec came from can be documented in the Status section
... also having just one name for all Recommendations is good
... But issue here wasn't where something came from, but where it's allowed to go

jeff: Put that in the status

florian: There's nothing in the Process that binds you to respect that

jeff: You can put a throwaway comment into Status that "you must put such and such in SOTD"
... Just don't want to be overly prescriptive about it

florian: If you need a comment in the Status section when you want to allow new features, or when to disallow it?
... Opt-in means we don't automatically get new features on all existing RECs
... What I propose based on what I hear now, is to replace existing distinction of XREC and REC with note in Status

dsinger: I'm not sure I agree
... I tihnk outside world needs to know, formally this document is immutable, and formally this document is immutable
... Other standards orgs need to know, if the document is stable or if it changeable

<wseltzer> [they already have that immutability through the dated version]

dsinger: Perception of outside world

florian: Note that we don't have immutable RECs, can always take changes that aren't new features

dsinger: ...

florian: Are you saying that the distinction of REC and XREC is something we need to maintain?

dsinger: "Is this going to change out under my feet, or is this something that is essentiall stable?" is an important distinction

wseltzer: We have always and always will have dated versions, they don't change
... but document at tip-of-tree would reflect the group's latest thinking

plh: I agree with that

dsinger: We make it very clear that if you want an immutable document you use dated version URL
... I'd like to continue to study this

florian: I will still make a PR, so we can compare the two versions

Scheduling

dsinger: Out of time, anything else?

florian: you and I need to discuss registries

[discussion of scheduling conflicts]

[various people have conflicts]

[discussing moving to 29th]

RESOLUTION: Move next call to 29th to avoid various conflicts

dsinger: plan is to resolve registries

Meeting closed.

This is scribe.perl Revision: 1.154  of Date: 2018/09/25 16:35:56  
Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/

Guessing input format: Irssi_ISO8601_Log_Text_Format (score 1.00)

Succeeded: s/Third//
Succeeded: s/review/revise/
Succeeded: s/???/I do believe it's a significant change and changing later will be difficult, but no alternatives/
Succeeded: i/dsinger/Topic: Scheduling
Present: tzviya wseltzer jeff florian fantasai
Regrets: cwilso
Found ScribeNick: fantasai
Inferring Scribes: fantasai

WARNING: No meeting chair found!
You should specify the meeting chair like this:
<dbooth> Chair: dbooth

Found Date: 08 Jan 2020
People with action items: 

WARNING: Input appears to use implicit continuation lines.
You may need the "-implicitContinuations" option.


WARNING: IRC log location not specified!  (You can ignore this 
warning if you do not want the generated minutes to contain 
a link to the original IRC log.)