dsinger: Florian suggested
dealing with non-registries topics first to get through
them
... other changes?
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].
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
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.)[End of scribe.perl diagnostic output]