Ever{Green,Blue} -- 22 Jul 2019

<inserted> scribenick: RalphS

<fantasai> Assumptions that are wrong in plh's email (cursory review, not very thorough)...

<fantasai> Living Recommendation being distinct from Recommenndation. It's not, it's a subset.

Jeff: thinking about the upcoming AB meeting ...
... overall summary of the approaches

<fantasai> Time to publish a new Recommendation being 90 days... not true, reviews are parallellized so it is not more than whatever minimum the AC and legal want

Jeff: itemization or characterization of the differences
... can we identify lead authors for each of those pieces?

<fantasai> Everblue doesn't provide contribution licensing... not true. It doesn't require it, it's designed to work within the current patent policy if needed. But it is part of the Everblue plan.

PLH: I've started an overall summary of the approaches

<fantasai> Everblue doesn't provide handling of registries. Also not true. It has special handling of registries.

<fantasai> This is all laid out very explicitly in https://www.w3.org/wiki/Maintainable_Standards

<fantasai> and has been for the last month

PLH: would appreciate help from Fantasai and Florian

Florian: there are some pieces where we've not yet reached blue/green understanding

<fantasai> It seems like that page has been ignored entirely by plh when writing up his thoughts.

Florian: the patent story for EB
... apparent reliance of EG on tooling that doesn't yet exist (issue raised last meeting)
... PLH's draft comparison of EB/EG just shared has some mischaracterizations

PLH: I looked at only the proposed Process changes, not other out-of-band information

Elika: that's not a fair comparison as the patent policy changes were only provided for EG

<fantasai> Elika: And the registries edits for Everblue were also ignored

Elika: e.g. there _is_ supposed to be a Contribution License in EB just as in EG

PLH: I didn't mean to be unfair; I just chose to look at only the proposed Process

Florian: we can discuss piecewise but our goal was for both teams to understand both proposals

Jeff: we can fix the methodology; this was PLH's first draft
... a useful feature of having a single presentation including both options is that it allows us to be very clear about what we're comparing

Florian: I'd like to explain the EB patent story
... shortly before July 8 I sent email to PSIG chairs and w3c-archive
... once we fix all the things I perceive to be bugs with the EG patent policy I think we will have also addressed all the EB patent issues
... adding contribution license
... making the license apply on the whole spec at the end of the exclusion period, not waiting until REC
... for EB we need to agree on what are called "review drafts"
... given that we said we want to fix Rec Track in any case, we'll want to add both these features
... so we should fix the EG patent policy to also apply to Rec Track
... this shouldn't be hard
... I've not yet reaceived a response from PSIG, though I know Wendy has forwarded the emails
... once these bugs are fixed the differences between EG and EB patent policies are very small

Jeff: I don't agree
... starting with the philosophy behind EG
... EG starts with the POV that we don't know whether the Membership overall is willing to change the W3C Patent Policy
... EG leaves open the possibility that they will agree to change the PP
... the comparison between EG and EB patent policies is more clear if we state that EG wants a solution even if we don't change the Patent Policy
... so an Evergreen Rec is "weaker" than a Recommendation

Florian: I agree with this, so let me clarify
... EG doesn't assume that the legacy PP will be discarded but it does assume the community will accept an experimental new PP
... we can make such an experimental PP work for both EG and EB
... the details are in my long email to PSIG

Jeff: how can it work for both?

Elika: we're pvoding an alternative PP and each charter can state which PP it will use
... we're proposing to write the PP in terms that are general enough that it can apply to Rec Track as well as the new tracks
... the Process would say what a legal review draft is and let the charter specify which patent policy it operates under

Jeff: if the AC doesn't agree to change the PP then we can still proceed with EG
... in my experience the Membership has not wanted to touch the Patent Policy
... so EG says that for Rec Track we'll continue to use the PP
... and for the experimental path we'll have a lesser standard that uses a different PP

Florian: mu proposal is that WG charters could state which PP they'll operate under

Jeff: that changes the fundamentals of what companies give licenses for

<fantasai> But with the Evergreen proposal every group can *already* make such a decision.

Jeff: this underlies what has been so difficult in changing the PP

<fantasai> We're just suggesting that they be able to do so without switching the type of spec development track they're working under

Florian: if it were true that companies reject changes to the PP then EB would still work

Jeff: I'd like the AC to tell us what is better but I want them to understand differences between the EG and EB proposals
... where EG only proposes to change the licensing policy for the experimental track

Florian: last time we said that the "experimental" part was just a branding aspect similar to the document licensing
... and we had a goal to fix known gaps in Rec Track
... EG will have better patent protection than the Rec Track
... so we should fix Rec Track to have that better protection too
... I'd like to fix the EG patent policy so it works for Rec Track too
... in EG there is no requirement to publish a FPWD early so there might not be a review draft for a long time

<fantasai> Florian's comments on the Evergreen patent policy is https://lists.w3.org/Archives/Public/www-archive/2019Jul/0001.html

Jeff: "review draft" is not defined; EG has snapshots

<fantasai> https://www.w3.org/2004/pp/psig/pp-evergreen.html

Florian: ^^ refers to "review drafts"
... and since EG allows the group to work for 2 years before publishing it might be a long time before patent commitments are in force

Jeff: I didn't notice that https://www.w3.org/2004/pp/psig/pp-evergreen.html used terms that weren't defined in EG

<wseltzer> [PSIG recommended that 6mo be the recommended interval for publication of review drafts]

Florian: in addition there is a loophole in the Contribution License as it only applies to the Evergreen Recommendation, not to preliminary drafts

PLH: that is also true for Rec Track; you have no license commitments until you publish an FPWD

Florian: there is no point in EG where you must commit or exclude
... since there is no FPWD you don't get either the Contribution License or the whole spec license

Jeff: any process can be abused by doing the work outside of W3C then bringing it into a W3C process

PLH: we introduced Preliminary Draft to acknowledge the existence of editors' drafts
... it's a way to label what are now editors' drafts
... so publishing these preliminary drafts on /TR makes you uncomfortable?

Florian: they don't require WG consensus and don't trigger FPWD license commitments

Jeff: this sounds fixable; add call for exclusions to Preliminary Drafts

PLH: [nods]

Florian: once this is fixed, EG has what EB wants for a patent policy; the same PP would be capable of being used in EB

Jeff: I'd be in favor of writing a new PP that is usable by both an experimental track and by EB
... this is different from proposing that a new PP is also usable for the existing Rec Track

Florian: propose writing a new PP so that it would be used by EG and then see if it can also be used by EB
... but EB would work even without a new PP
... the PP can use neutral terminology so it can be used by either

<fantasai> +1 to having a generally-worded patent policy that can be invoked by the Process in whatever way seems appropriate

PLH: happy to work on something that could apply to Rec Track in the future
... EG is not proposing to change the Rec Track PP yet
... in two years if the EG experiment proves successful then we could propose to fold it into Rec Track

Florian: so we could write a new PP now so that in two years it could be folded in

Jeff: i.e. the EG proposal asks the AC to make a decision about using a new PP for the EG track and does not take a position on what a future AC might apply to the Rec Track

<Zakim> fantasai, you wanted to say that experimenting on patent policies and experimenting on spec development shouldn't need to be tied together

Fantasai: I don't like tying changes to PP to changes that provide an alternative process
... separate questions of how we review technical work and what type of patent commitments we want and when we want them to kick in
... we don't need to tie these together
... should have to change workmode to change PP
... a new PP should be usable by either workmode

Jeff: when we present this to the AB we should capture this as an important advantage of EB
... the reason EG is a different, weaker, proposal is that it is fearful the AC won't agree to a new PP for Rec Track

Fantasai: we have two experiments: a different PP and a different way to do maintenance
... both can make use of a new PP
... we can ask the AC if this new PP can be an experiment that any WG could adopt or if it can be adopted for all

Florian: let's develop an "experimental PP" that is not tied to either EB or EG
... write it in a way that it can be used by either

<Zakim> jeff, you wanted to agree (I think) with Fantasai

<fantasai> Question to the AC #1: Would you want to allow some groups / some specifications to charter themselves to use such a new patent policy? Y/N

Jeff: I'd be fine saying there are three alternatives:
... EG, which integrates both new workmode and new PP

<fantasai> Question to the AC #2: Would you want W3C to adopt such a new patent policy for new specs, in place of the 2005 Patent Policy? Y/N

Jeff: EB without changes to PP; focuses on superior workmode
... EB with new PP

<fantasai> Question to the AC #3: Any other thoughts? <textarea>

Jeff: I don't have a problem putting three proposals to the AC

Florian: EB is conceived as modules that can be taken as a whole or in part
... but saying that EG is superior to EB because it has a patent policy is wrong; EB can have the same new PP

Jeff: I feel strongly that I don't want to put an uninformed story to the AC

<fantasai> Intro to the survey "W3C is considering an improved Patent Policy, which includes contribution commitments at the time of contribution as well as whole-spec commitments at the end of each exclusion period."

Jeff: we need to prepare a corpus of information so the AC understands what we're talking about
... once we have that corpus we can break it down in several ways for the AC

Fantasai: we're hung up on the quuestion of whether the AC will agree to changing the PP
... we should put that question to the AC soon
... start a survey early in September
... if no one objects to considering a new PP then we can work on that
... until we know whether the AC is willing to consider changes to the PP we don't know how to proceed

Jeff: I am supportive of starting a survey in early September running through the AC meeting
... I don't see any reason why we can't prepare as good a description as possible for EG and EB, even multiple versions of EB, for such a survey

<Zakim> jeff, you wanted to correct the record

Jeff: to help the AC think through several questions

Fantasai: fine to have several questions but the specific question of changing the PP should be a separate survey

<ralph> [I think the AC needs the context of EG/EB to understand why we're asking abput PP]

Fantasai: I feel strongly they should be separate surveys

Jeff: the surveys will go to the same people; I don't see why they should be separate

<wseltzer> [wseltzer: changing PP is a big deal, so we need to explain why we think it's worth the effort]

Florian: we need to write a new PP for EG anyway; let's write it and separate consider what the AC is willing to apply it to

<fantasai> wseltzer, ralph, providing context makes sense. I still think it should be a separate survey from one where we ask about specific Process details that aren't legally relevant.

Jeff: we might not even need to write the new PP in full legalize; we might be able to characterize it sufficiently for presentation purposes

Florian: I only objected to PLH's characterization that the PP was a significant difference between EG and EB

<fantasai> +1

PLH: I'm happy to change that

Florian: how can we work with PSIG to draft an experimental PP?
... how can we make progress quickly?

Jeff: in the short term, all you can do is ask to be invited to a PSIG meeting
... it took PSIG four months to get to the EG PP; I'm not optimistic that that same group can, over the summer, draft something else
... so an English-language characterization of how the new PP should work should be sufficient
... EG would say that the new PP would only apply to the experimental track
... EB could say the new PP is optional and/or could be chosen for either EB or Rec Track

Florian: I'd be fine with sharing a high-level description of a new PP

Jeff: PSIG has had time to become comfortable applying a new PP to EG; they haven't had similar time to think about that PP for EB

Florian: most of what I want to fix to make the EG PP work for EB are also bugs for EG

Jeff: I think most of the work is in getting the AC to think about whether they're willing to change the PP for Rec Track

Florian: can we resolve to work on an experimental PP that is usable for either approach?

PLH: I'm not against this but my reservation is that if we can't have a PP that works for either, would both EG and EB be dumped by the AC?

Florian: if we find we can't make a PP that works for both then we don't need to push that

Jeff: we're having a conceptual discussion with the AC; if the AC decides they prefer one of the proposals then we'll focus on making the legaleze PP work for that one

Florian: the EG PP seems to be intentionally different from the current PP in (a) having a Contribution License and (b) applying the license earlier than the final Recommendation
... are there any other differences?

PLH: I don't believe there are any other major differences
... EG and EB detail when those calls for exclusion are triggered

<wseltzer> [yes, those differences, plus explicit copyright license and incremental commitments at a window around each Review Draft]

Florian: then I think we have a reasonable chance of making a PP that works for both
... I don't think EG is trying to do anything [in the PP] that is a problem for EB

Tooling assumptions

Florian: there are a number of requirements in the EG track on what must be done everytime the WG publishes
... these would currently require a lot of manual effort
... if tooling doesn't appear in time, what do we do? delay EG? violate the requirements of EG? ... ?

PLH: yes, EG requires more tooling that EB
... both require some [NEW] tooling
... EB asks for 28 day AC review if additions are proposed

Florian: it's workable with existing tools; WBS is capable, though not ideal

PLH: so the burden would be on the Team to create the individual WBS

Florian: new tooling is not a prerequisite for EB to work

PLH: EB has markers in the spec for proposed corrections and additions
... do you expect those to be done manually?

Florian: same answer; the naive way would be a general note and <ins>/<del> to distinbuish changes
... more ideal would be tooling that allows the editor to turn things on and off

PLH: EG says the marker must change after 180 days
... EB requires the editor to check for expired markers each time the spec is published

Florian: this is similar, maybe slightly worse in EB but the requirement is to document the intended changes
... and we don't have the tool to automatically generate those

<inserted> fantasai: We don't even have the data for that

florian: WPT, CanIUse, and @@ are three sources we could use
... WPT won't tell us if we have tests or if tests fail because the spec has changed and the test is old

Jeff: what is the tooling challenge that you see for EG that doesn't exist for Rec Track?
... you want to know which features have implementation experience for both EG and Rec Track

Florian: right, but we need that information in different forms and at different points
... EB doesn't require the information for proposed changes, only when the 'proposed' marking is removed
... removing 'proposed' markings happens at a transition call
... EG doesn't have transition calls so it requires that all markings be updated every time the spec is published

Jeff: if the primary purpose of the markings is for the patent policy, would we need to update them at any other time than when we publish a review draft?
... my impression is that we only want to assign status to a feature that it's part of the Evergreen Rec if it has implementation experience
... something that doesn't have implementation experience we don't consider to be part of what we call the Evergreen Rec, so patent commitments don't yet apply

Florian: that's how EB works; additions are provisional until you've shown implementation experience

Jeff: EG is modeled from how we've structured the HTML process
... when there's a WHATWG Review Draft with a feature that doesn't have implementation experience we consider that Informative for the W3C Recommendation

Florian: Mike Champion has described that the markings are for readers of the spec to determine the stability of the feature
... but the EG proposal says that the WG can add the feature whenever it has consensus to do so

Jeff: there are two purposes for the markings
... the "soft" purpose is as you describe, for readers to understand how stable the feature is
... but it should also be true that EG says that implementation experience is required for things to be part of the Recommendation
... and if it's not that way, it's a bug

PLH: we didn't write it that way

Jeff,Ralph: that's a bug

PLH: not sure where the bug came in, but it's not currently written that way

<florian> https://w3c.github.io/w3process/evergreen/#evergreen-rec

Florian: see bullet first sub bullet of 2nd bullet

PLH: we didn't link patent commitments with implementation experience

Jeff: perhaps this should have been described in the PP, not in the Process text

Florian: if we expect continuous markings about implementation experience that's still a lot of work

Jeff: for the hard requirement you'd only have to update for Review Drafts, which are essentially transition calls

Florian: need to define threshold for "sufficiently implemented"
... EB has a fast path with stricter criteria that is expected to apply most of the time but not necessarily all of the time

PLH: EB explicitly requires two independent implementations
... we kept this vague in EG on purpose
... for the case that there is only one implementation that everyone is uses

Florian: in EB the WG makes that argument in the transition call
... and the patent commitment applies to everything including those things that don't [yet] have implementation experience

PLH: I agree we need to fix this in EG

Florian: either "implementation experience" is left fuzzy as it is today in which case it can't trigger patent commitments
... or you need to cause a transition call
... which are you trying to do?

PLH: both
... we'd like patent commitments with implementation experience but without defining implementation experience more than it currently is

Florian: EB can use today's mechanism: describing how the CR exist criteria have been met and convincing the Director
... that route does not require strict implementation experience
... however, if there are two indepement implementations then you don't have to convince the Director; it is automatic
... the non-automatic path is the same as today

PLH: I missed the automatic/non-automatic difference

Florian: see 6.7.4

<florian> https://w3c.github.io/w3process/everblue/#revised-rec-substantive

Florian: "... if it can show adequate implementation experience and the fulfillment of all other criteria of Recommendation text, incorporate it into the main text and request publication as a Recommendation."
... and then 6.7.4.1 Streamlined Publication Approval

PLH: I hope a _call_ is not always required in the non-automatic case

Florian: the intent is the same as Process 2019

<fantasai> ScribeNick: fantasai

Florian: ... Not obvious to switch to defining patent policy on an implementation threshold
... if there's no clearly-defined threshold

jeff: This is modeled after what we're doing for HTML
... besides promise that we'll deliver some tooling
... We have Evergreen have up-to-date markings
... but we don't have an Evergreen process yet
... so still under aegis of the HTMLWG
... and transition calls
... I assume that HTML will take a Review Draft
... It'll say, the things that count as normative for W3C REC are those that are marked as having 2 impls
... and we, the HTMLWG, propose in our transition call that that's the entirety of the W3C REC
... Everyone says OK, good enough
... That qualifies as REC under W3C
... What I don't think anyone ever discussed was
... Let's say you have feature with impl experence from only one browser
... and maybe partial implementation or a polyfill, should we allow that to be included in a REC even though markings not there?
... That's an example of where rules are too strict
... That test case hasn't come up in HTML yet, just trying to get started

plh: For WHATWG HTML, there would be 2 impl of the spec, not one
... Let's hope that's a good assumption for next 3 years
... Can we make that assumption for every other spec? No
... If I take ARIA mappings, we have one implementation mapping to iOS
... Does it mean because we only have one implementation it can't be part of REC?
... Today that's up to judgement of the Director, whether normative or not
... If we become more prescriptive on what qualifies as adequate implementation experience
... in order to link to the Patent Policy, that becomes trickier.

jeff: Do same thing as Everblue: if 2 impls, automatically go forward
... But if don't have 2 impls, effectively do a transition call, have the Director assess in individual cases it's good enough
... If Director wants to say for ARIA mappings, one impl is enough, then it's enough

plh: So transition call to publish a snapshot?

jeff: Yes, if you want an exception to 2 impls

florian: Another difference, on WHATWG side of the Process, there are also strict rules
... They have rules about how many browsers, and they specifically say browsers
... have to commit to implementing something before it's incorporated into the spec
... W3C can't have such strict rule, because we have specs for things that aren't necessarily implemented by browsers
... Because they have this strict criteria, taking their work and making a REC is not so tricky
... But on our side, our process cannot be so strict

jeff: question of implementation commitment vs experience
... We are highly suspicious, because in the past browsers would commit to things they never implemented.
... That's why we require experience rather than commitments

florian: Are you doing this judgement of sufficient implementation experience only for the patent policy or also for normativeness?

jeff: for both

florian: I like that idea, it's what we propose in Everblue
... Seems like it is different from what is in Evergreen
... So question is what do other ppl think about this?

jeff: For HTML, we said not taking anything as normative or patent-protected unless it has implementation commitments
... mchampion was on both sides of the discussion

florian: Suspect mchampion might not like it because he was defending the idea of having a gradual subjective categorization of the maturity of a feature
... He thought it was a feature that the reader decides

jeff: I have no problem including more information in the spec about implementation status

<mchampion> Sorry having teouble joint call

jeff: Question in my mind is not assigning W3C status to something unless it has the implementation experience

florian: If everyone on the Green Team agrees with that, suggest to fix that then.

jeff: Back to Florian's question from 45min ago, which is how long is it going to take us to get tooling in place
... How long do you think it'll take to implement the tooling?

<mchampion> I was just saying that in WHATWG it’s a “reader decides” situation... not sure how they would work i in W3C

florian: I think it depends on how we answer the question we were just discussing
... If we change to be more like Everblue, then easier
... No longer detailed gradient type info, every single feature of every single publication
... In that case Evergreen and Everblue are not terribly dfferent
... If we stay with normative from start, patent-commitment from start, need information of how much implemtnation we have for reader to make determination
... My feeling is that we will never have the tooling + data to do that

jeff: I think we have to make the change
... My view is this is modeled on the HTML thing

plh: good we have this conversation, differences between HTML and what we're trying to achieve

jeff: So, I have made a listing for myself of topics that may or may not be topics of distinction between Evergreen and Everblue
... wondering if it would be useful for me to give a stream of consciousness about what they are?
... Not complete, just thoughts

florian: go for it

jeff: One difference I think is that, to use emotiionally charged words, Evergreen is a fork of the process
... Whereas Everblue is not
... That is what I would say a clear advantage for Everlue
... Second difference is that Evergreen intends to be experimental at first
... Everblue does not

florian: I don't think this is a difference to the degree you characterize it
... Because Evergreen is a fork, it can only be intorduced experimentally
... Everblue *could* be introduced experimentally
... Probably we would just fix the REC track, but it would be possible to do Everblue experimentally

plh: Everblue has to introduce in charter?

florian: The ability to introduce new features to a REC is marked as a thing that has to be adopted in the charter
... but could adopt the whole thing via charter if preferred

jeff: Our highest level of status that we assign to something is a W3C Recommendation
... Evergreen is experimental in the sense that nothing in the experiment gets that highest status
... In Everblue it does
... You can call it experimental, but once you call something a W3C REC in an experiment you can't remove that name anymore
... Agree with fantasai that probably nobody cares about the name, but would like to share with the AC and have them tell me they're OK to make a change to REC
... You won't seem me advocating one or the other so much as clarifying
... Both Evergreen and Everblue without patent policy changes, neither require that we take on a change to the Patent Policy all at once
... and do instead in stages
... Everblue with patent policy changes says we're ready to make change to the entire patent policy
... Distinction 4, as I recall Everblue, if you want to introduce flexiblity of everblue and do continuous update for CR or REC level
... We have some rigid rules for what needs to be done, but from editing PoV, Evergreen didn't have any of these rules. Did that make sense?

florian: Don't think it's wrong, but needs details
... Everblue doesn't slow down making the edits
... But have strict criteria have to meet before you can call them normative and invoke patent policy
... Evergreen doesn't have it atm, but our previous discussion was introducing that back

plh: Everblue has concept of Living Recommendation, Evergreen has evergreen recommendation
... both states allow transtion to Recommendation

florian: No, a Living Recommendation *is* a Recommendation
... It might contain notes of things that may be added to it later

plh: I think ?
... Evergreen has to take to CR then to REC
... Everblue will do a Call for Review which will trigger the call for exclusions etc.
... Everblue makes it easier to move to a REC than Evergreen
... On the other hand, Evergreen will claim something is normative
... sooner than Everblue
... Because Everblue will be informative until it's part of REC
... Evergreen, if it's there for 180days, we assume there was opportunity for wide review etc. and it's now normative
... Won't have patent protectuion until review draft, but still it's normative
... I think Evergreen allows you to claim something is normative while it's not part of REC yet
... Whereas Everblue will only become normative once part of REC

florian: Agree most of what you said
... You said, with Everblue it's kind of easy to make it into a real REC whereas for Evergreen have to switch tracks and go through CR/PR/etc.
... That's true but only if you care about the document being called a "recommendation"
... If it's normative and has patent protection, that's the real status.
... This is easier to get on Evergreen than REC
... How we fixes the earlier discussion of patent protection and normativeness
... that we discussed earlier today
... then the two proposals are much closer than they are now
... The other thing you said, wait 180 days it become normative
... As written now, it's normative immediately.

jeff: Clarify that when I said that at a snapshot, patent protection is matched with normativeness
... My intent there was only that patent protection would not apply to non-normative things
... only apply to normative things and implementation experience
... and have to wait 180 days therefore

florian: So if you don't go through threshold to have W3C status
... and you're not a lawyer, you're an enginerr
... Do you envision that there would be some marking that the change is a proposal?
... Or would it just be blended into the text?

jeff: If you put the dating there, then you can know if 180 days
... If have markings of implementation expriencence
... Then you'll know
... but if don't get that until snapshot day
... then you won't know until snapshot day

florian: Both processes are vague about how to do this
... But in Evergreen approach, when you make a correction. You replace the old text with new one.
... In Everblue, old text is there, and new text is there also.
... Exactly how you mark it up -- notes, or INS/DEL, or what, both info isthere
... But in Evergreen the new text is there, old text is not, regardless of how mature the new stuff is

jeff: Maybe raise an issue about providing this info?

florian: I know what Everblue does, don't have an opinion on Evergreen because don't understand what it's trying to do

jeff: ...

florian: When you said that you wanted not just patent policy but also normativeness to depend on passing threshold...
... ... then old text has to remain?

jeff: WHATWG removes the old text
... Initial thought was to be as similar as possible unless reason otherwise
... Maybe your suggestion is good for WHATWG as well, I don't know

florian: I think on the WHATWG side, their criteria is more complicated than that
... For corrections to existing things in the spec, they requrie one implementation, actual implementation, and one intent to implement
... to even put it in the spec at all
... Maybe we want to copy that, maybe we do

jeff: Requires thought

florian: If you find a bug in the spec, in order to fix the bug, you need an implementation.
... This means that a large part of their spec lives in pull requests.

jeff: Community should discuss

florian: One approach currently discussed in Evergreen, you said you dislike becuase doesn't pass threshold for W3C status
... But if we don't fix that bug, the tooling required to make what's curretnly specified work is impossible to make
... You can fix it by doing same as everblue, I'm happy. If you're trying to fix some other way, I can't comment on it because I don't know what is the proposal

plh: Seems that Evergreen team needs to revise their proposal.
... So we can minute that
... I still trying to understand jeff's point #4
... jeff, you were mixing up editorial drafts and changes and... I didn't understand it.

jeff: That was the rigid rules issue
...

florian: I think your point was fair characterization of Evergreen vs Everblue today, but Evergreen team was going to make some revisions there.
... So doesn't make sense to characterize the difference until we can actually diff them

jeff: In 6.7.4.1 of Everblue, it talks about approval being automatically granted under certain criteria
... My interpretation of this is that if you make substantive change and you want to get approval for this change as having w3c status
... you need to follow a bunch of rules which are stricter than general criteria

florian: There's an either here. you may either follow stricter critera to bypass transition call. Or match the usual criteria and have a transition call
... In either case there's a threshold in 6.7.4.1
... In 6.7.4 there's a human-based judgement
... In either case there's a treshold

jeff: If I'm in an Evergreen world
... I can achieve status for certain features even if I haven't gone through either judgement
... for example, do I need to show in Evergreen that all issues have been formally addressed? Is that part of Evergreen?

plh: no

florian: To make something normative in Evergreen, you don't have to meet any kind of threshold

plh: Editor has to put it there, but that's the only threshold required
... Even if we change the patent policy bits, that won't prevent editor to put things in the spec
...

jeff: If text is there, and there are implementations, can that go to Evergreen Rec with patent protection and normativeness
... even if all issues are not formally addressed?

plh: Yes

jeff: So you could see that as a feature or a bug.
... to ignore some issues.

florian: To make distinction between normativeness/patent protection, have a threshold to pass. Haven't defined that threshold.
... Could require impemetnations, or addresisng issues, or whatever. Hasn't been defined yet

jeff: No one has raised an issue yet with this feature/bug of Evergreen that not all issues have been formally addressed.
... So that's a characteristic of the Evergreen proposal

florian: No one has raised the point specifically, but Evergreen today doesn't have any thresholds. Just in-the-spec annotations of issues/oldness/implementation/etc.
... If we switch to having some kind of threshold to have some kind of status, Evergreen hasn't defined yet.
... So we should punt on describing this difference until that's defined

jeff: I'm just describing my notes that I wrote earlier
... As written today that's a distinction
... I don't really care if you agree today or not, this is just a conversation.
... All I'm doing is noting that this is something we should be identifying as a difference

plh: One thing that Evergreen does is put the burden of proof to be not part of REC on ppl reading the document.
... If you don't like something in an Evergreen spec, you can raise na issue. and If you're not happy, you raise a formal objection
... but if no issues, it times out to become normative
... But in Everblue, you can put it informatively. But to become part of the REC, you need to address the issues and prove to Director that it's worthy of REC

jeff: One other distinction related to that same point
... which is frequency of review by horizontal groups / AC / legal
... Raised concern of Everblue of frequency, team response was we could limit the frequency
... Is the obligation on team bringing it forward or is it more passive?

florian: I think both approaches need to clarify on this, but I am also here not sure whether it's a distinction or not
... Evergreen currently has question marks and partly contradictory statements between Process and Patent Policy
... of whether it's on a strict 6-month cadence
... or some range of 6 to 24 months
... On Everblue side of the world, it's wide opne, but a note that maybe you shouldn't be more frequent than 6 months
... These are both open questions.
... Don't see why once we make that more firm the answer wouldn't be the same on both sides
... so this is an area for work, not necessarily an area of difference.

jeff: Candidate for a distinction

florian: Could be, but don't see why it needs to be different
... so if we want to allow as often as we want on both, we could, and if we want to rate-limit we could
... No argument for why they should be different
... so my assumption is that once the dust settles they won't be

jeff: So let's talk about AC review
... When does Evergreen have AC review?

plh: It doesn't unless you go to REC

jeff: So Evergreen never has AC review unless you go to REC
... Everblue?

florian: Simultaneously with legal review
... proposed changes are non-normative, folded in effectively editorially
... Get reviewed and folded in during call for review

[Florian quotes the Process doc]

<florian> https://w3c.github.io/w3process/everblue/#revised-rec-features

florian: You don't introduce a new feature. You introduce a note describing the addition you propose to add.

<plh> https://w3c.github.io/w3process/everblue/#LivingRecs

<plh> "There must be a Working Group decision to do so, after which the Team must solicit an Advisory Committee Review of the proposed change. The review period must last at least 28 days. If the proposal is approved, the Recommendation is republished as a Living Recommendation."

[poking at spec text now]

plh is reading the text

florian: That paragraph is about switching your Recommendation to being a Living Recommendation [i.e. changing it so that it is allowed to accept new features]
... In your charter you say whether your deliverable will be a non-living Recommendation or Living Recommendation or could be both
... Some users of our specifications count on a Recommendation representing a stable set of features
... So we require an AC review to allow the spec to, effectively, switch tracks and accept new features

plh: So if your charter...?

florian: If you go from CR to Living REC, you can do that as usual
... But if you have a REC and you want to make ti a Living REC, you need to ask the AC

jeff: It says last call for review of proposed additions must be announced
... Is that an AC review?

florian: I think so, I have a work-in-progress edit to clarify

jeff: So back to your earlier assertion that the frequency issue is the same for everblue and evergreen
... this is example where it's not the same
... Evergreen can say we live in Evergreen without AC review forever
... To get AC review become REC
... Everblue involves the AC every time there is a proposed addition
... So frequency issue, as we understand it today, is a distinction between Evergreen and Everblue

florian: I agree that it's an interesting case, of AC review being involved might require a different frequency
...
... Call for Proposed Addition isn't start of horizontla review. Should have done it already
... If haven't done it already, maybe it's a reminder, but it's not a point at which you ask.

jeff: When do you ask?

florian: Ask early, ask often, don't overload people.
... No different than today or from Evergreen

jeff: what makes it more than REC track today is potential of having a higher frequency of so-called Proposed Additions
... it's a feature and concern at the same time
... Can publish osmething more updated more frequently
... but HR communities overloaded frequency of review
... Could be something to think about

florian: partly, but not entirely
... Frequency of creation of proposed additions is jsut as fast
... just happens in editor's draft
... The material is created just as frequently regardless
... just doesn't reach /TR
... So speed at which mateiral is created doesn't hcange, but frequencly at which it hits /TR increases

jeff: But those in HR community can't keep up
... and what helps is batching reviews
... when hitting CR
... So I believe, and we can debate with them, but there are some HR communities if we give them a choice within next 12 months
... change in document per month, and they don't have to revie wuntil 12 months and they can batch and study all at once
... they would prefer that
... to having every month a proposed addition
... What I'd like to do is identify this as a distinction
... And have to also discuss Evergreen side
... But capture these important points

florian: I think that's fair, in general my impression is that neither Everblue nor Evergreen actually solves that problem.
... They surface it differently, but the problem that there's a lot of stuff to review and ppl can't keep up isn't solved
... But batching things at CR is too late in many cases, beause sometimes it's shipped
... Ever* doesn't fix that
... If you want to while be waiting, you can wait for awhile under Everblue and provide the feedback later
... Group is still required at address the feedback, but might not be able to if implemented and shipped
... So problem is surfaced differently, but the problem still exists

jeff: Everblue and Evergreen deal with it differently, just want to surface as a distinction
... different HR communities might have different preferences
... or might be upset by obht
... either way increases pressure on HR communites

florian: Disagree, the rate of change isn't changing from today.
... All tracks, today, blue, and green, all surface the problem differently
... but the technical work still progresses

jeff: Yes, but they use different techniques to deal with it
... I think they will be internalized differently.
... I want to identify the characteristics and get that in front of peope to think about

florian: I wouldn't characterize rate of change as being different, but surfacing diferently and ppl may have different prefs on what's better

jeff: ...
... I want to register that we need to be able to have a session with the various stakeholders, whether WebAppSec, WebID, CSS, Accessibility Mappings, and get their testimony
... Have them say their opinions
... We need to make sure that we keep that in front of ourselves

florian: When we shop the proposals to the different groups
... It might be interesting to be more adversarial, not to mischaracterize, but have a debate
... and discuss the strengths and weaknesses of each others proposals and get input on what these groups care about and think about them

jeff: Seems like almost necessary because we already have had a discussion with WebAppSec about Evergreen

plh: We're past the hour
... Still need to ask questions about next 7 days
... Who wants to write about common parts?
... And who wants to write about differences?

jeff: And fix bugs in Evergreen, and clarifications in Everblue
... And then start to write up spec text and patent text, but also conceptual text
... Here's the problem, here's how we solve them in each method
... Why are they different,

plh: I can fix Evergreen
... Can also try to revise my earlier email now that I understand more of Everblue
... to characterize the differences
... And if Florian, if you want you and I to talk before I send another email
... Not trying to pick a winner
... Also take an action item...
... One thing starting to bug me as I write the amil
... Especially for ARIA mapping
... ARIA mapping ppl want to update W3C Recommendation
... And Evergreen and Everblue still says, well if you want to do that you have to fulfill the requirements of the process
... Want to see from ARIA mapping if can fulfill the requirements

fantasai: The ARIA mapping discussion in particular was what precipitated discussion about normative registries that are official W3C Recommendations

<jeff> scribenick:

<fantasai> fantasai: The Everblue approach was to create a separate class of changes for edits to items in a registry

<jeff> Fantasai: Registries was partly to handle ARIA mappings

<jeff> PLH: Will you update your proposal

<jeff> Fantasai: There is proposed text for registries

<jeff> Florian: Separate branch

<jeff> ... could be combined

<jeff> PLH: maybe similar to PP - could be part of EB; but does not need to be

<jeff> Florian: EB is modular

<jeff> Florian: Proposed text is tuned to "normal" specs

<jeff> ... WebIDL and ARIA mappings are unusual

<jeff> ... WebIDL not intended to have implementations

<jeff> ... ARIA; only one

<jeff> ... hard to accommodate

<jeff> PLH: I agree with you

<jeff> ... EG was fuzzy to say "adequate implementation"

<jeff> ... EB more explicit in automatic case

<jeff> ... but 2 important use cases.

<jeff> ... HTML and SVG are easier

<fantasai> scribenick: fantasai

jeff: So plh will do everything?

plh: A bunch of it, yes, will try by Thursday

florian: fantasai and I will work on clarifications to Everblue

[plh and florian discuss syncing up]

plh: discuss next meeting

fantasai: My schedule next week is pretty wide open except Friday

plh: Tuesday next week?

florian: Don't know if we need big 3h meeting, or more frequent smaller meetings

jeff: I have this fantasy that by the time we meet with the AB on August 6th, we have this very slick presentation that describes what we're doing and how we have these two great approaches which have important disticition
... My view is that if that presentation is going to show up on August 7th, I'd like to see it at least a week in advance in draft space
... so I can make sure I can make sure I have material to chari

plh: I'll have a draft this Thursday, and maybe we can complete next week

fantasai: so plh will make a draft, we'll iterate async, and then have a call next Tuesday to wrap up

[discussing time]

Proposal: 3pm Boston time

RESOLUTION: 4pm Boston Time on Tuesday 30 July 2019

- DRAFT -

Ever{Green,Blue}

22 Jul 2019

Attendees

Contents

Tooling assumptions

Summary of Action Items

Summary of Resolutions

Scribe.perl diagnostic output