<plh> scribeNick: plh

Florian: plh and fantasai gave a presentation on continuous development
... (presenting the github repo)

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

Florian: everblue/evergreen

David: director-free isn't a Process 2020 but is a longer term project

Fantasai: improving the REC-track

<dsinger> Note that Director-free is a longer term exploration of what the Process might look like in the absence of a Director

Fantasai: nice to have patent licensing apply earlier
... CR or like
... number of use cases to improve the process
... goals
... simplify maintenance
... [Fantasai keeps going through the slides]
... proposal: update the patent policy, streamlining CR updates, and REC updates
... and add a dedicated registry process
... slides are at https://www.w3.org/2019/Talks/TPAC/continuous-standards/

Pierre: if the contribution doesn't make it in the full spec, there is no commitment, right?

David: the commitment would be indeed if it becomes part of the spec
... if the contribution doesn't make into the final spec, you only get the commitment to an early version

Florian: the patent policy of whatwg was derived from the CGs, and we're deriving it from it

Pierre: not everybody will be happy with it

Florian: when you rescind a spec, it's the same.

David: as long as you can point that you implemented that version, you'll be fine.
... chances that people will sue for implemting CR versions wil be low.

Pierre: here it says on each contribution
... is a pull request a document?

Fantasai: it would have to be published on /TR, not just a nightly draft
... details are still being worked out

<dsinger> I’m assuming that the commitment to contributions would be similar to the one we ask of non-WG members; that you get a license to the contributor’s IPR if you implement the draft that integrated it.

Fantasai: join PSIG to make your opinion

Florian: given that this is in the WHATWG policy, it seems a signal that it is acceptable

<dsinger> Indeed, if the feature doesn’t survive into Rec. you will not get full-spec. coverage that includes that feature.

Pierre: this is not a proper assumption imho

Chris: I would not compare this to the whatwg policy, because the workstreams are setup differently. a PR doesn't get merge until it stays in the spec
... but I would say that the goal is to not let you iterate without assurances on commitments
... the time period can be a decade

Pierre: in the case of whatwg, there is a very defined process....

chris: they managed their workstreams differently. it would be an improvement for w3c to update its patent policy nevertheless

Fantasai: the point is getting commitments earlier in the process
... [streamlining routine CR update approvals]

<tantek> This is a really good set of improvements (streamlining routine CR update approvals)

Travis: so, we have currently to do horizontal reviews, etc. the proposal is that ...

Florian: having done it once, you document this and you can publish

Travis: oh, so you're not locking again on a second review?

Florian: correct

Fantasai: as long as you didn't make change that would require updating the review

David: but who decide that?

Fantasai: details will be decided by the implementation

<Zakim> dsinger, you wanted to ask what this “routine” is? and how does someone decide what constitutes “routine”?

Florian: two parts of routine: we're not going to define how to make HR happy, you just don't have to spend continuously call for reviews. you just have to demonstrate that it happened

<inserted> scribe: nigel

plh: From the point of view of the Horizontal Groups, there's a wish to move away from the quality control aspects to one
... where you come as early as possible.
... The role is to allow WGs to go to HR groups as early as possible.
... So that it's easy to check the box on applying for transition

<scribe> scribe: plh

David: who gets to police if the Group did things right?

Fantasai: the Group needs to document and if they get caught, the publication can be revoked

Florian: WGs are supposed to be in consensus and the Team Contact should be paying attention

Fantasai: different process fixes can be taken up by the Process at different times

<fantasai> fantasai: although I recommend we adopt these all together to have a good Process

<fantasai> nigel: says if there's dissent from commenter, then blocked from CR?

<fantasai> fantasai: Not blocked, just can't use fast track -- have to get human approval

<fantasai> scribenick: fantasai

tantek: is there Process draft ext on this?

https://w3c.github.io/w3process/everblue/

https://services.w3.org/htmldiff?doc1=https%3A%2F%2Fw3c.github.io%2Fw3process%2F&doc2=https%3A%2F%2Fw3c.github.io%2Fw3process%2Feverblue

florian: yes, draft text for most parts
... exception is patent policy
... and the decoupling on next slide, not drafted yet

<plh> scribe: plh

<tantek> Thank you!

<scribe> scribeNick: plh

Fantasai: [Decoupling CR updates from CR review drafts]
... currently every CR updates trigger patent exclusions when you have to go through approvals, etc.
... lawyers don't like this to happen often

https://www.w3.org/2019/Talks/TPAC/continuous-standards/

Fantasai: folks are looking at unofficial/editor draft instead of looking at the official spec
... proposal is to have two types of CR publications: review drafts and updates
... updates wouldn't trigger patent exclusions/approvals
... and would publish a review draft on a regular basis for exclusions and approvals
... you can update as much as you want until you feel you need a review draft

Nigel: are the CR updates considered routine ones?

Fantasai: no, but you won't need the same level of approvals

Florian: for the updates, you won't have to prove everything, but you may get blocked for a review draft
... no checks, fast track or not happen on an update

David: if you publish 2 review drafts 2 months apart, they both trigger a call for exclusion?

plh: you need a minimum duration between 2 review drafts

<nigel_> ack

<Zakim> nigel_, you wanted to ask if the CR Updates are always "routine"?

Pierre: so, you'll have a CR updates, and CR review drafts?

Fantasai: yes, changing state would be misleading

Florian: going back would signal a lower quality, so wrong signal

David: why is this not like WHATWG with doing a review draft every 6 months?

Fantasai: because it's not automatic. you still need Director's approval

Pierre: today, you could do WD, WD, CR, then realize you forgot a feature, go back to WD, ...

David: why not doing a call for exclusion everything 6 months?

Florian: there is no point in the whatwg when someone checks the work done properly

<fantasai> plh: previous slide was about reducing overhread of asking Director's permission when everything is fine

<fantasai> plh: this is about facilitating publication of ED on /TR page

<fantasai> plh: so that people can show their latest work on the ?TR page

<fantasai> plh: without requiring Director approval every time they want to update the draft

<fantasai> plh: if you want a call for exclusion, you have to do what we do today which is to get a transtition approval from the Director

<fantasai> plh: we're not going to force WG to do that every time they want to update CR

<fantasai> dsinger: then you could just publish forever, never get a patent review draft

<fantasai> plh: max 24 months you can do that, you need to get patent review

<astearns> May be better to say these things are seperable

<fantasai> pal: CR means two things to an external organizatioN: quality, and patent exlcusion

<fantasai> pal: CR Update means WD with quality level of CR

<fantasai> nigel: There's later on an inline errata system for REC, why not do that instead of just make change?

<tantek> "Edited CR" - parallel to "Edited Recommendation"

Nigel: why not doing the updates as annotations?

Fantasai: when doing a lot of linked small changes, annotations would be confusing. it's easier to do that in Recommendations. For CR, it's hard, based on my experience as CSS editor.
... having annotations would make it impossible to read
... there is an encouragement to document your changes from review draft to review draft
... [modifying a Recommendation]

<tantek> This looks good, except keep the existing "Edited Recommendation" phrase in the process

<dsinger> The documents that result from CR updates *are* of different status from CRs; they have had horizontal review waivers, no director review, and no exclusion opportunity.

Florian: because we're calling reviews on a subset of the changes, other could be kept as annotations

Fantasai: [allowing adding features to an extensible REC]

<Zakim> nigel, you wanted to ask why a charter-level pre-agreement is needed to be extensible

Nigel: can we simply let the wg decide?

<vivien> I was wondering if this update of REC proposed fix is going to replace Edited Recommendation and Amended Recommendation https://www.w3.org/2019/Process-20190301/#maturity-levels

Fantasai: we want to get AC review

Nigel: why?

Fantasai: because it depends on the community.

Nigel: how can the AC know the community better than the WG?

Fantasai: because it's a broader set of people

Travis: the distinction between REC and extensible REC, you'd do a new revision but it takes time

<nigel> I think we should check that out a bit more, who is best to decide if a REC should accept extensions

<fantasai> Travis: From working on HTML, we just revved version number when adding new features

<fantasai> Travis: Main problem was it took so long to get REC, maybe just shortcut process for getting to new REC from old REC

<fantasai> Travis: instead of changing meaning of REC

<fantasai> fantasai: I like that proposal

<fantasai> AC poll - https://www.w3.org/2002/09/wbs/33280/improved-pp-2019/

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/NIgel/Nigel/
Succeeded: s/foals/goals/
Succeeded: s/retire/rescind/
Succeeded: i/plh/scribe: nigel
Succeeded: s/Floran:/Florian:/
Succeeded: s/NIgel/Nigel/
Succeeded: s/udpates/updates/
Present: CharlesHall dsinger Rachel Nigel_Megitt Mek plh cwilso florian Lauriat cb tantek jorydotcom
Found ScribeNick: plh
Found Scribe: nigel
Inferring ScribeNick: nigel
Found Scribe: plh
Inferring ScribeNick: plh
Found ScribeNick: fantasai
Found Scribe: plh
Inferring ScribeNick: plh
Found ScribeNick: plh
Scribes: nigel, plh
ScribeNicks: plh, nigel, fantasai

WARNING: No "Topic:" lines found.


WARNING: No meeting title found!
You should specify the meeting title like this:
<dbooth> Meeting: Weekly Baking Club Meeting


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: No "Topic: ..." lines found!  
Resulting HTML may have an empty (invalid) <ol>...</ol>.

Explanation: "Topic: ..." lines are used to indicate the start of 
new discussion topics or agenda items, such as:
<dbooth> Topic: Review of Amy's report


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