<scribe> scribe: natasha
<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
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++
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]