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

[nigelmegitt]

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]

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]

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]

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:

• if the operator of a Registration Authority wishes to retire, they tell us, and we manage the transition in conversation; if the authoring WG still exists, it goes back to them to revise the Rec-track document that defines the authority
• if we close a WG and we know that they are the approval/operator, we ask them to work out what to do before closure
• if nonetheless we end up with a 'dead pointer', yes, the team should have the authority both to become the operator and also the authority to find and assign a better if they wish (and if you don't want the team to do that, well, see steps 1 and 2 and it won't happen)

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

[frivoal]

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]

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

• RESOLVED: Merge PR 790, allow editors to make editorial tweaks

The full IRC log of that discussion

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