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.

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

A non-exhaustive set of possible input documents for registries #100

Closed
wants to merge 11 commits into from

Conversation

brentzundel
Copy link
Member

@brentzundel brentzundel commented Mar 8, 2022

This PR builds on #98 and #99.

It adds a paragraph for a non-exhaustive list of possible input documents and uses the links that were in the table in #85 to populate the list.


Preview | Diff

msporny and others added 11 commits March 2, 2022 11:51
Co-authored-by: Ted Thibodeau Jr <tthibodeau@openlinksw.com>
Co-authored-by: Jeffrey Yasskin <jyasskin@google.com>
Co-authored-by: Brent Zundel <brent.zundel@gmail.com>
Signed-off-by: Brent Zundel <brent.zundel@gmail.com>
Signed-off-by: Brent Zundel <brent.zundel@gmail.com>
Signed-off-by: Brent Zundel <brent.zundel@gmail.com>
… here

Signed-off-by: Brent Zundel <brent.zundel@gmail.com>
@brentzundel brentzundel changed the title Add non-exhaustive set of possible input documents A non-exhaustive set of possible input documents for registries Mar 8, 2022
Copy link

@selfissued selfissued left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Please close this PR without merging it, as #98 already does the job well that needs to be done. Saying that creation of registries is in scope is all we need to do in the charter.

@iherman
Copy link
Member

iherman commented Mar 9, 2022

Please close this PR without merging it, as #98 already does the job well that needs to be done. Saying that creation of registries is in scope is all we need to do in the charter.

We had a long discussion on previous entries where lots of details, references to all kinds of documents, etc, have been listed to avoid unnecessary in-scope/out-of-scope discussions creeping into the WG's work. I think this proposal (which does not contradict the short paragraph proposals in #98 or, rather, #101) just sets the right balance.

@iherman
Copy link
Member

iherman commented Mar 17, 2022

The issue was discussed in a meeting on 2022-03-16

  • no resolutions were taken
View the transcript

3.2. A non-exhaustive set of possible input documents for registries (pr vc-wg-charter#100)

See github pull request vc-wg-charter#100.

Brent Zundel: PR 100 adds a possible set of input documents.

Michael Jones: Having a list of input documents would take away from having a nice clear clause.

Brent Zundel: I agree, but the same decision would be made here.

Orie Steele: I just have a question regarding why listing input documents is so contentious.
… It seems we can all do registries or not do them. But it does seem like providing links to input documents seems better than not providing those.
… Can we have a brief conversation around why we're blocking input documents when we might do something?.

Michael Jones: It's a fair question. It's my sense, looking at some of the input documents. The registries that are proposed are not structured the way I would structure it. Extensions are overly general. Extensions for VCs -- well there will be a lot of different possible registries. It would be better to have a fresh perspective. As I said in PR 99, we should organically create these.

Markus Sabadello: I feel like we may or may not want to work on certain things. I don't see any downsides for listing existing documents and it's helpful to point to the existence of those. It doesn't mean that they have to be used, but I agree with Orie that it's better to mention them than to leave them out.

Ted Thibodeau Jr.: In my world, input documents are things that we've learned from. Either we developed them and they are bad or they are good or whatever. It seems to me it's good to list input documents even if the plan is to make them worthless wrt what we develop.

Michael Prorock: +1 Ted.

Markus Sabadello: +1 to Ted.

Ted Thibodeau Jr.: If we can't learn from past experience, what can we learn from?.

Dave Longley: +1 to Ted.

Orie Steele: I think those input documents have evolved organically from those who have implemented version 1. Fully disclosure, I'm an author of a lot of input document / CCG draft things in this space. I can tell you w/ 100% certainty is that I've learned a lot here and many of those shouldn't have happened.
… To Ted's point -- acknowledging that we've learned from these things is important. Leaving them out is to bury our heads in the sand. We've learned a lot and a lot has been painful. Sometimes it's good to include an input document and then say that it represents the worst ideas we've had.
… We're acknowledging that and we want to move on from it. I also agree with Mike in that we don't want to pour concrete around them. That's going to happen no matter what -- it's easier to talk about things if they are linked.

Dave Longley: +1 to Orie.

Ted Thibodeau Jr.: I think it's also OK to say "this is an example of something we are adamantly not going to make this time, in xyz ways".

Michael Prorock: +1 Orie.

Orie Steele: I would much rather acknowledge that the documents take us in a way we don't want to go as needed.

Brent Zundel: +1 Orie.

Michael Jones: To Ted's point and Orie's about learning from past work. I support that. I view that as orthogonal to listing them in the charter. There are a number of individuals like Orie, Ted, and Markus and others on this call that are familiar with them. That knowledge will not be lost and brought to the WG.
… Either positively or not. I don't think that having a laundry list of possible input documents really moves us forward. Once we have a working group rechartered, I'd be happy to have people submit pointers to that in meeting minutes or notes or drafts.
… A charter is a special thing, it does not have to have lists and lists of things. We're already pretty bloated, let's not do that anymore, please.

Brent Zundel: What if it was a list of links to follow and it wouldn't take up as much space.

Michael Jones: It's not the formatting that bothers me -- it's the presumption that these are the registries we want to create.
… Let the registries evolve organically from the normative work we do together.

Orie Steele: the opposite is also true, the presumption that these ARE NOT the registries we want to create.
these registries have ALREADY evolved organically.

Ted Thibodeau Jr.: The question comes to mind --- who is the charter for? It's for the Advisory Committee. It's not to benefit us to tell us what documents we've already worked on. It's to help other people benefit from work that's already been done. It's for them.

Orie Steele: +1 Ted.

Ted Thibodeau Jr.: It's for people reading the charter to say "I don't know, what's this based on" so they can go look at the input documents.
… And know what it's based on.

David Chadwick: A number of people said this list contains both good and value examples. That means there's a value judgment. Anyone reading the list will not know what's good or bad. If we have the list and we put the value judgments, then people will get bogged down in the mud over those judgments.

Michael Jones: To the point about the Advisory Committee -- I can't imagine that the current wording that says that registries are in scope would be confusing.
… Having recently setup the new W3C registries policy they would be happy to seeing that. Listing things could be breaking into jail, generating questions that otherwise wouldn't occur.

Orie Steele: agree regarding the "breaking into jail" bit.

@brentzundel
Copy link
Member Author

The group has failed to come to consensus on this PR, closing

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants