<fantasai> ScribeNick: fantasai
[agenda fiddling]
jeff: Florian, fantasai, and
Wendy did a terrific job preparing for the call
... sent material to PSIG before the call
... Wendy and fantasai did a great job providing a concise
description of what the Process changes were and what Patent
Policy changes were needed
... There were 7-10 attorneys on the call, more attendance than
usual, which was great
... amount of familiarity with Process 2020 was highly
variable, which created some challenges
... nonetheess got through agenda
... Comments were in three categories
... First, there were comments about the minutiae of the
proposed patent policy changes
... Not time on the call for us to thoroughly thras through and
reach consensus on these
... 2nd class of comments, new to me, had to do not with Patent
Policy itself, but with process of how a new patent policy gets
introduced
... questions like how do we get agreement on it, are people
signing up without consent, does it apply automatically to all
WGs, is it retroactive?
... Need to address these
... Third set of comments, some pushback on how we're doing
things within Process 2020
... If we had done things in P2020 different here/there, maybe
simplify changes to Patent Policy
... Those are main categories of comments we received
... 1.5hr call, fairly short considering magnitude of the
change
... PSIG members were asked to send their comments to Wendy and
to PSIG ML over next week or so
... Based on categories, most urgent for PSIG to deal with
patent policy
... and we deal with transition afterwards
... Next PSIG is scheduled for January 13
... Depending on comments and when they come in, Wendy might or
might now have time to prep revision
... Chair proposed to increase frequency of meetings rather
than once/month
... Decided not to due to holidays yet, but might consider
iafter the holidays
fantasai: wrt retroactivity etc.,
we need a transition clause inthe Patent Policy so that part
can't happen later
... definitely varying levels of familiarity with what's going
on
dsinger: overview?
florian: One thing that made
Everblue changes hard to understand
... is that Chapter 6 of the Process was already messy and hard
to understand
... So we spit changes into two phases
... First to make changes to make CHapter 6 more
understandable
... then actual changes to Process
<dsinger> see the Github process readme for section-6 cleanup and everblue branch: https://github.com/w3c/w3process
florian: Thhe editorial changes
are mostly moving things around
... occasionally merging sentences
... Reason why this Chapter is a mess
... is that it largely started with definitions of each
maturity
... and largly described how to transition from one to the
other
florian: but there were bits of
definitions in the transition process descriptions, and bits of
transition process descriptions in the maturity
defintions
... So we tried to untangle this
... 95% moving sentences, 5% merging/rephrasing sentences
... At the end of these changes (link above)
florian: we apply Everblue
changes
... This next diff (above) is against the refactored Process
document
... so easier to understand the changes
plh: I don't think Process should
say that we're entitled to markup changes in a REC
... we have a modification-in-place policy
florian: This is not new. This is all existing stuff, haven't changed.
plh: Next is editorial changes,
we always allow editorial changes
... we always allow editorial changes
... If you want to make editorial changes, we try to give you a
clean path to do it
... You were talking about moving things around, maybe add a
sentence that you can always make them by republishing the
document, status of document doesn't matter
florian: When we did this clean
up, goal was to not change anything. Just move around to be
easier to read.
... Your suggest seems to be to make a revision of the Process
where we refactor some stuff a little more
... Related to this, there's concept of Edited REC
... Process has some confusion as to what that is exists
... but, if you make an editorial change to a REC, it's called
Edited REC
... I think could simplify by making them not a special class
of REC
... but that's a larger change
<dsinger> Suggest PLH submits simplifying pull-request(s)
plh: We don't surface the concept
of Edited REC into our document sin practice
... Even if Process changes to give special labels to things,
we can make their status present largely the same as existing
status
... don't need too many status types, confusing to
community
... can put stuff in Status of the Document
florian: There was also some
concerns about making Process shorter and more conceise in
general
... Jeff suggested we should tackle after P2020
... because it's more changes, and we're already doing a lot of
changes
dsinger: I would suggest we look
at what changes plh would want, and then decide
... would be against clean-up branch?
florian: I'm happy to work with plh on the changes, just want us to know if we're doing now or later
dsinger: Would like to next do
description of Everblue branch
... try to get towards merging these into the main doc
florian: OK, so clean-up is mostly moving things around, maybe let's review, issue CfC, and merge it in
dsinger: I'm willing to read it in detail
fantasai: I've reviewed in detail
because co-edited changes with Florian
... Jeff reviewed in detail, sent many comments, which were
addressed
florian: Changes in
Everblue
... Major change is introducing two types of CR
... another is defining amendment process for REC, invoking for
class 3 changes and class 4 changes slightly separately
... Factored out "update request"
... Had "transition request" previously
... but "update request" for CR revisions was embedded in
CR-sepcific section
... we pulled it out so that it could be re-used for
republishing RECs
... Then there is bit of defining the two subtypes of
RECs
... Then some smaller changes
... There are 2 open issues I'm aware fhtat are worth talking
about
... One talked about on the ML a lot, framed differently in
various times
... issue ????
... Distinction between ERECs and plain RECs
<dsinger> https://github.com/w3c/w3process/issues/345
github: https://github.com/w3c/w3process/issues/345
florian: mchampion gave a useful
distinction between producers and consumers of RECs
... Labelling RECs that can accept new features those that
can't differently was a feature not for producers of RECs, but
rather consumers RECs.
... Historically RECs have not been able to accept new
features
... could accept corrections, but not new features
... so current proposal does not change this
... so that ppl who want scope of feature-set fixed are not
surprised and can continue to have that
... Separately we have ERECs, which are exactly the same as
RECs, except that changes can include new features
... suggestion was to have this distinction listed in the
charter, so that AC can review this distinction
... For awhile it wasn't clear if people understood the
motivations for this distinction
... but now that seems to be the case
... Seems nobody except fantasai and I think this is a useful
distinction to have
... most others seem to feell that it's not useful
mchampion: jeff suggested just putting this info in the Status of the Document, whether certian paths in PRocess were used
<Zakim> jeff, you wanted to comment on the new topic and to provide a pointer to the email discussion
florian: The distinction isn't so
much which *was* used, but which *will* be used
... but yes, could put it in Status of the Document
<jeff> https://lists.w3.org/Archives/Public/public-w3process/2019Dec/0026.html
jeff: mchampion's suggestion to
simplify got +1 from a number of people
... Florian said willing to fold
... Main point here is to simplify document, think that has
pretty wide support
fantasai: ...
plh: In practice, we do supersede RECs
fantasai: That's different
... It's a new document that supersedes
... It doesn't change what has been referenced by other
documents
plh: But if you accept fixes, you're making changes anyway
dsinger: Differences in referencing. Referring dated versions vs referencing "top of tree"
florian: ISO is not a problem,
they used dated drafts
... but Bluetooth or HbbTV are better examples, they don't
republish our stuff, they reference
dsinger: Most groups use dated versions, WHATWG asks to not do that
plh: People can reference whatever they want, let's simplify the Process
dsinger: I'm all in favor of
simplifying Process as long as two communities understand
it
... One is lawyers
... the other is the outside world, and we need to be clear
with them how to refer to this thing
... and refering to top-of-tree
... if that's covered by Status of the Document rather than
formal Process or whtaever, fine, but I do want it to be clear
to those two communities
<Zakim> jeff, you wanted to say that Elika's concerns are the reason to put something in the SotD; not needed in the process
jeff: Want to say briefly that I
embrace Elika's concerns, but in the balance, as discussed on
ML, is that including it in the status of the document was
sufficient clarity to base decisions on
... cleaning up the Process was more improtant
florian: With 2 audiences
concerned, I'm not concerned about lawyers, because RECs that
don't acquire new features still acquire fixes
... and from patent PoV any change is relevant
... Other audience ...
... At this point I think better to simplify Process because
there seems to be a lot of confusion
<jeff> +1 to Florian's FAQ idea.
florian: but that when we present to the AC we explain this situation, in case they want something different
fantasai: ...
dsinger: does this mean we can make such changes to any REC?
fantasai: Yes, any REC, including ones already published
dsinger: but can do that already right?
florian: No, you can make fixes,
but you cannot add new features without starting a new
document
... This changes that
dsinger: You could make that change even to an old REC, already published?
florian, fantasai: yes
mchampion: Why do that instead of revving the version number?
florian: If we don't ban the functionality, we shouldn't be surprised that people use it?
dsinger: It's likely lots of
small changes that people want to make, but haven't because it
was painful in the past, so by no means unlikely
... I think we need to think through this
fantasai: Should I change the title of the issue to be more general? discussion in issue is broader
jeff: Lots of ML discussion
dsinger: link issue to thread
florian: So what are we trying to do, are we asking AC?
dsinger: I think with next Process call, we decide on whether to act on 345 or not
florian: but are we pinging AC?
mchampion: Is there any other questions to put to the AC?
fantasai: I don't think so... this is the only one that changes something about our output, and that we aren't clear that we want (like CR stuff). It changes what a REC means, which might be relevant to people who don't care so much about details of PRocess
dsinger: Changes meaning of existing RECs as well which is significant
jeff: I'd like the chair to find
a way for the CG to collaborate on how we present this to the
AC
... I think depending on how it is phrased to AC, could change
outcome of AC feedback
dsinger: Suggestion was to bring
the question up to the AC until we present the Process
... ...
<jeff> +1 to the three decisions
dsinger: Three things we need to decide are * merging clean-up branch * merging Everblue branch * folding EREC and REC
<dsinger> github: https://github.com/w3c/w3process/issues/346
STOP
somebeody screwed up the minutes
and my sound is out
I"M NOT MINUTING YOU FLORIAN
<dsinger> github: https://github.com/w3c/w3process/issues/345
github: https://github.com/w3c/w3process/issues/346
florian: We have these two types
of CRs which are analogous to what's happening in WHATWG:
snapshots vs updates
... The difference with WHATWG model is snapshot is not only
for lawyers, it also has Director's review, which checks for
wide review, horizontal review etc.
... We discussed it's good to tie carrot and stick
<inserted> scribenick: jeff
florian: without verification the
work does not get done
... good idea to tie carrot to the stick
... this is intentional we discussed many times
... many people agreed, but Wendy does not.
David: People should just post to the issue.
Mike: I agree with Wendy. Cannot close this.
<fantasai> ScribeNick: fantasai
<jeff> David: 345 and 346 for next call.
dsinger: ???
florian: Move them to Process 2021
dsinger: issues 28 and 182 will
move to 2021 unless something happens Very Soon Now
... before next call, we need to be very crisp on which issues
we'll deal with for Process 2020
... so tag issues, discuss, we need to close down the list in
January
florian: Question to Jeff, the issues you filed, did you want them addresed?
jeff: All for next section,
except the class 3 / class 4 changes distinction
... I don't think we should distinguish these things in the
Process
... Should both exist, but right now we have different modules
for how to deal with class 3 vs class 4 changes
... I don't think there should be two different paths for
that
florian: I don't understand how this is different from Extensible Recs
jeff: Not a nomenclature
issue
... whether we have differnt paths
<dsinger> Chair says that ONLY by tagging agenda+ after we clean out after this call, will something be dealt with in this revision
<dsinger> https://github.com/w3c/w3process/labels/Agenda%2B
dsinger: Currently Agenda+ 3
issues
... if you want something else in Process 2020, mark it Agenda+
or else we *will not address it for Process 2020*
... we cannot review 30 issues on every call
... next call is formally on the 25th of December
... I suspect we'll not make it, so let's drop that call
... restart in January
<jeff> +1
dsinger: clear list of issues
that we address
... formally accept Everblue, clean-up
... and then registries for following call
... anything else before we adjourn?
... meeting closed!
<wseltzer> [belated regrets, calendar sync and flight delays]
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/started/largely started/ Succeeded: s/documen/document/ Succeeded: s/fee/seem to feel/ Succeeded: s/HPTV/HbbTV/ Succeeded: i/... without/scribenick: jeff Default Present: dsinger, jeff, plh Present: dsinger jeff plh florian Léonie (tink) Regrets: anna wseltzer Found ScribeNick: fantasai Found ScribeNick: jeff Found ScribeNick: fantasai Inferring Scribes: fantasai, jeff Scribes: fantasai, jeff ScribeNicks: fantasai, jeff WARNING: No meeting chair found! You should specify the meeting chair like this: <dbooth> Chair: dbooth Found Date: 11 Dec 2019 People with action items: WARNING: IRC log location not specified! (You can ignore this warning if you do not want the generated minutes to contain a link to the original IRC log.)[End of scribe.perl diagnostic output]