W3C

- DRAFT -

Process CG

13 Nov 2019

Agenda

Attendees

Present
jeff, wseltzer, dsinger, florian, plh, Anna
Regrets
tzviya
Chair
SV_MEETING_CHAIR
Scribe
wseltzer

Contents


<scribe> scribenick: wseltzer

dsinger: Agenda-bashing

jeff: an update on living standards
... presentation to the AC at TPAC on EverTeal
... generally supported
... Fantasai has now written explainer
... Florian is working on Process text
... Wendy has been conversing with PSIG
... who are waiting for AB signal
... AB plans to take this up at meeting next week
... would the chair be willing to have a CfC on the CG that Everteal has the directional support of the CG
... while holding off approval until we have text

dsinger: sounds as though we should do pre-flight for AB

florian: explainer is primarily from POV of user of the process, once approved
... should we have another doc explaining to somoeone whether they should approve
... e.g mailing list discussion of extensible vs rec
... should we put issues into process flagging options

dsinger: when we present to AC, it should have rationale
... why we did particular things

annamweinberg: as a PSIG participant
... be mindful that any minor change to patent policy can have large ramifications
... helpful to understand why each change is necessary
... what's the concrete real issue behind that change

<Zakim> jeff, you wanted to discuss RECs, Extenstible RECs, and Elastic RECs

annamweinberg: enable PSIG to revise PP to address concrete issues with minimal disruption

jeff: suggest someone who really understands current proposal speak 1:1 with Anna
... re rec types, don't think we need to resolve before we choose direction of Everteal
... that's the kind of detail that can be described later
... I'm pushng for "Elastic" over "Extensible" terminology

annamweinberg: while I'd appreciate 1:1, think it's not just me
... are there real examples of problems?

plh: re PP, when you have a spec being developed over several years, your patent commitments are uncertain pre-Rec

<annamweinberg> +q

plh: and pressure from other orgs, such as WHATWG, with more modular PP
... agree with Jeff we can decide later who decides what bit gets used

wseltzer: conveying concern from PSIG about the choice to work with updates to PP
... rather than an experimental track
... because it's difficult to evolve the single PP

florian: we're seeing an increase in specs that never reach rec, but wait in eternal CR
... possibly they don't intend to reach Rec, but want to remain flexible

<Zakim> dsinger, you wanted to say two things (a) things that take forever, or never, to get to Rec and formal license and (b) the at-risk (theoretical) problem

florian: so the PP should cover them at CR

dsinger: ^
... I'm not aware of actual problems, but those are the issues
... re scope of Process CG
... I need to talk with Jeff and AB
... I'm not so comfortable making policy decisions here, vs fixing bugs
... don't think we're the right place to decide e.g. for Everteal as the right direction

fantasai: as pointed out, we have specs that take years, 10 years, to get to Rec
... writing a comprehensive test suite for CSS2 or SVG is a lot of work
... takes a lot of time
... we require implementations in this time
... but there's not yet a patent license
... only a promise to grant at Rec
... we're lucky that hasn't caused problems

<Zakim> jeff, you wanted to comment on the scope of the Process CG

jeff: re scope of CG, in 2013, AB decided process should be done in public
... made CG the place that renewed versions of process shoudl be developed, with AB approval
... we've made substantial updates, e.g. process 2014
... AB approved and AC is decision body
... so helpful for CG to endorse direction

dsinger: who will explain the explainer?

Process 2020 Explainer

fantasai: we have an explainer

<fantasai> https://www.w3.org/wiki/Process2020

fantasai: overview of what's changed, how you use
... what's not explained well enough?
... apparently one is why do we need to update PP?
... walks through the wiki

https://www.w3.org/wiki/Process2020#Maintaining_a_.E2.80.9CLiving_Standard.E2.80.9D

plh: would it be helpful to have examples?
... working through a few deliverables/groups and the options they'd use

<Zakim> dsinger, you wanted to ask about HR

fantasai: I gave a few examples
... e.g. CSS Text horiz review

florian: could be a lengthy explanation for staging of a WG doc over time

dsinger: when do you send HR email to review groups?

fantasai: you need their approval to publish CR review snapshot or REC

<fantasai> it's not necessary for update drafts

florian: you need to prove it happened, doesn't specify when
... amount of technical change isn't new, but now trying to publish

fantasai: these requirements are for the streamlined review

<Zakim> wseltzer, you wanted to discuss snapshots

wseltzer: I thought the snapshot shouldn't have distinct requirements
... so it's easy to mint

fantasai: we need to have groups do review
... and we thought this was a convenient point for self-check
... useful to assure quality of work, wide review
... we don't want to require editor to do these checks at every point
... at every update
... it takes time, effort, worth doing just not every time

wseltzer: @@

plh: a concern I heard about evergreen was you could publish without review
... so we distinguished snapshot from CR update
... automatic publishing doesn't assume you've resolved all the issue

dsinger: wseltzer and I are both concerned about hte complex interlinking
... jeff, what shall we do with our remaining 3 minutes?

jeff: I'd like to get time for deeper discusison about this tradeoff
... help us crisp up the dispute

Next meeting

dsinger: let's not meet Thanksgiving week
... I'll poll the mailing list
... compare to the strawan starting point we had a year ago
... with a trust, verify, and back-out as needed for HR
... what are we buying in return for added complexity
... thank you, especially fantasai

[adjourned]

<jeff> thanks, David.

<mchampion> +1 to dsinger, going back to the WHATWG process as a strawman proposal then add more requirements for horizontal review seems like a more productive way forward at this point

Summary of Action Items

Summary of Resolutions

[End of minutes]

Minutes manually created (not a transcript), formatted by David Booth's scribe.perl version 1.154 (CVS log)
$Date: 2019/11/13 16:03:20 $

Scribe.perl diagnostic output

[Delete this section before finalizing the minutes.]
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/CSS/CSS2 or SVG/
Succeeded: s/update or//
Succeeded: s/review snapshot/review snapshot or REC/
Succeeded: s/be/have/
Present: jeff wseltzer dsinger florian plh Anna
Regrets: tzviya
Found ScribeNick: wseltzer
Inferring Scribes: wseltzer
Agenda: https://lists.w3.org/Archives/Public/public-w3process/2019Nov/0014.html

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


WARNING: No date found!  Assuming today.  (Hint: Specify
the W3C IRC log URL, and the date will be determined from that.)
Or specify the date like this:
<dbooth> Date: 12 Sep 2002

People with action items: 

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.)


[End of scribe.perl diagnostic output]