Unresolved issues from CCG did-method-registry repo

[kimdhamilton]

The CCG DID Method Registry had 4 unresolved issues at time of transfer. They're in the attached spreadsheet.

2020-08-11-11-39-57-open-issues.xlsx

[OR13]

I suggest we close, and open new issues targeted at specific changes that may be requested.

[iherman]

The issue was discussed in a meeting on 2021-07-27

• no resolutions were taken

View the transcript

3.17. Unresolved issues from CCG did-method-registry repo (issue did-spec-registries#105)

See github issue did-spec-registries#105.

Orie Steele: We addressed most of this...

Brent Zundel: I'm going to leave 105 open for now...
… We can come back to it in the future... still work to be done there.
… We're going to close the meeting today... thanks to Ted for suggesting direction, we close a lot of issues today!
… What we went through today makes it clear that we still have work to do on registries before I'll be satisfied w/ them, look forward to more of this and more registries work.

Ted Thibodeau Jr.: closed 15, opened 2. good ratio

---

[clehner]

Copied from that xlsx file:

number	title	labels	state	assignees	milestone	comments	created_at	updated_at	closed_at	body
85	Define Contribution Requirements		open	msporny	null	1	2020-04-08T17:20:55Z	2020-04-09T13:11:01Z	null	Is "Privacy Considerations" required?_x000D__x000D_See: https://github.com/w3c-ccg/did-method-registry/pull/84_x000D__x000D_https://w3c.github.io/did-core/#privacy-considerations is non-normative.x000D
36	Add note to did method registry process about versioning method specs in a way that bubbles up to the registry		open		null	1	2019-04-11T21:11:49Z	2020-04-08T17:25:55Z	null	From CCG call on 2 April 2019: https://w3c-ccg.github.io/meetings/2019-04-02/#action-1_x000D__x000D_"add note to did method registry process about versioning method specs in a way that bubbles up to the registry"x000D__x000D_Relevant context:x000D_Kim: Uport, might be useful to mark this one as deprecated, since people may be working with it_x000D_Joe Andrieu: +1 To retaining uport as "deprecated"x000D_Jonathan Holt: Version control issues; machine readable_x000D_Joe Andrieu: +1 To add version to registry_x000D... For version control, implement a better syntax around changes and whether it has been deprecated_x000D_Manu Sporny: Specification should have version in the title_x000D... JSON-LD can support the other request, this is a respec feature_x000D... This requires work by the people writing the specifications, not everyone does that_x000D_Drummond Reed: +1 To adding that note to the registry instructions. ‚ú™
31	uPort is missing a method spec link		open	awoie	null	3	2019-03-15T17:42:40Z	2020-04-08T17:27:00Z	null	It was in the original commit, so I don't have an author
29	Dominode is missing a method spec link		open		null	1	2019-03-15T17:41:43Z	2019-03-26T19:51:53Z	null	The commit lists @ricjcosme as the author

[OR13]

This work has been done, unresolved issues were added and closed, this tracking issue is no longer needed.

[rxgrant]

The issues were:

• Define Contribution Requirements [done]
• Add note to did method registry process about versioning method specs in a way that bubbles up to the registry [requirement lost to the sands of time - seems unnecessary]
• uPort is missing a method spec link [done]
• Dominode is missing a method spec link [will be addressed in issue Explanation on the DID Methods in the registries' document #83]

Reason for closing: [as far as the WG can determine] "work was done"

(Dominode doesn't have a link, but that's tracked elsewhere.)

[msporny]

We have defined the contribution requirements, so that's done.

The second item is not how we do things in the registry, there is just a link to the latest spec.

uPort now has a link to a spec.

Dominode still doesn't have a link to the spec, but will be resolved by either labeling via "no link to spec", or removing it from the registry.

[iherman]

The issue was discussed in a meeting on 2021-10-19

• no resolutions were taken

View the transcript

5.3. Unresolved issues from CCG did-method-registry repo (issue did-spec-registries#105)

See github issue did-spec-registries#105.

Orie Steele: I maintain, as i did at the time, that this issue is broad and should be closed and replaced with smaller, PR-able issues

Manu Sporny: there were method spec links missing at the time

Daniel Burnett: but newer issues track that, we don't need to keep this one open to track it

Orie Steele: +1

Manu Sporny: i'm not sure that's true for every issue covered here
… in particular the "did method spec" versioning (i agree that the missing did method spec links will be handled by ryan's PR or follow-up PRs)
… so yes, i think we can close

Orie Steele: if you'd leave a comment, that would help. otherwise, no objections?

Ryan Grant: I just posted a comment

Daniel Burnett: the most important reason for all this commenting-before-closing is to make explicit that issues are never closed without resolving

Drummond Reed: +1 to closing

Daniel Burnett: and if someone can link to the part where the missing-spec-links are part of ryan's PR, that would help too