w3c / process

W3C Process Document
https://www.w3.org/policies/process/drafts/
196 stars 130 forks source link

Mandate default custodianship for Registries if the specified custodian is no longer available #699

Closed nigelmegitt closed 1 year ago

nigelmegitt commented 1 year ago

Arising from the TTWG's call on 2023-01-19 and discussion ongoing to create boilerplate for TTWG registries at w3c/ttwg#241, where the idea is to specify that TTWG is the custodian of its own registries, but if TTWG ceases to operate then custodianship would fall back to the Team:

The question arose: shouldn't the Process define a fallback custodian for all W3C Registries if the originally specified custodian is unable to operate? More broadly, if the Registry Definition's process for requesting changes to the Registry is defunct (perhaps the email address has been frozen, etc) what is the default fallback?

It seems unhelpful or impractical for a WG to have to define a process for what happens when the WG no longer exists.

frivoal commented 1 year ago

Having the Team as a fall back seems useful, though we probably want to let groups explicitly opt out of that if for some reason their registry has update criteria that wouldn't be appropriate to hand off to the Team.

Maybe we also want to give the Team the ability, when it inherits custody of something, to assign it to some other body, possibly with an AC review to confirm.

TallTed commented 1 year ago

give the Team the ability, when it inherits custody of something, to assign it to some other body

Exactly what occurred to me on reading the OP.

registry has update criteria that wouldn't be appropriate to hand off to the Team

I suggest that any group realizing such should nominate a few (3? 5? 10?) groups that are expected to endure sufficiently, which groups should then resolve their intent to serve as a potential fall back, among which I would think the Team could choose when needed ... or the nominating group could order their list by preference, which guidance I would think could be followed as with any creator's wishes about their output.

dwsinger commented 1 year ago

whoops, good catch.

(A few years back I had a need to contact all the Registration Authorities approved by ISO, and was unhappy to find how many dead pointers there were. We can and should do better.)

I think the ideal route is something like:

we need to work out whether such re-assignment should cause a full-track revision of the Rec-track defining document

frivoal commented 1 year ago

I suspect it would be OK for a specific registry to opt out of that fallback mechanism if it would be inappropriate for their use case, but as a default if nothing is specified, that does seem reasonable.

css-meeting-bot commented 1 year ago

The Revising W3C Process CG just discussed Default custodianship for Registries if custodian no longer available, and agreed to the following:

The full IRC log of that discussion <fantasai> Subtopic: Default custodianship for Registries if custodian no longer available
<fantasai> github: https://github.com/w3c/w3process/issues/699
<fantasai> PR: https://github.com/w3c/w3process/pull/790
<fantasai> Changes: https://github.com/w3c/w3process/pull/790/files
<fantasai> florian: We have notion of a registry custodian
<TallTed> q+
<fantasai> ... when a WG sets up a registry, they describe the tables etc. but also who has the ability to update it
<fantasai> ... can be WG itself, coudl be a CG, could be the Team
<fantasai> ... But what happens if that body ceases to exist?
<fantasai> ... if you still have a WG around, you can fix it
<fantasai> ... but if no WG?
<fantasai> ... This empowers the Team to propose to the AC a new custodian
<fantasai> ... otherwise have to spin up a new WG to make the revision
<fantasai> TallTed: As I understand, there would only be one custodian, so should be "the custodian" vs "a custodian"
<florian> q+
<fantasai> florian: Interesting nuance is that we anticipate that although it might be uncommon, the rules allow a registry to contain multiple tables, and possible for each table could have a different custodian
<fantasai> ... allowed by the rules, though unlikely
<fantasai> TallTed: My concern is that it's the last custodian of a given segment
<fantasai> florian: When we were preparing this, the way fantasai said to think of it was that if multiple groups are empowered to update a table, then collectively those groups are the custodian
<fantasai> florian: I suspect in practice it won't make a difference
<fantasai> [discussion of this grammar point]
<florian> fantasai: we allowed each table to have a different custodian
<florian> fantasai: but for each table, the custodian could be a person, a group, a set of groups…
<fantasai> TallTed: I'd like to take a stab at rephrasing, so let's not merge today
<florian> fantasai: so a registry could have multiple tables, each with a different custodian, and some of those custodians might be sets of multiple groups
<fantasai> florian: that's fair. I think your concern is, for a particular table we allow group A or group B, then no need to replace one that's gone since still one active custodian
<fantasai> fantasai: if we can do that without making the phrasing overcomplicated...
<fantasai> florian: alternatively, remove notion of custodian per table
<fantasai> TallTed: I think the more complicated handling is probably going to happen, given where some groups are going
<fantasai> fantasai: do we want to resolve to merge with editorial tweaks delegated to editors / Ted?
<fantasai> TallTed, florian: seems fine
<fantasai> PROPOSED: Merge PR 790, allow editors to make editorial tweaks
<fantasai> RESOLVED: Merge PR 790, allow editors to make editorial tweaks