Agenda-bashing

dsinger: Florian suggested dealing with non-registries topics first to get through them
... other changes?

Ever* Update

jeff: Sent some summary emails

<plh> jeff: we tried to keep folks u[p-to-date in emails. any queston on the update?

jeff: Key emails to look at are email after July 3rd and after July 22nd
... Teams are working together to make a presentation for next week on how they solve the problems and what the differences are
... That's the highlight

<scribe> ACTION: Jeff to Send summaries to archived list

<trackbot> Created ACTION-53 - Send summaries to archived list [on Jeff Jaffe - due 2019-07-31].

Schedule update

jeff: AB passed a resolution at its biweekly call last Thursday saying that it really wants to solve continous development inan accelerated fashion
... Based on good progress of Green Team and Blue Team
... and AB's resolution
... It's essential to get continuous development for Process 2020
... But don't think we'll be anywhere close enough by August to send out a draft Process 2020 to the AC asking for review
... So i'm hopeful coming out of September meeting with a small number of months of clean-up, shoudl be able to get something to AC end of 2019
... And have a Process 2020 update early next year
... My sense is that we're behind where we were last year for 2019
... We launched March 1st, I think we're behind that because we want to get continuous development and registries right
... That's my view
... Can discuss so we have common perspective

dsinger: I agree, there's nothing compelling in current process work that is compelling
... and important to get continuous development right

florian: I think situation of non-registries and non-continuous dev is less dire than previously, but not enough to rush anything out the door
... Don't have anything significant of value

<dsinger> https://github.com/w3c/w3process/labels/Type%3A%20editorial%20improvements

Editorial

florian: 262, tempted to close with no action
... because confusion can be clarified in the Status section of the document
... Could also be explicit in Process that Status section has to say so
... but don't see a strong need to do that
... and given that we take forever to add any wording to anything, prefer to skip

plh: Not objecting
... The only thing that would be a problem is bikeshedding the name
... We have Rescinded, Retired...

florian: This isn't about retiring a REC
... This is about retiring a non-REC

plh: On the /TR page they're called Retired
... Don't care about the name
... Just need to be consistent
... We use Retired for REC as well

florian: Won't do it unless you ask, do you ask?

plh: I think you're fine. I'll look at it

<jeff> +1 to close

fantasai: It's probably nice to mark these documents a bit different, since Notes that were on REC track aren't quite the same as NOTEs that are just NOTEs.

<dsinger> https://github.com/w3c/w3process/pulls?q=is%3Aopen+is%3Apr+label%3AAgenda%2B

fantasai: Particularly since with continous development updates, we're going to have patent protection on those, but not regular notes.

<dsinger> https://github.com/w3c/w3process/pull/274

florian: That's a separate issue, though, this is just about some clarifications
... And Tantek wanted wording, but hasn't replied for 2 yrs so propose to close
... Can close later.

RESOLUTION: Closed no change

<dsinger> https://github.com/w3c/w3process/pull/270

?

UNKNOWN_SPEAKER:

jeff: Our guidelines are referenced in the Process document
... presumably if we somehow or other change PWE, that has to get balloted by the AC

<dsinger> CEPC is normatively referenced from the Process

jeff: but change the docuent and our Process document points to something new
... So seems like we need to coordinate schedule

<dsinger> “Participants in any W3C activity must abide by the terms and spirit of the W3C Code of Ethics and Professional Conduct and the participation requirements described in section 6 of the W3C Patent Policy.

<dsinger> “

jeff: and get attention on change as part of Process 2020

florian: CEPC should stay in, of course
... But Process also links to a document on disciplinary action
... that pre-dates Director's authority to do so
... It's out of date
... We should remove it

<jeff_> 4. Group priority and Publication Plan (all)

jeff: If we are about to update CEPC, and have a more robust CEPC, then that might address Nigel's objection
... PWE is having meeting next Thursday
... we should have coordination

<dsinger> https://github.com/w3c/w3process/pull/270

florian: This issue clarifies distinction between "chair's decision" which is made by chair alone, and "group decision" as made by grou with chair chairing

RESOLUTION: Accept edit

<dsinger> issues: https://github.com/w3c/w3process/issues?utf8=✓&q=is%3Aopen+is%3Aissue+label%3AAgenda%2B

florian: Some WDs become NOTEs, some becomes RECs, don't think there's a problem. Let's close it
... No comments in the issue

<dsinger> https://github.com/w3c/w3process/issues/236

dsinger: We'll close if no comment

florian: Nigel can re-open if needed

<dsinger> https://github.com/w3c/w3process/issues/251

dsinger: Prefer to discuss this with the AB, because complicated impact

<dsinger> This is tricky; we need to get the group going, and if we set rules too tight, people will work around them (as they already do).

jeff_: We try to arrange many 1st WG meetings at TPAC
... for groups chartered in summer
... many ppl are going to be at TPAC anyway
... It'll be a bad result if we aren't able to have the meetings at TPAC
... just because it's a little too close

florian: This is a good point
... There's a lot of good points, we should discuss with full AB

plh: On the F2F meeting, in my experience, if I tell ppl you can't have an F2F meeting because too soon for Process
... Companies will organize an informal meeting anyway
... So putting limits in the Process won't help with that
... Just creating potentially more informal meetings
... Realize that this won't help people on other side of issue

florian: I want to argue against this, but do I argue now or later?

dsinger: later

<dsinger> https://github.com/w3c/w3process/issues?utf8=✓&q=is%3Aopen+is%3Aissue+label%3AAgenda%2B

<dsinger> https://github.com/w3c/w3process/issues/262

<dsinger> https://github.com/w3c/w3process/issues/281

florian: Came out of Director-free discussion
... but was a broader topic
... Not clear right now it's not clear if possible to object to change in chair if done outside of regular chartering
... We considered that objecting to a chair is not particularly great method, better to just discuss with Team
... but should still have an objection process if needed

<dsinger> (see associated Pull Request https://github.com/w3c/w3process/pull/299)

florian: So the suggestion was "if there's a decision, you can object to it"
... generally

dsinger: My comment was that it needs to be clear that you can object to any formal decision
... but don't have formal decision formally defined

florian: Said that you could object to XXX Decisions, which are all defined
... all of these can be objected to

plh: We have to be careful here.
... In the past, you can object to any decision made by the Director
... including chair appointment, because that was a Director decision
... CEO Decision is a bit weird, you want to be a bit careful
... Also today we have a Steering Group that makes decisions, you can't really object to those
... Your scope is a little bit too broad

jeff_: On the issue of objecting to chair appointments...
... I'm trying to parse what htis issue is
... do we believe that in the current Process as written that it's possible to object to chair appointments?
... Is it disallowed? Or not clear how to do it mechanically?

florian: Unclear
... Last time discussed in the AB, some sense that it shoudl be allowed
... So trying to make it clear

jeff_: I'm generally not infavor of adding text to clarify that some case is allowed when it's already allowed unless it's become an issue of some sort
... Is there a case that people wanted to object to a new chair but weren't sure how or somethng?

florian: It was surfaced during the discussion of Director-free
... This was soemthing Director did, that some other method would be needed
... Raised question of how to object to it

jeff_: Another question
... Do we think the Team has the authority to appoint a new chair if one steps down?

florian: In Director-free then yes, Team does this
... Because Team has less theoretical authority than great Director, what about if AC disagrees

plh: Distinction between appeal and objection?

florian: ...

plh: Why would AC have option to appeal but not object?
... We need to be clear of who can object and who can appeal

florian: Appeal isn't a general-purpose mechanism for everything
... It can be invoked in limited circumstances
... More cases there's formal objections
... and there are some other things where there's nothing

<jeff_> https://www.w3.org/2019/Process-20190301/#WGArchiveMinorityViews

florian: Trying to make so have formal objections in those cases

jeff_: Unsure about formal objections in this round of Process
... The formal objection definition is mostly about technical arguments
... technical arguments to change the chair?
... Lots of stuff which could be cleaned up
... Not sure why pick this particular issue
... Don't disagree with the logic, but not obvious worth doing at this point.

florian: Issue was discovered during Director-free discussions
... found to be more general than Director issues
... No particular urgency to fi

jeff_: Would need to do some significant clean up of this section in general
... This section should say "Decisions are made in W3C by WG, Team, whatever"
... and each decision can be objected to

florian: Isn't that what I'm doing?

fantasai: No, you're not defining everything up front like jeff suggested

jeff_: I think we need to substantially reframe decisions in Director-free
... If opening that box of code, let's do the rewrite there.

florian: So Defer until Director-free?

plh: I'm also supposed to represent again the formal objection situation in August
... If we're changing what Formal Objection is, have to take that into account
... If we say Team, and can object to decisions by the Team,
... Does this mean the Council will also have to look at those issues?
... That would potentially increase the issues that Council has to decide
... And what if person involved in Council?

jeff_: That's one of several reasons why ? had some conclusions that weren't thought through

dsinger: So punt this and clean it up as part of Director-free branch

RESOLUTION: Work on this as part of Director-free branch

dsinger: 15min left

florian: Soon, fantasai and I and Ralph will discuss registries
... so hopefully update rest of you after that

dsinger: I'd like to be involved

jeff_: Want to get status of play
... Don't have a crisp understanding in my mind of where disagreements are and how to resolve

dsinger: Having reviewed input from various ppl
... tried to collect what I thought was least constraining rules to define how to manage a registry
... Key aspect of it was that registries contain nothing that is normative or essential and therefore didn't need an IPR policy
... I haven't heard anyone pushing back against that
... fantasai and Florian concerned that rules were too abstract to actually implement a registry
... Fair, thought about that
... Didn't want to be too prescriptive, but needed guidelines to get going
... ...

florian: I think we are not in disagreemnt in theory, but maybe in practice

<dsinger> I wanted to make to make it as simple as possible to make today’s proto-registries into registries

florian: We agree with having guidelines and rules that are flexible, we agree
... We think we did just that
... /TR is not particularly constraining
... As far as I understand your idea of it
... it seems like your idea is that pre-existing things hosted elsewhere can be blessed as Registries
... instead of having one way, a flexible way, but just one way, of doing registries
... The goal is not to overly-constrain things
... the concrete incarnation of /TR for specs is more specific than the Process requires
... but we're staying at that same level

[some analogies]

florian: The point is, starting from what we have, because we're not trying to invent a new Consortium
... or to develop extensive new tooling
... but have guidelines that make it clear when something is a W3C Registry that follows W3C Registry rules
... We tried to cast a Registry process that satisfies requirements
... happened to use /TR

dsinger: what is /TR?

florian: Technical Reports is something defined in the Process
... We're recasting in terms of that
... because most, but not all, of what we needed for registries was already in the Process
... We just added the missing delta

<scribe> ACTION: dsinger to Re-read Chapter 6 of Process to better understand proposal for delta

<trackbot> Created ACTION-54 - Re-read chapter 6 of process to better understand proposal for delta [on David Singer - due 2019-07-31].

florian: Yeah.

<dsinger> https://www.w3.org/2019/Process-20190301/#Reports

fantasai: Have you seen the Process edits for this?

<jeff_> Fantasai: David, have you seen the process edits?

dsinger: Yes. Felt it was too constraining. People doing registries in uncontrolled wikis.

florian: We have people doing specs in all kinds of places as well
... Should have one clean place to put it where it's official
...
... Wrt MPEG registry, it's a large registry or a collection of registries
... There's a bunch of TSVs, the output is a bunch of tables
... and you described this as extraordinarily complex
... I don't see it's particularly comlicated, it's a bunch of tables with cross-links

dsinger: It doesn't look like a /TR document

florian: We have many /TR documents which consist of multiple pages

dsinger: examples?

florian: CSS2? SVG?
... Technical Reports aren't single HTML files necessarily
... Might want a build step
... But no reason why can't be represented as a series of HTML files
... No reason MPEG tables can't be made to conform to pubrules
... Styling will look a bit different and tweaked markup a bit
... but is the type of thing tha could be published under pubrules

dsinger: But then people will be unhappy because publishing to /TR is hard
... They'd rather post their stuff on a wiki

fantasai: They can already post stuff on a wiki.People who are happy posting their stuff to a wiki don't need Process changes. it's people who want to publish something official that want Process changes.

dsinger: but publishing updates to /TR is very onerous

florian: Between Echidna and the Process changes we're proposing, it will not be hard to update.

plh: We have two types of registries Normative ones and non-normative ones
... Non-normative can be hosted anywhere
... but normative ones, those are the tricky bits
... Things like ARIA mappings

<dsinger> (notes that I tried to write the rules such that there are no ‘normative’ registries)

plh: We need to focus on solving the normative registries

jeff_: Wrt updating /TR, is Everblue process going to fix that?

florian: Branch for everblue doesn't include the registries changes, they're on a separate branch
... The rules for registries that we propose, generally
... is that the rules for the registry, the structure of table and rules for changing it, are handled under normal REC track change process
... But changes to entries in the registry don't require such reviews, can be made same lightweight process as editorial

jeff_: could we just use everblue change process?

florian: No, becuase has rules about implementation experience, patent review, etc
... Not really relevant for registries

Meeting closed.

-dsinger

florian: I agree that ARIA mappings are hard. They've been characterized as a normative registry. Not sure I agree with that characterization... they're an API

plh: They're mapping one API to another.

florian: It's weird
... Tempting to fit into registry process
... Tempting to hope that Ever* solve it
... I don't have a great answer for this
... Using Registries for that is stretching it, but still have to do something about it. Don't have a great answer

plh: ARIA mapping is like WebIDL, they're strange beasts.
... It's very hard to classify together

florian: Even if we leave these on the side, still worth making Registries as a thing for W3C
... Consolidating all of these under a single process and publication process and list them all
... that would be good

plh: How do we communicate those things, and what kind of process do we have?
... We should have better communication of what our Regstries are, but maybe different from process
... e.g. xpointer registry, designed to be automatic

florian: Don't think we need to fix things for ppl who don't wnat to use our Process
... but bunch of ppl trying to use our Process and it's painful for them, should fix that

fantasai: Wrt xpointer, it's automatic, just fill out a form and it updates, yes?

plh: Yes

fantasai: Can do that with the Process changes we're proposing
... Define the rules as "you add a value if you fill out this form over here and its input has the following format"
... then just hook up the form to an Echidna process to publish with the update, that's it

florian: Other example I wanted to give was UI events, which as 2 companion specs
... UI Code and UI Key
... And these companion specs are trying to be Registries, and so they are forever in CR
... These things would be less painful if we make the edits that fantasai and I suggest

plh: Problem of supporting keyboards in browsers is a an 20yr struggle

florian: Spec just wants to document all the keys that is, not trying to force everyone to have a large keyboard
... Documents the keys, and the events, etc. etc.
... This is a Registry

plh: We still have WGs that are publishing registries, right now I recommend to do it as NOTEs
... kind of easy
... but I don't have a list of such documents

fantasai: What florian and I are proposing is very close to that

florian: What we're proposing is very similar to that
... but restricts the rules
... E.g. if you say that the registry is append-only
... If you pubish in a NOTE, you can change that rule whenever
... In our proposal, the rule is a bit harder to change
... but the entires are as easy to change as in a NOTE
... That's effectively what is the proposal

plh: Thing that makes ARIA Mappings uncomfortable with publishing as a NOTE
... is that NOTE doesn't carry the full weight of a Working Group
... So it's a perception problem
... and that brings them to REC which is too heavy

florian: Our proposal would address that... you don't call it a NOTE, you call it a spec
... The part of the document that describes the registry format and chnage rules, changing that is heavy
... but changing entries is in is as easy as changing a NOTE
... Stuff in the registry aren't covered by the IPR process though

plh: They have that because publishing under REC, but not sure they actually need that.

florian: So maybe Registries would solve their problem them.
...

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/authority/authority than great Director/
Succeeded: s/fantasai/florian/
Present: jeff plh florian
Regrets: wendy
No ScribeNick specified.  Guessing ScribeNick: fantasai
Inferring Scribes: fantasai

WARNING: No meeting chair found!
You should specify the meeting chair like this:
<dbooth> Chair: dbooth

Found Date: 24 Jul 2019
People with action items: dsinger jeff

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