Should registry track how to contact DID method authors?

[dhh1128]

Right now, our table of information about registered DID methods includes a link to each spec, and a human-friendly name for its authors. As part of the work on a rubric for DID methods, I'd like to contact the authors of each method to ask them to point out some noteworthy properties of their method. Unfortunately, we don't have contact information (except for a moderately complete list of github handles) for the authors of most of the methods.

I suggest we rename the column that's currently entitled "Authors", changing it to "Author Links", to encourage authors to provide some form of contact info (hyperlink to their LinkedIn profile, an email address, etc). I would be happy to submit a PR to that effect if people agree that this is not too heavy-handed/centralized.

In the meantime, I'm tagging the github handles of as many DID method authors as I can find, to make a request: Would you please help the DID rubric effort in two ways? 1) read this letter that we're trying to send to you: https://bit.ly/did-rubric-letter; and 2) share some better contact information with me (feel free to email me directly at the email address that's included at the bottom of that letter)?

@dingpl716 @kimdhamilton @danpape @jcnelson @peacekeeper @frozeman @jonnycrunch @SHBailey @mikelodder7 @PeterTheOne @awoie @dlongley @egidiocasati @kunxian-xia @lucastetreault @jjamieson1 @jungsoo827 @DaegiMin @sondreb @infowallet @mrinalwadhwa @VictorNS69 @esanchma @kremalicious @thehenrytsai @VolkerScheiwe @Exulansis @chunningham @bcessa @cbruguera @jsong1230 @chainyard-tys @dhuseby @ender503 @sunilp @mym-xjl @OneITFarm-WellLink @andreataglia @zo-el @dmitrizagidulin @rhiaro @raullenchai @dsemenovsky @JonesWilde @vegetar808 @vpayment @infitude @OmairLiaquatAli @bocheng0000 @maudnals @gjgd @OR13 @teleinfo-bif @shuizhongmose @anzhy-chernyavski @troyronda @fqutishat @wuyahuang @gatacaid @nklomp @stbeyer @paulmadsenhed @lovesh @glcohen @OntologyTech @mooorex @caict-develop-zhangbo @atz3n @qiluge @liyuan @jpbu @MajdT51 @jvlkl @msporny @julio-cabdu @mplattr3 @pranavkirtani88 @SophieDM @youngjoon-lee @ilovelili

CC @jandrieu

[peacekeeper]

+1, I have also been part of conversations where we thought it would be nice to be able to contact DID method spec authors. For example, once the DID Core spec is finished, we should contact them all to see if they want to update their method status from "PROVISIONAL" to something else.

I think the simplest approach would be to just add links to the existing author names? E.g. like this? #176.

[OR13]

Yes, I would welcome a PR with "SHOULD" language around an email for point of contact.

[talltree]

@OR13 Given that we want to ensure accountability for any registry entry, is there any reason it shouldn't be a "MUST", as in, if you wish to propose a DID method specification, you must provide at least one author contact?

[OR13]

@talltree I would be fine with a MUST, I am just not sure regarding PII and W3C registries.

[dhh1128]

Regarding the "MUST" idea: I'm not opposed, but I was a bit shy about it because it starts to smack of the sort of registration that domain names require; I worried that some might find it too heavy-handed and out of sync with the decentralized spirit we wanted to preserve. I think that may be Orie's hesitation as well. But I'll go with whatever consensus says is best.

[dhh1128]

PR opened: #178

[dhh1128]

Since a PR has been merged to answer the question posed by this ticket, perhaps we could close it? Do I do that unilaterally, or do maintainers of the repo close it?

[OR13]

@dhh1128 thanks for the ping, closing the issue.

[jandrieu]

Resurrecting to address WG interest in adding contact information as a registration requirement.

Proposed next step: a PR that changes the first entry in Section3 "Any addition to the DID Core Registries MUST specify a human readable description of the addition." to add and contact information for the author of that description.

One question: does this apply to ALL properties? Or just DID Methods?

[brentzundel]

Re-opening

[TallTed]

@dhh1128 @jandrieu --

The original post in this issue appears to have been meant to alert all the listed Github handles -- but a number of those handles are not live-clickable, and I'm guessing they were not alerted, presumably because Github puts some limit on how many handles can be tagged in a single post.

I'm thinking it may make sense to add a comment and re-tag those which are not clickable in the initial post, in hopes that some more semi-nonymous contacts will reveal better contact info.

[jandrieu]

So, we already reached out to those folks one a one-to-one basis (if you check the issue history there are a dozen or more issues we created to try to reach those folks).

We managed to get quite a few that replied directly. Some even updated their entry (or their method spec) to add contact details.

What we failed to do was get the WG's blessing to add contact info as a requirement for registering a method. Seemed like there was some support for that on today's call.

The biggest gap is whether we require contact info for all additions (such as properties) or for just DID Methods. Seems to me that contact info for everything is the right way to run a registry; we just haven't matured the process enough yet for that to be the explicit rule.

[TallTed]

@jandrieu -- OK, thanks. The MANY connected issues suggested something like that was going on, but only by their existence. I didn't see any reference back to the opening comment here, so those other issues might have been targeting different entities.

[jandrieu]

Will develop a PR to make sure contact info for DID Method authors, email minimum and any other mechanism if desired. If contact information is not provided, it will be subject to removal.

[jandrieu]

A label will be added for those without contact details "Missing Contact Info"

[iherman]

This issue was discussed in a meeting.

• No actions or resolutions

View the transcript

6.1. Should registry track how to contact DID method authors? (issue did-spec-registries#174)
See github issue did-spec-registries#174.
Manu Sporny: let me try and suggest something. We have a number of issues that are “needs contact info”
… Joe, I’m not sure how you feel about that. Can we close these?
Joe Andrieu: for the outstanding issues, I’m happy to close them. I would still like to get the requirement that new additions have contact information
Manu Sporny: #174
Joe Andrieu: that should be part of registry process?
Manu Sporny: let’s get that in there. We need a PR. Joe can you take that?
Joe Andrieu: yes, I can do that.
… One question, I had initially stuck it in mentally, but that would mean for all properties, not just DID Methods. Do we want that?
Manu Sporny: let’s keep focused on just DId Methods, then we can expand it later if needed.
… this would say “We need contact information for DID MEthod authors, at least an email.”
Ivan Herman: there are quite a few of these without contact info. Does that mean we will remove those methods that haven’t responded?
Manu Sporny: my suggestion, we have contact info, we have github handles, but we should say we need email addresses moving forward.
Ivan Herman: I don’t have an opinion, but it should be clear.
Joe Andrieu: in my experience, a github handle is a poor way to communicate. There isn’t even a claim of authorship
Manu Sporny: we had also discussed marking them as “Unresponsive DID Method Author”
Joe Andrieu: some of these methods aren’t compliant. Is there some process to remove those methods that aren’t compliant.
… Daniel and I reached out to let them know about the Rubric. We didn’t reach out about non-compliance.
Manu Sporny: we are seeing that there is a need to deprecate things, like publicKey,
… maybe we need labels for did methods as well. This is a provisional did method that isn’t compliant with v1.0, and the author is unresponsive.
… we can add labels that give people an idea as to the current state of things.
Drummond Reed: we had talked about actually separating the DID Methods, particularly due to the large number of them. A single step for DID Methods to self-attest compliance to the official spec.
manu irc: +1 to separate tables for DID Methods that are “in a bad state”
… that would be a filtering process that results in the tags Manu mentioned. I suggest separate tables. If we have methods that never respond and don’t react. They would be in a separate table to indicate they never did what they needed to show they were in compliance.
Justin Richer: -1 to a second table but a status or tag is less offensive
Ivan Herman: just noting there is already a mechanism in the table. did:git is withdrawn, it is crossed out
… we should use that mechanism
… what drummond said is doable as well, but that is a lot of work to separate them
Markus Sabadello: I like the idea of labels. We also discussed a status field. We could also indicate whether a test suite has been submitted.
Drummond Reed: +1 to indicating if a test suite has been submitted.
Charles Lehner: maybe also a flag for whether it is mentioned in the DID Rubric?
Markus Sabadello: wanted to mention issue 83 is related to this. Registration process of methods vs process for other entries could be addressed by this discussion
Manu Sporny: We could always delete (offensive language) because it violates the registration rules.
Joe Andrieu: I agree with the general sense. Deleting could leave holes, so keeping things around and adding labels makes sense. But we also need the power to delete things that are inappropriate. So the editors should have that power.
Drummond Reed: +1 to giving the DID Spec Registries editors the choice for how to maintain the registry (in concert with the guidelines)
Manu Sporny: nest steps. Sounds like for 174 we’re just going to have a label that says: “no contact information” or something like that. We need to say that an email address is necessary. We add that label to methods that don’t have that.
Drummond Reed: +1 to a list of labels
Manu Sporny: more generally we need to come up with a list of labels that we believe we will be applying: deprecated, v1.0 compliant, etc.
Daniel Burnett: +1 to giving editors choice here, with the reminder that “we prioritize end users over implementers, and implementers over spec writers”

[OR13]

@jandrieu See #329

[OR13]

The process requirements were updated, this issue should be closed.