<mchampion> Present via IRC but will have to step out in a few minutes

<plh_> scribeNick: plh

Intro

<plh_> Jeff: last week discussion and emails that came after and spec/process text from Fantasai/Florian, overall it's coming together nicely

<plh_> ... as I see it, to the original goal, which was to have a method of continuous development, we have 2 solutions and both of them are plausible

<plh_> ... they have significant diffs, in philosophy and results

<plh_> ... it's not obvious to me which is a better fit for our needs

<plh_> ... last week of discussion has been helpful in improving both of them

<plh_> ... when we started these long calls, I had kind of inspiration probably misplaced that we would come to consensus that one approach works and the other one doesn't

<plh_> ... at this time, it's not clear to me that we as a small group can/should be choosing a winner

<plh_> ... and other opportunity is for both teams to continue to improve their proposals, clarify issues, develop a matrix of what differences are

<plh_> ... are show up at the August AB f2f saying we now have a clear view of green and blue, compare them

<plh_> ... and see if there is an AB consensus, which is unlikely

<plh_> ... but ultimately show up in Fukuoka, present the proposals and the key decision points, and get feedback from the AC

<plh_> Florian: so, for TPAC, both proposal text should be clear to be adopted by the AC then?

<plh_> Jeff: desirable but not necessary.

<plh_> ... we could present both of them

<plh_> ... it's probably to get each side to present their proposals

<plh_> ... as we iterate, some of the differences will get resolved

<plh_> Jeff: looking at the proposals:Evergreen is a fork

<plh_> ... green folks might say folks are good for experimentations, while blue say it's a negative

<plh_> ... we should be able to present both sides and let the AC decide

<plh_> ... with Blue, one has to follow rules to do steps, unlike green

<plh_> ... everblue might say its way is better, for guarantee of quality

<plh_> ... while green folks might say that flexible is necessary to attract the WHATWG-like folks

<plh_> ... to me, that's an interesting conversation to have with the AC

<plh_> ... patent policy might be an other one

<plh_> ... PSIG almost agreed on evergreen PP. Everblue might say we don't need to make changes

<plh_> ... so rather than debating who is right, that would be better

<plh_> ... so, how's my path forward?

<plh_> Fantasai: it would be good for us to minimize the differences as much as we can

<plh_> ... so removing the unnecessary differences

<plh_> Jeff: +1

<plh_> ... we saw a great use case for that last week, with procedural consensus

<plh_> ... after discussion, we all agreed that no change necessary from today's process

<plh_> ... just a need to document it better

<plh_> ... so yes, +1

<plh_> ... we'll try to do some of that on these calls

<plh_> ... continuing through issues today

<plh_> ... if we agree on the framework, I'll ask the document editors to go offline and prepare this happy resolution for the AB f2f

<jeff_> https://www.w3.org/Member/Board/20190806-abagenda.html

<plh_> Jeff: I did put together 2.5 hours on Ever*

<plh_> ... .5 on PSIG on Evergreen, might need to be reframed

<plh_> ... 2 hours on Ever*

<plh_> ... and one hour on Process 2020 roadmap

<plh_> ... which could be combined

<plh_> Florian: agreed with the approach in general

<plh_> Jeff: alright, let's keep going through issues then

<plh_> Fantasai: did we address formal objections?

<plh_> ... EG says that FOs need to be documented. We should require that FOs get processed before publication

<plh_> ... rather than sitting as a note in a draft

<plh_> ... we should make some changes to better handle FOs for RECs by requiring that updating a REC means annotating RECs with objections, like Errata

<plh_> ... and also require that, if published, you must have raised this FO throught the appropriate process

<plh_> ... either proposal will need to do that

<plh_> ... ie clear note in the draft and must have been raised

<plh_> Jeff: still a question on where the Director needs to be involved

<plh_> ... I agree we should address it

<plh_> ... addressing the FO issue in a compatible way in EG and EB is sensible. EG has a proposal, not clear if it's complete

<plh_> ... not sure if it matters for today's call

<plh_> ... could be refined in the upcoming weeks

<plh_> .... we could have common issues between the 2 proposals

<plh_> ... and ask for AB input

<plh_> ... you started to mention the council

<plh_> ... to be clean, let's assume we have a DIrector for now, and change that later

<plh_> Fantasai: for EB, we have Director's call in case of FOs

<plh_> ... if there are strong objections to a change, this needs to be addressed before the change gets made

<plh_> Fantasai: depending on whether a change was made or not, I would handle FOs differently

<plh_> Florian: when it comes to objection to the whole spec after we reached RECs, this is already an existing problem

<plh_> ... presumably, the Director will look at it at some pojnt with EG. EB requires the Director to stay in right away

<jeff_> PLH: We need to distinguish EG or EB are coming from REC or CG

<jeff_> ... EG should be previously REC docs for the experiment

<jeff_> ... but some CGs never want to go to REC track

<jeff_> ... That is on the side for now for EG

<jeff_> ... EB doesn't make distinction

<jeff_> ... always on REC track

<plh_> Florian: EB happens after you reached REC

<jeff_> PLH: We should get licensing commitments before REC

<jeff_> ... is it OK if doc has FOs is a question

<plh_> Jeff: while we put the CG never goes on the REC track on the side, if we look at the differences, this is a key distinction we need to recognize

<plh_> ... and talk about the +/-

<plh_> ... so EV does allow for CGs to move directly without going through REC, which isn't the case for EB

<plh_> ... different philisophy

<plh_> plh: fair enough

<plh_> Jeff: for EB2, it's different on getting a FO on part of the text vs the whole text

<plh_> ... the devil will be in the details

<plh_> ... don't understand the proposal yet. and don't agree it's the same use case compared to today

<plh_> ... we don't have a situation where a spec has objections today. we did give the REC status on it

EB3

<plh_> Jeff: assert a change many place of the spec

<plh_> ... not sure what to do

<plh_> .. sure, this may happen

<plh_> Florian: there is a need to update the entire spec. you don't get to exclude something that you previously did not

<plh_> [confusion about EB3 and EB4]

<plh_> Jeff: my understanding is that EB3 states that we will have changes all over the spec

<plh_> Florian: true, I don't see how this is a problem

<plh_> .. you need to mark them up differently in the spec

<plh_> ... but don't think it's a problem

<plh_> ... it may be complicated to express, but shouldn't be a problem

<plh_> Fantasai: EG says we need to put status tags, how to mark spec-wide changes?

<plh_> ... so, not more difficult that what EG requires

<plh_> Jeff: agreed.

<plh_> ... at some level, the more localized, the easier

<plh_> Florian: on EB, we have changes to the spec and mark them as non-normative. in EG, you have stability tag, how do you mark features that have changed across the spec?

<fantasai> plh_: I think didn't define precisely in EG what it means to be a feature

<jeff_> PLH: EG did not define "feature" in detail

<jeff_> ... on purpose

<jeff_> ... vague

<jeff_> ... editor can define

<jeff_> ... hence what to change

<jeff_> ... for sure

<jeff_> ... so EG, EB should be similar

<jeff_> ... both recognize - can be complicated

EB4

<fantasai> Flexbox changelog: https://drafts.csswg.org/css-flexbox/#changes

<jeff_> PLH: EG made a difference between patent commitment (a la CG) and a la WG

<jeff_> ... you have Contribution level when you contribute and open a window

<jeff_> ... after 180 days you get the entire doc for PP

<jeff_> ... EG left that on the side

<jeff_> ... need to have commitments sooner than REC because it could take years to get to REC

<jeff_> ... LS does not want to be in limbo indefinitely

<jeff_> ... i.e. we never know if we get to REC

<jeff_> ... e.g. Editing spec

<jeff_> ... in WebApps

<fantasai> This is problem with the REC track as it stands, we shouldn't only fix it for LS

<jeff_> ... since it is core, it could take years until it becomes REC

<jeff_> ... w/o sooner patent commitments, LS people will say it don't work for them.

<Zakim> florian, you wanted to respond after plh

<plh_> Jeff: so, how would the PP apply to long running documents?

<plh_> Florian: we can now update a REC itself, and we have delta.

<plh_> ... EB works using the existing patent policy

<plh_> ... you get a CfE on the changes, so there is coverage of changes to the REC as well as the REC itself

<plh_> ... what happens on the way to REC?

<plh_> ... it's a weakness of the REC track

<plh_> ... you can add a contribution commitment

<plh_> ... which what EG and WHATWG do

<plh_> ... with a window frame

<plh_> ... +1 to do it

<plh_> ... we can have something for PSIG to look it

<plh_> ... if it takes a long time to get to REC, we could apply the specification commitments at the end of the Call for Exclusion opportunity

<plh_> ... so the licensing applies at the end of the CfE

<plh_> ... it's a weakness of the REC track that EB can fix

<plh_> Jeff: the case where the initial spec never gets to REC

<plh_> ... and it's a core spec so you can never get there

<plh_> ... if we don't do the fix, that ends up reducing the issue that EV gives you this advantage

<plh_> ... second observation: this notion that you come to REC and it gives patent commitments, and then you keep enhancing and get commitments on the additions

<plh_> ... is that the same as getting commitments on the entire spec?

<plh_> ... I can imagine yes, but we'll need to check

<plh_> ... [...]

<fantasai> "as a result of subject matter not present or apparent in the latest public Working Draft"

<fantasai> https://www.w3.org/Consortium/Patent-Policy-20170801/#sec-Exclusion

<plh_> Fantasai: [...]

<florian> I agree with Elika's explanation of why it works, and I also agree with Jeff that I want PSIG to check that we got this right.

<fantasai> fantasai: The concerns about whether we're licensing delta's and the combination of deltas with the previous text is not an issue.

<fantasai> fantasai: The Patent Policy is very clear that exclusion opportunities apply to "claims made essentia... as a result of subject matter not present or apparent" in the previous publication.

<plh_> Jeff: this would raise a difference issue. if the patent protection is complete, it could imply that, even if there a small focus, they might feel obligated to review the entire document

<plh_> ... so we'll need to review the workload

<plh_> ... we can't make a tiny change every day and expect the review of the entire spec

<plh_> Florian: you have it on CRs already.

<inserted> fantasai: So I would like us to stop being confused about if there is an issue on here, there isn't, the patent policy is very clear on how it works with changes

<plh_> Jeff: we need to document the implications

<plh_> Florian: we could rate limit the call for exclusions

<plh_> ... we could keep it as an open issue for now, or attempt to fix it

<plh_> Jeff: don't have an opinion yet. just trying to get clarity on the +/- of each proposal

<plh_> ... EB might want to rate limit or not

<plh_> ... and see what comments wi

<plh_> ... we'll get

<plh_> Florian: once we get a rate limit it may be a difference between EG and EB

<plh_> Jeff: EG has the snapshots

<plh_> Florian: ye, but it's not necessary for EB

<plh_> Jeff: my only suggestion is to think about it at the moment

<florian> action myself to mark this as an open question in the EB draft

<plh_> Jeff: my third comment is about the concept of end of CR Exclusion opportunity to get the commitments before REC

<plh_> ... there is a core proposal for EG and a core proposal for EB, with variations for each of them

<plh_> ... I want our best shot at EG amd best shot at EB and put those in front for reviews/comments

<plh_> ... otherwise it will be too complex to review

<plh_> ... ie either it's in or out, but not in between

<jeff_> PLH: I disagree

<jeff_> ... I see it as necessary for EG

<jeff_> FR: For EB don't describe as part of EB

<jeff_> PLH: Then it is a difference between EG and EB

<jeff_> EE: It is part of EB

<jeff_> ... we want to address a collection of issues against the process

<jeff_> ... EG totally new set of rules

<jeff_> ... EB collects changes to REC track

<jeff_> ... so PP changes must be part of EB

<jeff_> ... interesting to note that EB changes can be a package or 1 by 1

<jeff_> ... while that is useful...

<jeff_> ... to compare EG and EB you must compare in complete form

<jeff_> ... can't include PP for EG and not PP for EB

<jeff_> ... it is an interesting note that EB w/o PP changes also has value

<jeff_> ... but it is not a broken system

<jeff_> PLH: Happy with Fantasai's characterization

<jeff_> EE: It is part; but not in process doc - goes in PP

<jeff_> PLH: Fine by me.

<jeff_> FR: Working on PP text for PSIG

EB5

<plh_> Jeff: whether sufficient reviews for EB

<plh_> ... Florian convinced me it's there

<plh_> ... may need to make clearer

<plh_> ...but the rate limiting for AC reviews might need to be considered

<plh_> ... so similar to EB4

<plh_> ... no need to do more today on this

<plh_> Florian: +1

Eb6

<plh_> Florian: probably part of the changes. we'll need to keep iterating

<plh_> Jeff: I'd like to get us scheduled into PSIG to help clarify the AB discussion

<plh_> ... PSIG meets monthly, probably middle of the month

<plh_> ... my advise is to reach out to Wendy

<plh_> ... to get clarification for EB

<fantasai> Their next meeting is July 8th

<plh_> ... hopefully we can get it done in August

<plh_> ... write to Wendy and Don if you can be ready by Monday

<plh_> ... who knows if folks will show up to that meeting as well

<plh_> Florian: we'll try

<plh_> [break]

<fantasai> plh, can you updated the wiki at https://www.w3.org/wiki/Evergreen_Standards

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

EB7

<plh_> Jeff: we're trying to do something for a communityn of editors that want to do something they feel they can't do with W3C

<plh_> ... it's more important that it works for them

<plh_> ... for WebIDL, thank you Fantasai to follow up on EB

<plh_> ... we discussed Editing

<plh_> ... webappsec

<plh_> ... Wendy suggests that webappsec want a more agile process, with tip-of-tree

<plh_> ... I'm not proposing to solve that today, just want to make sure, we'll need to reach to webappsec and test EB as well

<plh_> ... other reason is that Mike mentioned that some spec writers that are contemplating where to go, it would be nice to get their feedback

<plh_> Florian: my answer to Wendy [ quoting his email ]

<plh_> ... the agility is there, the only question is how you call it

<fantasai> florian: It's only REC after REC, it's agile throughout

<plh_> Fantasai: publishing/updating is difficult. we made it easy to publish a working draft

<plh_> ... but having a maintained REC is still hard

<plh_> ... whether you call it EG and EB, we need to fix that

<jeff__> PLH: I'm skeptical that EB is easier than current process in maintaining the REC

<jeff__> ... willing to be proven wrong

<jeff__> ... but EB may not simplify REC

<jeff__> ... fiddles with process

<jeff__> ... but still have all the requirements of the process

<jeff__> ... just simplifying transitions, publications

<jeff__> ... I agree not simple today

<fantasai> https://lists.w3.org/Archives/Public/public-w3process/2019Mar/0076.html

<jeff__> ... to maintain --> hardest thing is to find someone who can do it

<jeff__> EE: You need to read ^^ before you say that

<jeff__> ... EB, EG are addressing that (a) you can fix a big immediately but (b) takes forever to get on W3C website

<jeff__> ... Website is so out of date

<jeff__> ... so much effort that I won't do the work, maybe once every three years for a REC I will try

<jeff__> ... for CR, maybe once a year

<jeff__> ... for some specs, every 6 months

<jeff__> ... need to make specs updateable

<jeff__> ... get to 0 issues

<jeff__> PLH: Never true that you need to get to 0 issues

<jeff__> ... we always publish with open issues

<jeff__> FR: REC?

<jeff__> PLH: Even on RECs

<jeff__> ... working on one today

<jeff__> ... yes, difficult

<jeff__> ... but not clear that EB makes it super-easy

<jeff__> FR: Need calls to make change stable

<jeff__> ... not needed to put into the spec

<jeff__> ... marked as provisional

<jeff__> ... extra work to remove maturity markers

<plh_> Jeff: the key point I was trying to raise is just that we have to the intended beneficiaries and check with them

<plh_> ... and get them to weight in on the 2 proposals

<plh_> ... Mike, is there a set of folks at MS to check with?

<plh_> Mike: me and Travis basically

<plh_> ... most of the specs we're thinking about taking to the WICG

<plh_> ... I was thinking more about ms2ger and Mike West regarding living specs

<plh_> ... nobody besides showed interest in investing time in this on the MS side yet

<plh_> Jeff: ok. happy to work with you and Travis

<plh_> [Jeff re-exposing the plan]

<plh_> Mike: I'll be happy to circulate things in the AB once the proposals are more refined

<plh_> Jeff: 2 additional issues: EB8: frequency of running process (AC reviews, PP reviews)

<plh_> ... EB9: EB is more radical than EV, since it changes the definition of Recommendation

<plh_> ... since they don't have full reviews of everything yet

<plh_> ... maybe "Living Recommendations" instead

<plh_> Florian: yesterday, I did make the changes in the EB proposal

<Zakim> florian, you wanted to bring up two additional questions

<plh_> Florian: 2 additional topics

<plh_> ... one difference is how to mark things

<plh_> ... with EG, you have maturity annotations

<plh_> ... with EB, you have proposed changes

<plh_> ... at every publication on EG, the editor is supposed to update the maturity status of every mark

<plh_> Jeff: for 180 days, you can put the entry date

<plh_> Florian: but on everything single feature, that sounds like a lot of work for every mark to update them

<plh_> Jeff: when something makes implementation commitments, that's when you make the updates, ditto for implementation experience

<plh_> ... if nothing changed, you don't need to update

<plh_> Florian: the text in the evergreen process suggests that each mark gets updated...

<plh_> Jeff: a valid implementation of that is to keep as-is unless you heard otherwise

<plh_> ... the word must doesn't convey that you have to update everything single one of them

<plh_> Florian: characterizing the level of implementation could take some judgments

<plh_> Jeff: it's caniuse level updates

<plh_> Florian: I don't disagree that having the information is bad.

<plh_> ... so since Mike Champion characterized it as a way to know which part of the spec is stable....

<plh_> Jeff: you can't overclaim, but you can underclaim

<plh_> Florian: since we're talking about making changes to existing features, caniuse is rarely granular enough to provide this level of information

<plh_> Jeff: I was using caniuse as a level of frequency

<plh_> Mike: whatwg solved that by tooling

<plh_> ... the support table are generated

<plh_> ... with the plan to use WPT

<plh_> ... I agree that doing it by hand would be a lot of work, but if you can put the proper data, that would be more efficient

<plh_> Jeff: EG will need to clarify their proposal

<fantasai> I think we need a process that works reasonably well without tooling, and can be improved by tooling

<jeff__> PLH: Doesn't tell you about the coverage?

<plh_> Florian: given that we're not just worried about the specs but also details, caniuse won't help you

<jeff__> FR: We don't have a tool that says whether everything is covered

<florian> +q fantasai

<florian> q later

<jeff__> PLH: Current trend to integrate WPT, MDN into specs in general

<jeff__> ... today need more granularity

<Zakim> plh_, you wanted to give more thoughts about WPT/specs integration

<jeff__> ... even though we lack tooling today, EG will leverage those trends in the future

<Zakim> fantasai, you wanted to say that we need to be realistic

<plh_> Fantasai: it would be foolish of us to adopt a process that cannot be implemented without a tooling that we don't have

<plh_> ... we're assuming we'll get more data and integrate them to make EG work

<plh_> ... we shouldn't make this presumption

<plh_> ... and be ready to deploy next year

<plh_> ... we need a process that would only take a week to deploy

<plh_> ... rather than relying on tooling that we don't have and may never have

<plh_> ... it has to work without the hypothetical

<plh_> ... the tooling required for EG would take 2 years for 5 engineers to deploy

<plh_> Jeff: the green team has to say how it will work on day one

<plh_> ... and a few months later

<plh_> ... this needs to go into the proposal

<plh_> ... and EB disagree, we'll itereate

<plh_> ... we'll find things out as we are moving forward

<plh_> Florian: an other thought: if we plan to use caniuse, caniuse has one feature for CSS Grid, a 100+ pages spec

<plh_> Florian: second question for EG: wide review

<florian> https://w3c.github.io/w3process/evergreen/#wide-review-er-track

<plh_> ... in EG document, [reads EG proposal on wide review]

<plh_> ... is it true that wide reviewers cannot operate on that timescale?

<plh_> ... the review on an evergreen document should be wide

<jeff__> PLH: Today for horizontal review (subset of wide review)

<jeff__> ... groups say they cannot look at every change

<jeff__> ... so we batch them

<jeff__> ... and even that is too many reviews for them

<jeff__> ... that's why EG takes the batch approach

<jeff__> FR: But that happens on the REC track

<jeff__> ... wide review happens incrementally

<jeff__> ... worry will let editors off the hook

<plh_> Jeff: CSS is working on 50 documents, if we need to do reviews once a week, with EB, we'll get the same reaction. it's an ever* in my mind.

<plh_> ... continuous development has this issue broadly speaking. horizontal reviewers can't review on ongoing basis

<plh_> ... we documented the issue in the EG proposal

<plh_> ... if folks become lacks, it may be well

<plh_> ... regarding the diff with today

<plh_> ... if we make many changes in many documents, we're only asking them to look at changes before transitions

<plh_> ... but we'll confer more status in EG/EB much more frequently

<plh_> ... can we deal with it and how?

<plh_> ... EG suggests a sliding window and we batch the snapshots

<plh_> ... and we assumed that we could do a REC pass from time-to-time

<plh_> ... it may be an issue with EB

<plh_> Mike: agreed this is a hard problem. wide review vs ongoing updates

<plh_> ... and certification comes along later

<plh_> Florian: not disagreeing. horizontal groups complain we're doing reviews too late

<plh_> ... they're calling for better practices/tooling

<plh_> ... the difficult of doing horizontal reviews is true

<plh_> ... don't know if it needs to be baked in EG/EB

<fantasai> r12a's comments on horizontal review - https://github.com/w3c/w3process/issues/130#issuecomment-505847681

<plh_> Jeff: the big issue they have is frequency and we can't ignore the frequency increase issue

<plh_> ... otherwise they'll push back

<plh_> ... if you increase the number of Recs, you need to address the issue

<plh_> ... you need to address the horizontal reviews community

<plh_> Florian: with 200 things getting to REC, the amount of changes will not vary, as editor's drafts are moving very fast today,, so we have the issue today in any case

<plh_> ... maybe we can address it separately

<plh_> Jeff: I don't want to propose a change to the process and get pushback from the horizontal review folks because they won't know how to deal with it

<plh_> ... we tried to address this in EG

<plh_> ... by having these snapshots

<plh_> ... by ack the problem

<plh_> ... and by making it experimental, selling on faith that it's a worthwhile experiment

<plh_> ... just trying to explain the rational

<plh_> ... ie addressing the perception that horizontal groups are suffering today

<mchampion> It could be part of the “contract” with WGs that want to work in Evergreen mode that they have appropriate horizontal reviewers engaged in the WG, and tooling I place or editors committed to do the work by hand. So the horizontal communities can engage on their current rhythm with come assurance the spec isn’t going off into the weeds between wider reviews

<plh_> Florian: ok with management expectation

<jeff__> [interesting proposal, Mike]

<plh_> ... I suspect that EG proposal will not get well received

<Zakim> fantasai, you wanted to address experimental failures

<plh_> Fantasai: if we put a process which is half-baked, it's a lot of effort to adapt, etc.

<plh_> ... we should make a really good effort to bake our process proposal and that it will be well refined/thought

<plh_> ... we need something pretty solid rather than just experimental

<plh_> Jeff: agreed. the green team thought the socialization process would take a while

<plh_> ... like the document license

<plh_> ... we started small with HTML, then spread the experiment

<plh_> ... so it's a socialization issue

<plh_> Fantasai: you need to be upfront how solid the proposal is

<fantasai> fantasai: You were not presenting it as a solid proposal whose "experimental" status was primarily for socialization and not for testing and exploration

<plh_> Jeff: ok, we've got through the issues.

<plh_> ... next steps...

<plh_> ... can we get both sides to continue to iterate on each proposal, keep each other informed, work on a single presentation, ...

<plh_> Ralph: I'm in the teal camp. I'm happy to keep iterating and may join the blue team on some topics

<plh_> Florian: on the blue side, we need to do rate limiting and patent policy. horizontal reviews, ...

<plh_> ... AC reviews and patent could be solved but need more thoughts for HR

<plh_> Jeff: also need to reach to presume beneficiaries, have a common presentation

<plh_> ... should we let blue and green and iterate by themselves

<plh_> [scheduling next call in the week of July 22]

<plh_> Next call on July 22, same time

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/veil/vil/
Succeeded: s/tags/status tags/
Succeeded: s/on the changes/on the changes, so there is coverage of changes to the REC as well as the REC itself/
Succeeded: s/CfC/CfE/
Succeeded: i/Jeff:/fantasai: So I would like us to stop being confused about if there is an issue on here, there isn't, the patent policy is very clear on how it works with changes
Succeeded: s/PISG/PSIG/
Succeeded: s/editing early/Editing/
Succeeded: s/EV/EG/
Succeeded: s/do the work/do the work, maybe once every three years for a REC I will try/
Succeeded: s/EV/EG/
Succeeded: s/vary/vary, as editor's drafts are moving very fast today,/
Succeeded: s/will be/and that it will be/
Present: Florian Ralph jeff_ plh_
Regrets: Wendy
Found ScribeNick: plh
WARNING: No scribe lines found matching ScribeNick pattern: <plh> ...
Inferring Scribes: plh

WARNING: 0 scribe lines found (out of 471 total lines.)
Are you sure you specified a correct ScribeNick?


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