W3C Process CG -- 03 Oct 2018

<scribe> scribenick: wseltzer

dsinger: 172

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

florian: PR
... decision to advance should be based solely on technical maturity

<jeff> Wendy: You might advance to CR to memorialize a compromise

<jeff> ... advance the discussion

<jeff> ... even if not REC-ready

<jeff> Florian: Agree more subtle when you revise a CR

florian: this issue is only re getting to initial CR, not revising

dsinger: this loses the intent of original issue

florian: rephrased based on fantasai's comments
... there are cases where you need to invite implementation to figure out what's wrong with the draft
... "we've reached the point where we can't move forward without external feedback...
... though we know it's not rec-ready"

dsinger: but it needs to be comprehensible, well-written

florian: tricky to phrase
... Nigel and I were slightly disagreeing
... I think, WG can say "we choose to leave undef"

dsinger: PR is not quite ready, not urgent
... iterate off-line

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

dsinger: 28

florian: substantive change and editorial change are thus far defined only for specs, not charters and process
... 1st PR is to define these terms

<Zakim> wseltzer, you wanted to disagree

wseltzer: oppose adding new rules to the process

<Zakim> jeff, you wanted to try to find the text of the pull request

wseltzer: and I disagree substantively with some of this definition

florian: there wasn't previously a def of "substantive change to charter"

jeff: in charter review, we've typically said "if the Director believe that the change would affect a reviewer's disposition toward the review, it's substantive and needs further review"
... if it's just a change to delay a milestone by a month, don't believe that would change a reviewer's review, hence non-substantive
... verbiage here re "timeline of deliverables" considered substantive, way more restrictive, replacing judmgent by rules

florian: for now, Director has 3 options: editorial-fix, substantive-fix and say why, substantive-return for re-review

jeff: asking for explanations could be good, but replacing judgment by rules seems problematic
... and there's lots of text

mchampion: recall this was a concern of CSS
... sympathetic to their concerns and to Jeff's points

florian: second PR is to disallow Director to change, even with explanation

https://github.com/w3c/w3process/pull/218/commits/51cf8326190055962dc4472eb1c69f5270dfde95

florian: CSS concern arose from question of changing work-mode
... post-AC-Review, the charter was changed to use external incubation
... which many of us found a negative change
... and it was used by some group participants to argue for other changes
... so I want to disallow changes

dsinger: let's take this to offline discussion

<Zakim> jeff, you wanted to ask whether a "may" would be substantive

jeff: I worry that this proposal gets into semantic detail
... in CSS case, Director thought adding a liaison was not changing workmode
... so it's not even clear the Dir would have perceived that as substantive change
... not minimizing the issue, but don't want to hit it with a club either

<dsinger> https://github.com/w3c/w3process/issues/117#issuecomment-420385595

dsinger: take it offline

<jeff> [there might be a more direct solution to the particular CSS issue.]

<dsinger> agreed to close

dsinger: close 117

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

dsinger: 207, consider as part of previous

dsinger: 204, continue offline

<dsinger> https://github.com/w3c/w3process/issues/183#issuecomment-420502598

dsinger: 183

florian: CSS wondered whether they had to go back and review all old things
... make clear that superseding is implicit when publishing with same shortname
... only need to invoke process when different spec

jeff: does supersede mean you're no longer recommended to use the previous?

florian: yes

jeff: consider HTML; 5.2 is Rec, but we haven't superseded 5.1
... deliberately

florian: different shortnames

dsinger: jeff is asking a different question from what the PR is addressing

florian: if you use the same shortname, you don't need to supersede

jeff: fantasai's comment re CSS2

wseltzer: language is still confusing

dsinger: 155

<dsinger> https://github.com/w3c/w3process/issues/155#issuecomment-413185877

florian: define FPWD
... there's nothing published on /TR and private, so there's no private WD

dsinger: accepted, move on

<dsinger> PR here https://github.com/w3c/w3process/pull/212

dsinger: 169

florian: don't imply that Member Submissions are only way to bring in outside work (cf CGs)

dsinger: hearing no disagreement, move on
... accepted

<dsinger> https://github.com/w3c/w3process/issues/9#issuecomment-426267002

dsinger: 9

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

florian: simple proposal

[[ A participant may represent more than one organization in a Working Group or Interest Group.

Those organizations must all be members of the group.</p]]

florian: this just bothers people trying to do the right thing
... so clarify

dsinger: accepted

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

dsinger: 208

wseltzer: I raised 208, I'm satisfied with PR 220

dsinger: accept and move on
... 39

florian: take it offline

<dsinger> https://github.com/w3c/w3process/issues/194#issuecomment-425351665

dsinger: 194
... should process talk about GH and other tools? question for AB
... real question, but propose not to hold it here
... 180

florian: described elsewhere, in CG/BG process
... in that PR, Chaals suggests incorporating by reference; wseltzer says no
... in either case, we can do that later if we want

dsinger: Process doc is how we run membership of consortium, not public groups

jeff: where did you put this into Process doc?

florian: last sentence of intro, W3C also runs CGs and BGs

dsinger: accepted
... 116, close and reopen more specific issues as needed
... where are we going from here?
... I know Jeff wants to talk about Evergreen
... but I'm frustrated that there's not much discussion
... from WGs, AB, etc
... don't want to hold the rest of Process hostage

jeff: I volunteered to add to Evergreen Standards doc some use cases
... I'd propose to focus on some use cases: AAMs and Vocabs
... I'd start by asking those groups if they'd find it useful

dsinger: I'd be delighted to hear from those groups

florian: I don't think we can resolve that whole issue before TPAC
... so I'd like to focus on how we publish what we have
... and I'm generally an evergreen skeptci

dsinger: so, what do we do with the current process
... do we want to aks AB to move ahead?
... proceed with open issues?

florian: as editor, I'll start compiling changelog
... don't think we have much more time

dsinger: is it the consensus of this body that we should put a new process to AC in 2018

jeff: 2 questions: is it advisable to move ahead without major change
... I don't think so, but won't block
... but in terms of going to AB tomorrow, think we're not ready
... should have the doc on which we wan t approval
... AB had commented no need to couple with TPAC
... send to AC when ready

dsinger: agree this isn't ready for tomorrow
... question to AB, whether to move ahead and on what timetable
... at TPAC, we could explain where we are to the AC
... 15min, and discuss expected timing

em> represent more than one organization in a Working Group or Interest Group.//em> represent more than one organization in a Working Group or Interest Group.

dsinger: jeff, can we add that to agenda tomorrow?

jeff: ok
... and if we want to raise with AC, need to figure out where

florian: Q&A sounds fine
... as editor, I think we have things worth proposing to AC
... would like AB to tell us when to do so, how much more time we have

<dsinger> Agreed: to establish a timeline with the AB, and present the current status and timelime to the AC around TPAC (in email, with a verbal pointer at TPAC)

[adjourn, meet next after TPAC]

wseltzer: regrets for Nov 14

- DRAFT -

W3C Process CG

03 Oct 2018

Attendees

Contents

Summary of Action Items

Summary of Resolutions

Scribe.perl diagnostic output