Re: VC Specifications Directory goes live

Inline:

On Wed, Mar 22, 2023 at 9:25 AM David Chadwick <d.w.chadwick@truetrust.co.uk>
wrote:

> Hi Manu
> On 22/03/2023 13:44, Manu Sporny wrote:
>
> On Wed, Mar 22, 2023 at 9:17 AM David Chadwick<d.w.chadwick@truetrust.co.uk> <d.w.chadwick@truetrust.co.uk> wrote:
>
> I have just encountered another issue with the directory entry. What is the semantic of "maintainer"? Is this the maintainer of the directory entry, or the maintainer of the specification that is pointed to by the directory entry? These could be different people as they are clearly different roles. Currently I have assumed it is the maintainer(s) of the directory entry.
>
> Yes, it's supposed to be the maintainer of both, but as you note,
> that's not always the case.
>
> The question here, again, is one of simplicity and determinism; we
> want a single point of contact.
>
> If a maintainer of a VC specification can't bring themselves to also
> add an entry to the VC Specs Dir, then that is an indicator of a
> future potential problem. To put it another way, we don't want an
> unaffiliated individual adding entries for VC Specifications where
> they do not have the right to speak with authority about the
> specification and its registration.
>
> I understand that. But this is not the issue I have raised. Furthermore
> what automated checks do you have for this? None as I can see since the
> email address for the maintainer of entries you have inserted is
> public-vc-wg@w3.org, but this does not match the email of any of the
> editors of the underlying specification. So you must be using human
> checking for affiliation confirmation. In which case the human checkers can
> validate the affiliation of the inserter of the directory entry.
>

The repo maintainers are not going to have time to do anything but see that
the checks pass, and that there are no collisions or offensive content.
Lets not over engineer this, anyone can file an issue or pull request to
change entries you believe are unhelpful.


> It's not that we can't complicate the rules of the VC Specs Directory
> to address these cases... it's the cognitive burden we're placing on
> the maintainers of the directory when we make the registration
> criteria require more thought than necessary.
>
> To go at it from yet another direction: "Do we think that requiring VC
> Specification Directory entry authors to also be editors/authors of
> the specification they're adding to be an undue burden?" At present,
> I'm leaning towards: "No, it's not an undue burden... we want someone
> that can speak with authority about the specification being
> registered."
>
> I think your response is too simplistic (or maybe arrogant?) and does not
> take into account the real life work loads and responsibilities of people,
> plus the synergies that arise from different experts working together.
> Different people have different expertises, different workloads and
> different responsibilities. Combining expertises can lead to synergies,
> efficiencies and more work throughput overall. For the two directory
> entries I have just proposed, I am the VC expert and so have created the
> directory entries for Evidence and ToU, whereas my colleagues are experts
> in OIDF IDA and TRAIN/ETSI trust lists and have been responsible for the
> underlying technologies that we have incorporated into VCs (to the huge
> benefit of VC eco-systems). So its not a question of the technology
> providers not being competent enough to create the directory entries, but
> rather is one of "they are already working flat out and appreciate the help
> from someone who is already familiar with the VC WG and its processes and
> procedures"
>

I am not sure what you mean... obviously folks are not required to register
things in the directory.
If their work is not mature enough, or if they feel being contacted
regarding their work is too high a burden, they should consider registering
a community to support any inbound (like a community list)... Or they can
simply not register the work, because they do not wish for engagement on it
that would come from a registration.


> But this raises a larger issue. Where are the definitions of the schema fields to be found? Perhaps they should be added to the Read.me file?
>
> It's currently documented here (see the description fields):
> https://github.com/w3c/vc-specs-dir/blob/main/tooling/specification-entry.yml
>
> That said, people are not going to find it easily there, and the
> descriptions are not great. Please raise an issue to improve upon the
> current state (document these fields in the README.md, the pull
> request template, and improve the descriptions in the
> specification-entry.yml file.
>
> Thanks. I have raised this issue
>

Thanks, I suggest this be covered in the respec document, every field in
the schema should have a definition and help text in respec.

I filed: https://github.com/w3c/vc-specs-dir/issues/12

> Kind regards
>
> David
>
> -- manu
>
>
>

-- 
*ORIE STEELE*
Chief Technical Officer
www.transmute.industries

<https://www.transmute.industries>