Revising W3C Process Community Group Teleconference -- 27 Jan 2015

<trackbot> Date: 27 January 2015

<timeless> scribe: timeless

Add self-reference links in document

timeless: could section headings be self links, so that i could more easily link to sections?
... currently: "4 Dissemination Policies"
... it's annoying to get that as a url, and usually involves losing one's place

<chaals> [Sure. It's an editorial change]

timeless: <h2>4 <a id="dissemination">Dissemination Policies</a></h2>
... instead, i'd favor:
... <h2>4 <a href="#dissemination" id="dissemination">Dissemination Policies</a></h2>
... thanks :)

Review Open Action Items

SteveZ: there aren't any
... i had one from last week

ISSUE-152: Process2014 Regresses Editorial Revision of RECs

SteveZ: to track down how the change to require a CR before doing a Proposed Edited REC came into being
... was it conscious or accidental
... i spent time doing that, i still don't have the answer
... i still can't find in any of the minutes that i can search
... revising-the-process ML
... any discussion of that particular topic, at least mentioning "Errata"
... i didn't check for "Edited Recommendation"
... i looked at when the change occurred
... my guess is it happened because we dropped the Proposed Edited Recommendation section
... there's a lot of time lag
... there were a lot of changesets in Process 2014
... it happened pretty early
... what i could find is that it didn't seem that you needed to do a LC before Proposed-Edited-REC
... but that would seem to mean that we shouldn't be able to do substantive-changes
... i'm a little confused about that

<chaals> issue-152?

<trackbot> issue-152 -- Process2014 Regresses Editorial Revision of RECs -- open

<trackbot> http://www.w3.org/community/w3process/track/issues/152

SteveZ: it's hard to tell in Process 2005 what was required to publish an Edited Recommendation
... other than that you had to announce a Review of a Proposed Recommendation
... i can't find evidence of a conscious decision to change the process
... but i haven't spent enough time reviewing
... ... that the change editing
... because there's a Patent Exclusion point
... and people think that's a good thing

<Zakim> chaals, you wanted to suggest you look for discussion of changes.

chaals: "classes of changes"

<mchampion> Why do we need a patent exclusion point if there are no changes with IP impact?

SteveZ: requiring a CR as entry to Proposed-Recommendation is a good thing because it defines an Exclusion Point

chaals: we don't actually have any clear mechanism for determining whether there's a patent-problem beyond a Review
... explicitly asking for review is a way to take a responsible approach
... assuming that there isn't is courageous

mchampion: anything having to do w/ Patent Law takes a certain amount of courage, anyone can sue anyone for anything
... it's a practical question / balance of risk/reward
... as long as there's a good instruction to "changes MUST not expand ...; only to fix / correct misinterpretations / correct spelling"
... it should be hard for a Patent to hold on the edited and not the original
... we're getting a strong push from the community that W3C is too optimised for Process, and not enough on on Agility
... i think we should continue to optimize for agility
... there's some risk, but a bigger risk that the organization will fade into irrelevance
... and recommendations will come from elsewhere w/ zero patent protection
... we should work to royalty free patent commitments
... that's why we're working on the process

SteveZ: reasonably sure there were concerns raised in PSIG discussion
... i understand we can make a case for ignoring PSIG discussion

chaals: couple of points...
... not sure we're optimized for Process
... one thing we try to optimize for is Royalty Free Commitments that are believable
... i'd dispute that agility is more important that Patent commitments
... we do have a serious value for making sure that Patent Commitments hold
... 2nd... PSIG discussed this recently
... they have a question of Patent commitments for PERs [?] vs. PRs
... if the group got it right for PR, then great
... if the group got it wrong, then 12 good people of texas will have their heart and minds
... because W3C Process doesn't trump Patent Law
... Substantive changes could introduce a Patent that we hadn't intentionally avoided
... the Touch PAG
... says that if you explicitly mention an ellipse, then you're violating a Patent
... if you just say measure a region, then you aren't
... the Widget Update PAG says
... that if one thing is responsible for managing an update, then you're violating
... if a different thing is responsible for managing the update, then you're not
... [violating that patent]
... which is why it's worth reviewing for patents
... it adds 4 weeks
... i don't see that as a big deal
... there's another issue

issue-99?

<trackbot> issue-99 -- Can we shorten the timelines required by the patent policy -- closed

<trackbot> http://www.w3.org/community/w3process/track/issues/99

chaals: issue-99, which says you can't go to REC w/ an open exclusion period
... which would slightly stretch that time
... if we make it you can't open/enter/close, then it extends/doesn't
... up to 5 weeks depending on choice
... can't close CR, extends 5 weeks
... those are variables that are in play
... i'm not convinced that there's value in avoiding CR review for the sake of agility
... it doesn't seem a lot of agility is gained
... there are people who claim, including those who have excluded patents from W3C specs
... that if they haven't been given an opportunity to exclude
... then they aren't obliged, and can just come along later and sue
... which leads me to think that a CR isn't a bad thing to do

<Zakim> SteveZ, you wanted to say "wheelchair"

SteveZ: chaals you said what i needed to say, so i don't need to say anything

mchampion: we're making one little review period/process at a time, making W3C less attractive to do work in
... that's what i'm seeing, not sure about others

SteveZ: not disagreeing, but the main reason that some folks who are in whatwg are in w3c for is patent-protection
... if we undercut that, it doesn't seem good either

mchampion: chaals made a good case
... the examples were enlightening
... i hear the main point, you can make small technical changes
... to an implementer, but which open up a huge loophole to a lawyer
... we should make it very clear what class of changes are allowed in an Edited REC
... w/ those examples in mind, make sure we craft language which would flag them

chaals: "if you make changes to conformance, go to CR" "if you don't, then you don't need CR"
... do you have some example to make it more clearly?
... engineers don't have a clue what patents cover/don't
... based on experience suffering through PAGs caused by engineers

mchampion: patent commitment goes for scope, not conformance
... you could cause a problem by camel casing something in one place and not in another place
... it stretches my imagination whether that

chaals: that particular case has come up

mchampion: i'd be much more comfortable if we worried less about the lawyers
... who'd be happy if we did absolutely nothing

<chaals> [The camelcase change didn't come up as something that forced a return to PR, but it has occurred]

chaals: you can be [sued for doing nothing]

mchampion: i'd agree that w3c's value proposition is tied up w/ the royalty-free patent commitment
... but people won't make that commitment, if we don't have value
... the better thing would be to fix camel casing in substantive CR process

chaals: agree

mchampion: bit of a corner case

jeff: i'm not aware of how often anyone would want to go through the P-E-R process
... i support mchampion 's concern about agility
... P-E-R is rarely used
... i'd lean more toward chaals 's concern that it isn't used
... but if we expect it to be used all the time, then
... i'd be more respectful of mchampion 's PoV
... i don't have a way of getting data
... i don't remember a lot of PERs

SteveZ: PERs haven't been frequent
... the main concern that fantasai raised
... this change of requiring a CR makes it even less likely that it will happen
... a fulfilling prophesy

<mchampion> No doubt there aren't many PER's ... but arguably that's the problem we're trying to address here. People believe, with some justification, that W3C Recommendations are full of errors that are never fixed whereas Living Standards are kept up to date

SteveZ: if this is done through the normal process, then
... the normal evolution of a spec requires the REC process

jeff: if we think it's moot
... let's not give the impression to lawyers/ISO that we're cutting corners

SteveZ: i'd like to leave this topic to AC to review
... and i still need to give some work to look for "class of changes" in the ML and Editing Log
... to see if we did this as a conscious decision or not
... if we do nothing right now on the draft that we have
... our preferred option if PERs are rare, is what's there
... the question that needs input from the world/chairs
... and i can send a message to chairs@ to see what their input is
... on what their preferred mechanism for maintenance
... certain RECs, the XML groups use PERs
... because they aren't changing those specifications

next meeting

<chaals> scribe: chaals

timeless: DIdn't know XML uses PERs.
... if we are making it useless should we drop it entirely?
... if groups use it, clearly not.
... can we get moreinfo about their usage?
... we should cater to those who use or are lkikely to use. My assumption is that a couple of extra weeks wouldn't matter
... if there are other groups who would like to use PER but don't, there may be a point in looking at changes - but otherwise, we are building castles in the air.
... If you are going to make a PER change, and a couple of weeks later plan another one, you might start holding off changes in order to reduce the churn of repeated requests.

SteveZ: That problem hasn't arisen yet.

timeless: Assuming that is the case. We could automatically do them on a calendar cycle.
... would assume lawyers are happier with predictable schedules.
... engineers are used to working iteratively in code, if something doesn't get fixed for one release, you do it for the next -- the same can apply to PERs

SteveZ: There are release cycles for specs.

<timeless> scribe: timeless

chaals: XML, RDFa, HTML have used PERs
... you can use the Recommendations list and looking at the Edition number
... "second edition", "third edition", etc
... or look at the stuff that AC reps get presented
... XML, RDFa has used them, HTML used them (including introducing substantive changes)
... my guess is like timeless
... the people who use them don't use them much
... if they're using them to address Errata, we currently have a quarterly requirement
... i don't think people will freak out about a couple of weeks
... the UCs aren't for a whole new version, just a couple of tweaks

SteveZ: would people object if i sent a message to chairs@
... basically summarizing the discussion we had today
... and the direction we had today
... and explicitly asking whether the people who use PERs feel this is a reasonable approach

<Zakim> jeff, you wanted to object

jeff: why make waves
... we're doing a public process, the chairs are able to join, encouraged to join
... there's an opportunity to do an AC review
... why suddenly

SteveZ: i'm fine w/ not
... we're aware of some people who use PERs, and some people may be planning to
... i'm fine w/ leaving the discussion here
... updating issue-152 w/ a summary of this discussion
... jeff and i won't be available on the 3rd and 10th
... i propose to cancel those two meetings
... objections?

[ None ]

RESOLUTION: meetings for Feb 3rd and 10th are canceled

SteveZ: i'll send around a list of issues that perhaps should change state (raised/open)
... we've pretty much stabilized Process-2015
... we should start to look for Process-2016 activities

AoB

jeff: the AB plans to do a major review of this work on Feb 12th

RESOLUTION: SteveZ i'll send an email giving people a heads-up about the AB review on Feb 12th

SteveZ: i'm on track to do a Chairs call on the Process
... where i'll socialize public-review-announce@

[ Adjourned ]

<chaals> [thanks all, especially josh for scribing]

- DRAFT -

Revising W3C Process Community Group Teleconference

27 Jan 2015

Attendees

Contents

Add self-reference links in document

Review Open Action Items

ISSUE-152: Process2014 Regresses Editorial Revision of RECs

next meeting

AoB

Summary of Action Items

Scribe.perl diagnostic output