[go: up one dir, main page]
Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

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

Closed
nigelmegitt opened this issue Jan 23, 2023 · 5 comments
Closed

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

nigelmegitt opened this issue Jan 23, 2023 · 5 comments
Labels
Closed: Accepted The issue has been addressed, though not necessarily based on the initial suggestion
Milestone
Process 2024/2025

Comments

@nigelmegitt
Copy link
Contributor

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.
@nigelmegitt nigelmegitt mentioned this issue Jan 23, 2023
Closed
@frivoal
Copy link
Collaborator
frivoal commented Jan 25, 2023

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
Copy link
Member
TallTed commented Jan 25, 2023

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
Copy link
Contributor

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

@w3c w3c deleted a comment Feb 25, 2023
@frivoal
Copy link
Collaborator
frivoal commented Feb 25, 2023

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.

@nigelmegitt nigelmegitt mentioned this issue Feb 27, 2023
Open
@frivoal frivoal added this to the Deferred milestone Mar 2, 2023
frivoal added a commit to frivoal/w3process that referenced this issue Oct 11, 2023
@frivoal
Enable Team to replace defunct registry custodians when no-one else can
0ee0b6e 
See issue w3c#699
@frivoal frivoal mentioned this issue Oct 11, 2023
Merged
@css-meeting-bot
Copy link
Member

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 <fantasai> Subtopic: Default custodianship for Registries if custodian no longer available
<fantasai> github: https://github.com//issues/699
<fantasai> PR: https://github.com//pull/790
<fantasai> Changes: https://github.com//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

@plehegar plehegar modified the milestones: Deferred, P2024 Nov 7, 2023
frivoal added a commit that referenced this issue Nov 8, 2023
@frivoal @TallTed
Enable Team to replace defunct registry custodians when no-one else c…
f6c0670 
…an (#790)

See issue #699

Co-authored-by: Ted Thibodeau Jr <tthibodeau@openlinksw.com>
@frivoal frivoal added the Closed: Accepted The issue has been addressed, though not necessarily based on the initial suggestion label Nov 8, 2023
@frivoal frivoal closed this as completed Nov 8, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
Closed: Accepted The issue has been addressed, though not necessarily based on the initial suggestion
Projects
None yet
Milestone
Process 2024/2025
Development

No branches or pull requests
6 participants
@frivoal @plehegar @TallTed @nigelmegitt @dwsinger @css-meeting-bot