W3C

- DRAFT -

Revising W3C Process Community Group Teleconference

13 Mar 2019

Attendees

Present
tzviya, dsinger, cwilso, natasha, plh, jeff, florian
Regrets
Leonie
Chair
SV_MEETING_CHAIR
Scribe
natasha

Contents


<scribe> scribe: natasha

Agenda Bash

agenda+ label issues

<dsinger> https://github.com/w3c/w3process/labels/Agenda%2B

dsinger: #235 ready to go?

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

florian: we're in agreement, looking good

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

dsinger: lets leave for 1 more month, and deal offline

<dsinger> on #235, all, please review and we’ll deal with this finally

florian: #239 desent in process means formal objection, we should stop the incorrect use
... this pull request removes the incorrect use

dsinger: removing agenda+ label

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

florian: ... #243 address later please

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

florian: #245 publish is strictly defined as put something on TR, so removing inconsistent use
... i think we agree

<tzviya> +1

dsinger: removing agenda+ label

florian: #246 plh seems happy with this. Any comments?

plh: we may publish Team Submissions in the future, but does not need to be part of the process

florian: the definition is buggy, so suggest to delete rather than fix

dsinger: leaving for now

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

florian: #250 a sentence not really doing anything. chaals is rephrasing

dsinger: any concerns?
... #254 could take some time

florian: director is mentioned throughout the process. Some places director is repeated, some places the director is stated to do a thing but this is already being delegated
... this suggestion doesn't change the power of the director
... I am happy to wait, but please review

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

dsinger: we may decide to do this as part of the changing role of the director generally, we will see

florian: #259 deleting "proposed recommendations" to the sentence
... chaals agreed

<fantasai> wfm

dsinger: agreed to delete

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

#79 Process supporting "Living Standards"?

dsinger: hope everyone read the wiki

https://www.w3.org/wiki/Evergreen_Standards

plh: wiki put together to make a more concrete proposal
... proposal is to add 2.5 additions to the process
... Preliminary Draft - similar to WD
... Evergreen Recommendation
... then a subset of ER, like a snapshot
... there are parallel tracks for previous REC track and ER
... trying to find balance to publish often and early with reviewing

<dsinger> process draft is at https://www.w3.org/2019/03/Evergreen.html

plh: we don't expect a horizontal review to happen before publishing
... the community should decide that there has been enough review
... the wiki explains tooling to do this

<dsinger> (note that horizontal groups include AC and team, in a sense)

plh: we have struggled with formal objections
... REC Track has director involved to manage formal objections
... but we do not want to stop the group publishing, and so how does the group manage to deal with formal objections

<jeff> [The formal objection discussion is in 6.11]

<dsinger> [The Wiki mentions FOs briefly in https://www.w3.org/wiki/Evergreen_Standards#Review_tooling]

plh: and then what happens if the group does not agree or meet the satisfaction of the director regarding formal objections
... comments?

jeff: we could put it in the header until resolved

plh: three options in the doc

jeff: three options: one says group must stop until agree with the director - this is similar to the REC Track
... second is the group can keep publishing but they cannot snapshot; seems a good compromise but then we could end up with no IPR protection
... third is we note there is a formal objection, the director could disagree and "mark" the document, but the group can continue

florian: value to allow for fast publication when there is consensus; formal objections is group agreeing with itself. I worry about a process which allows for the editor to continue when the group disagrees

jeff: the group is still required to have a procedural consensus that the editor must respect; otherwise the editor is violating what they are supposed to do

florian: depends on how procedural consensus is defined; I still worry about this

<plh> [[

<plh> The Working Group ceases its work

<plh> The Working Group is no longer allowed to publish an ERS

<plh> The document header indicates that the Director disagrees with some parts of the document

<plh> ]]

florian: I don't want it to be too easy to ignore dissent
... option 2 doesn't work because organisations care about IPR commitments

<Zakim> cwilso, you wanted to discuss role of chair

florian: formal objections help push the discussion to happen

<jeff> [So Florian prefers option 1]

cwilso: the role of the chair - seems superfluous in this

<florian> +1 to cwilso

<dsinger> +1

cwilso: they should have a stronger role for maintaining consensus

<fantasai> +1

<tzviya> +1

plh: how to declare consensus - we left it open to be defined in charter or for group to make that decision

cwilso: more concerned with the role of the chair; even in a non ER working group, the chair should strive for consensus

plh: I agree, chair responsible for the model on achieving consensus in the group
... not sure we have to add this to this proposal

<dsinger> (hearing a lot of traction for stating clearly that the chair determines and establishes consensus of the WG, and that the draft must represent the consensus of the WG)

cwilso: I read this as the chair didn't have those responsibilities

jeff: there is emphasis on what the chair is not supposed to do
... please feel free to send additional text as you please

dsinger: hearing consensus for suggested text on chair is still responsible for achieving consensus based on their stated method

<florian> ever green should not mean drastically changing everyday. Establishing consensus on a ER, which is supposed to be somewhat sable, shouldn't be any harder than on a WD, so I don't really see a need to differ from the REC track here.

dsinger: back to formal objections
... can we insist the draft in the github repo states a formal objection has been made and so the doc cannot be snapshotted or get IPR commitments - the doc is "on hold"

<florian> a?

dsinger: so then the formal objection is being maintained

jeff: ah so your use case is that the formal objection has been raised so the ER is on hold?

dsinger: if there has been a ruling on the objection that should not be ignored
... the group would have to return to a state of where the formal objection has been resolved, otherwise on hold

jeff: ah so you're suggestion is for after the ruling?

dsinger: yes.

jeff: do we put group on hold until the formal objection has been ruled?

dsinger: no, so after the ruling if the formal objection still exists then the group must strive to resolve the formal objection

<jeff> [DS conclusions: If Director rules in favor of objectors, document must go back to state without objection.]

dsinger: so only after

<Zakim> florian, you wanted to support david's proposal

florian: support of dsinger option "4".
... formal objections do not happen often.
... if we have a large spec then it may have more formal objections, that may be good as it will result in a more modular approach to spec development

plh: another approach was to add the TAG into this loop

<dsinger> [option 4: while the FO is pending, unresolved, it is noted in the WG’s WD and the ES in the document header. After FO decision, the ES document must be one that is not subject to the FO, either by returning to the state preceding the FO, or by resolving it to teh staisfaction of the Director]

<florian> jeff, FO can already stop publication. They're not that common.

plh: not sure they would want to do this; but it might be good to find a way to add some entity in this loop to aid the Director

<dsinger> [of course, if the Director denies the FO, we’re done]

<fantasai> I'm a little confused about the option numbering... I think recording the formal objection in the document close to the objectionable text and allowing work to continue while the Director is reviewing the issue is fine.

plh: we try to get to issues before they get to formal objections

<fantasai> Once the Director has decided on what should be done, then blocking publication until it has been fixed seems appropriate.

plh: it could take a long time for objections to be resolved

<Zakim> tzviya, you wanted to ask for clarification about why consensus is different in this case?

tzviya: theory of consensus should not be different from a standard REC track group
... I believe some comments on consensus should be added

<florian> +1

tzviya: or note that it is the same as the rest of W3C

<fantasai> +1

dsinger: tzviya please work with cwilso on the text for this

fantasai: I agree the consensus should be the same; the proposal seems overly specific on describing the work mode of the WG. Those details should be left to the WG as in the current Process: we should be specifying the requirements of what shows up in an ER publication, not how it gets there

plh: shall we create a repo branch for this?

florian: it's ok as it is now

dsinger: we can avoid merge conflicts this way and see changes more clearly
... I hear consensus for when a formal objection has been raised that there is a note in the header which states this, but then a ruling may mean the work is on hold

fantasai: it would be good for it to be added in the location within the document so readers are aware that there is a formal objection and where to go to see more information

<tzviya> +1 to fantasai

<plh> +1

dsinger: plh I will work with you on this

jeff: this is extremely important, so lets make sure we get this right
... raising an issue in an issue is a problem; I'll leave to the chair to think about offline
... dsinger has a wiki on registries and how they relate to evergreen standards
... working on adding something which states how the ER process can be helped with proper registries
... looking for people who are willing to use this as an experimental process
... we have asked people to work on the Horizontal Review issue, and there will be tweaks on this going forward

dsinger: please take a look at the registries work
... we will present this to the AC as something they should be following
... plh is making a presentation to the AC!

<Zakim> florian, you wanted to discuss closer proximity between REC track and ER track

florian: mike champion commented that we could work on merging the REC Track and ER track - work for another time
... ER stage and CR stage are at a similar level, so we can explore this

plh: preliminary draft was being called WD for some time but there was some difference
... CR difference is the horizontal review

dsinger: let's take this to github

<fantasai> https://github.com/w3c/w3process/issues/79

fantasai: are you talking about the patent policy issue and trying to improve patent policy? I would be interested in this.

dsinger: me too
... this is our last call before our AC meeting

jeff: wseltzer has crafted some wording on patent policy for ER track
... probably no conclusions before AC meeting

dsinger: can we delay next call for 1 week

<jeff> april 17 WFM - but PLH on vacation

jeff: let's take to doodle poll

dsinger: thank-you all!!!

<jeff> Natasha++

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/03/13 15:02:36 $

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/use/incorrect use/
Succeeded: s/resolve/result in a/
Succeeded: s/look/loop/
Succeeded: s/???/fantasai/
Succeeded: s/should be the same/should be the same; the proposal seems overly specific on describing the work mode of the WG. Those details should be left to the WG as in the current Process: we should be specifying the requirements of what shows up in an ER publication, not how it gets there/
Default Present: tzviya, dsinger, cwilso, natasha, plh, jeff
Present: tzviya dsinger cwilso natasha plh jeff florian

WARNING: Replacing previous Regrets list. (Old list: Wendy)
Use 'Regrets+ ... ' if you meant to add people without replacing the list,
such as: <dbooth> Regrets+ Leonie

Regrets: Leonie
Found Scribe: natasha
Inferring ScribeNick: natasha

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

Found Date: 13 Mar 2019
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]