Revising W3C Process Community Group

06 January 2021


cwilso, dsinger, fantasai, jeff, jrosewell, plh, tantek, weiler, wseltzer

Meeting minutes

Agenda bash

fantasai: looks good to me

jeff: someone recommended that we need to draw a line between things with PRs and things without

fantasai: not today. the registry stuff still needs sorting. maybe end of month.

david: we're targeting Spring AC
… informal review in March?
… so AB approval in March
… we'll start drawing lines by the end of the month
… refine the work in February

#461 - Elevating a TAG document to W3C Approved Status

GitHub: https://github.com/w3c/w3process/issues/461

David: +1 to not require Notes not to contain implementation technology
… [reading his notes on GH]

fantasai: CSS working group produced a Note that was an interesting proposal informing others
… we should clarify that Notes don't receive IP commitments

plh: example of MSE, where we published a tech mapping
… as a note. That had implementable tech

<fantasai> proposal: W3C NOTE SHOULD NOT specify implementable tech, transition request MUST include rationale for not being on REC track

plh: +1

Resolution: : W3C NOTE SHOULD NOT specify implementable tech, transition request MUST include rationale for not being on REC track

fantasai: what about the naming?

fantasai: "W3C Memorandum"

david: ok with me

<wseltzer> ask the TAG, who wants to produce the things?

jeff: at some point, we should send this to the TAG for them to comments

wseltzer: "memorandum" feels legal to me :(

fantasai: it is used in various context. UK definition for non-legal usage: "an official report about a particular subject that is written for a company, organization, or government to consider"

<wseltzer> "working paper"

<weiler> [and memorandum seems.... not-self-explanatory. it's clearly new, but it doesn't help the outsider]

<wseltzer> "paper"

<wseltzer> "whitepaper"

david: we can use "note", "report", "memorandum", "whitepaper"

fantasai: having separate names would help depending on the level of consensus

david: ok, we'll do a poll in the pull request
… I'll go with memorandum for now

Resolution: Go with Memorandum in the PR for now, bikeshed the name later

#356 - Streamlining the process document

GitHub: https://github.com/w3c/w3process/issues/356

David: how can we achieve that?

wseltzer: tried to and it's a big task
… maybe folks want to join me with a big chunk of time to attempt to do this

david: we could have a dedicated meeting for this. I still see this as a serious issue

fantasai: this will have to be done through individuals pull requests
… rather than having a meeting
… it would help if we split the document
… into separate files
… we don't have support for multi-pages documents in bikeshed

tantek: the reason a meeting would be useful is that some of the assertions are debatable.
… we should do it at the highest level rather than doing per section

fantasai: if you have a suggestion, please post it

wseltzer: less formal meeting and more folks sitting with a whiteboard on what needs to be rewritten

david: we can remove repetition and guidance

wseltzer: I doubt we'll achieve this in 2021

tantek: +1 to wendy. any large rewrite takes a while. maybe next year.

<Zakim> tantek, you wanted to note a meeting could ask/discuss what are the goals of the process document, who is the audience (today, not 20 years ago)

tantek: to help the meeting, we can start by looking at the goals and who the audience is
… it's been a while we looked into that

david: I'll encourage folks to look for redundancies and related in the meantime

#130 - Enumerate the requirements for wide review

GitHub: https://github.com/w3c/w3process/issues/130

fantasai: we need a specific proposal for text in the process. the revision of /Guide helps a lot
… we seem fine for now
… maybe we can add something next year if needed

david: ok. I updated the issue

<tantek> I like Leonie's comments in the issue

plh: Pointed to /Guide document. I don't think it answers all the questions, but agree with fantasai that I don't see what can be added to the Process document at this time

tantek: was to address a problem or make things easier?

fantasai: HRGs were getting called in very late in the game just before CR transition, which was stressful and difficult for them, wanted clearer guidance on getting involved earlier
… the process is at high level but, to make things more specific, the new guide document helps

#466 - Registries Survey

Github: https://github.com/w3c/w3process/issues/466

david: the survey needs to be as helpful as possible

tantek: I like the questions in general. little confused about how many applied to creating vs updating a registry
… 2 different stages
… having troubles to answer the survey as it is

fantasai: the maintenance of the registry is the proposal
… the process to update a registry has to be documented
… the process document does not impose any requirement on that process must be

fantasai: I'll update the proposal to include "for the registry definitions..."

jeff: i'd like to move fast on this since it's getting in the way for 2021
… we should empower a small set to finish the wording

<tantek> I would agree with that, registry table(s) should not necessarily be in /TR

david: if something is on /TR and operates under the Director, should the registry tables be under /TR?

david: we can have a w3.org URL but /TR?

fantasai: we conclude it's possible to publish the tables and the registry rules in the same document

<tantek> I'm more interested in seeing how much this process allows for non-w3.org URLs to registry tables

<fantasai> it doesn't

<fantasai> that's intentional

<fantasai> If someone wants to maintain a registry table somewhere else, they can already do that

plh: I'm fine with the tables being under /TR under the authority of the groups

david: do we need the last question about separate process tracks?

fantasai: I agree that the question doesn't need to be asked to the community
… happy to push it to the AB

david: don't feel strongly about it, just concerned

<Zakim> jeff, you wanted to comment on the length of the process document

jeff: not worried about the length of the process document. complexity/verbiage is more of a concern
… if it's a separate piece, that's fine

<Zakim> tantek, you wanted to give example of HTML and microformats rel registry

tantek: separate registries: HTML refers to the microformat rel registry

tantek: maintaining the flexibility of having the tables outside w3.org should be kept

<jrosewell> Observation: this solution (https://www.iana.org/protocols) provided by weiler looks very good for maintaining and communicating this information as I understand things. Why reinvent the "wheel"?

david: it could be a redirect

fantasai: we need a w3c url to guarantee long time maintenance of the URL
… otherwise it's not a w3c registry

<jrosewell> I see the reason to have on W3C. It's about maintaining a controlled archive. Don't we have a similar issue with use of GitHub?

<fantasai> jrosewell, yes, we do. Which is why I keep complaining about groups publishing their work at github URLs.

fantasai: we need to conclude on the survey.

<tantek> I'm ok with "registry on w3.org" meaning ok that it's a redirect or archived copy on w3.org while the actual maintained / edited registry is elsewhere (on a separate domain etc.)

david: doesn't sound like we can get rid of the last question

<tantek> yes, common practice is tables are separate from registry definitions, AND on a separate domain

david: it's a mistake to bar the common industry practices. how to verify that the registry process is being followed

<fantasai> tantek - sure, but is that because it's a good idea or because of technical / organizational limitations

<fantasai> tantek - we don't have such limitations here

<tantek> because it's what individual groups/communities want, and therefore it's what they think is a good idea. it's about agency and adoption

fantasai: goal of the survey is to get opinions on what people needs

<tantek> also, don't break existing registry processes

<jrosewell> Could we ask IANA for a copy of iana.org/protocols solution and then host it on registries.w3.org ? Then adapt that once it's up and running to meet specific W3C needs.

<tantek> also this is about re-use of existing registries

<fantasai> we're not changing any existing requirements

fantasai: the underlying question is "if you're making a registry at W3C, what do you need from us?"

<fantasai> jrosewell, if you want to host at IANA, host at IANA and reference it. Nothing preventing you

tantek: there are a lot of existing registries. you want to make it easy to reference a registry
… with heavy wording on must be on w3c, this seems a bad idea
… the primary use case is to reference registries

fantasai: we're targeting audience that want to publish registries on w3c

tantek: we should drive to use existing registries

david: our primary audience is the folks who lack a registry process at w3c

fantasai: sure. we're looking for feedback

tantek: the survey is about forking or creating rather than reusing registries
… which is harmful

david: can we improve the first question?
… I'll rephrase the third question

fantasai: we need the feedback asap

<tantek> Does your group need to define a registry or preferably re-use an existing registry?

<tantek> ^ this is the kind of wording change we need

<fantasai> This isn't about using registries, it's about maintaining them.

david: ok, I want to comments before end of this week and I need permission to send this out

<fantasai> You can reference any registry you want

<fantasai> nothing about what we're doing is changing that

<tantek> it doesn't read that way

<fantasai> "Does your Working Group use a registry of some kind?"

<tantek> it fails the clear case of what happened in HTML

david: I'll work with plh to setup the survey based on comments this week

<tantek> the WG did not maintain the registry, merely used it by reference

<fantasai> tantek: it can continue to do so

<fantasai> tantek: it doesn't need to be a W3C Registry for a W3C REC to reference it

<weiler> do your WG's specs create or use registries?

<tantek> biasing towards moving the locus of control (maintenance) of a registry to a WG may be harmful

<fantasai> tantek: Referencing registries is a solved problem and not what we're about here.

#435 - Tooling

Github: https://github.com/w3c/w3process/issues/435

[out of time. to be continued]

Next meeting

David: 20th, 7am PT

tantek: ical for this meeting?

david: not yet

jeff: we're working on it actively


Summary of resolutions

  1. : proposal for W3C NOTE SHOULD NOT specify implementable tech, transition request MUST include rationale for not being on REC track
  2. Go with Memorandum in the PR for now, bikeshed the name later
Minutes manually created (not a transcript), formatted by scribe.perl version 127 (Wed Dec 30 17:39:58 2020 UTC).