What is the Process

The W3C Process Document describes the organizational structure of the W3C and processes, responsibilities and functions that enable W3C to accomplish its mission.

• Revised in the Process Community Group
• Open to anyone, includes the AB
• Final decision by AC Review, CG has no authority

Selected Topics from the Process 2021 Cycle

• Registries
• Tooling

What is a Registry

A registry documents a data set consisting of one or more associated registry tables, each table representing an updatable collection of logically independent, consistently-structured registry entries.

What is it for?

• collision avoidance
• duplication avoidance
• ease of submission
• centralization of information / ease of discovery
• consensus

The Problem

W3C has no standard way to maintain registries

People have been using various ad-hoc and inconsistent work-arounds

Registry Proposal

Makes registries ‘first class’ deliverables of the W3C, on /TR, referenced by W3C URLs, with a process for defining, publishing, and maintaining one in the Process document.

Anatomy

• One or more Registry Tables
• Registry Definitions, which define for each table:
  • the purpose & scope
  • the fields (name, type, constraints…)
  • what kind of changes to are allowed (addition, deletion, modification, deprecation…)
  • the process & criteria to register or modify entries
  • the custodian (not necessarily the Working Group)
• Must not contain normative requirements on implementations

Registry Process (base case)

• Put the Definitions in a section of a REC track document
• Put the Tables in the REC track document as well
  
• Take the Definitions to REC normally
  (consensus, wide review, WD→CR→PR→REC, AC Review…)
• Tables can be updated with no more process than required by the Definitions
  (no Director or AC Review, no Transition Call, can be fully automated if desired…)

• In line with current practices
• Stable rules approved by the AC let us grant official standing
• Full flexibility for updates / additions within those rules

Automation

Allows automated submission/publication if desired

Could be Pull-Request based, or anything convenient

Publication

Can be in the same REC as the referencing specification…
…or in a standalone REC containing only the Registry Definitions and Tables.

Tables can be inline in the REC as HTML content…
…or in an attached machine-readable file…
…or both.

Open Questions

• For registry-only documents: usual REC Track or simplified Registry Track?
  Do we need both CR and PR?
• Should we allow Definitions and Tables to be published separately?
  (i.e. not just separate files, but completely separate /TR publications)

Must be Together?

Pros:

Easy to keep everything in sync

All information is available without duplication nor external reference

One thing to reference

Data-only attachment possible anyway

Cons:

Rules for updating Definitions and Tables are different

Most readers of the Tables have no interest in maintenance rules

May be Separate?

Pros:

IETF+IANA do it, why not us?

Tables document can be shorter

Can set up a different back-end (proxy?) for Tables, to ease automation, with no risk to Definitions

Only allows separation, does not mandate it

Cons:

Partial duplication of Definitions needed for readability

Mutual cross-links needed between Tables and Definitions

Need to manage potential incompatibilities between updates

Separate track?
(For standalone registries only)

Do we need both CR and PR?

Upsides of having both:

CR signals “we think we’re done”, which some wait for before reviewing

Only one AC Review, at PR
(though multiple CRs less likely)

Upsides of merging:

No phase dedicated to gathering implementation feedback due to no implementation to wait for

No artificial delay due to minimum review periods stacking up

It’s your turn!

• Review the draft Process:
  • Version with Registry Track, no PR phase, Definition+Tables together
  • Version with REC Track only, Definition+Tables may be separate
  • Diff between the two
• Ask questions at the AC meeting
• Talk to your favorite AB member
• Participate in the Process CG

Historical Tooling

• Telephone conferences hosted by Zakim
• IRC and the IRC bots
• Email/Tracker/Bugzilla for issues and actions
• Email for asynchronous communication
• Wikis for exploring ideas
• CVS for source control

Badly outdated, partly retired

Current Situation

Each group picks their own tools

Upsides:

Better work flows

Better usability

Keeping up with community norms

Downsides:

Discoverability challenge

Need for accessibility / archival / persistence not always respected

Tooling Project

Ongoing discussion in the AB and Process CG:

• Need at least documentation of best practices and guidelines
• May also need some minimal enforceable rules?

Full details in the wiki