<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/
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.)[End of scribe.perl diagnostic output]