search

w3c-ccg / community

COMMUNITY: W3C Credentials Community Group Community Repo
https://w3c-ccg.github.io/community
Other
41 stars 6 forks source link

Additional criteria for work items #214

Closed mprorock closed 3 years ago

mprorock commented 3 years ago

Do we as a community want to apply additional standards or scoping criteria around CCG work items? e.g. example specifically in mind is a proposed scope limitation for new DID methods that the CCG would adopt if there is not a specific ledger requirement in place for the new DID method.

Couple of key notes:

  1. This kind of criteria would likely have to be applied to other existing items which could be highly problematic
  2. The CCG could grow rapidly as a shared IPR space for development of DID methods - this could be good
  3. In general the principle for work items is (and personally I think should continue to be) that if multiple parties want to work on something in common, let's approve it and get folks moving
OR13 commented 3 years ago

The CCG should not exclude any work item from acceptance that has multiple independent companies interested in participating... specifically, concepts such as blockchains, ledgers, hash tables, programming languages, data format languages, etc...

Blocking the work of community members who want to work with a specific technology such as JSON-LD or Bitcoin, is not appropriate.

The scope should be limited to things that can be done in a git repository.

mprorock commented 3 years ago

The scope should be limited to things that can be done in a git repository.

What about items like reference implementations of software?

OR13 commented 3 years ago

@mprorock I hear that git works just as well for specs, as it does for code.

mprorock commented 3 years ago

@mprorock I hear that git works just as well for specs, as it does for code.

;) totally get it - i was just taking you literally

mprorock commented 3 years ago

Key note around not adding additional criteria and continuing around the existing inclusive path, is that we are encouraging active interoperability in an IPR space

mprorock commented 3 years ago

tagging @rxgrant as I know you have additional work potentially inbound around did:btcr to foster interoperability and continued adoption of DIDs through use of bitcoin as an anchor point which would be highly beneficial to the community and I could see where additional scope restrictions could be problematic for that

bumblefudge commented 3 years ago

TBH even though I work for a very web3-focused company, I am sympathetic to the ecosystems around blockchains, DLTs, and DAGs being somewhat collusive and partisan in structure; I always use the analogy to commercial clouds because they are essentially just ways of pooling infrastructural resources and security resources, for better and for worse. But we need a clearer definition of what business relationship or types of alignment we don't want to see between all sponsors of a work item or all participants in a work item, because no technological criterion is going to map neatly to that collusion threshold. (I'm not sure "interoperability" gets us out of this quagmire either, since it's also a technological description for a business problem-- translation engines and AI always seem to arise when business incentives drive interop!) To be even blunter, I think the problem isn't anything about a given DID method's choice of VDR, it's the business incentives behind the work item being hard to align with CCG's that we're trying to proscribe, right?

jandrieu commented 3 years ago

Hey. I just saw this thread.

Unfortunately, this would require a change to the charter, which I doubt would pass.

From the charter:

Work Items In general, all documents related to credentialing are welcome. If there are individuals who will commit to being editors for a document, the group should agree to accept it as a work item even if it conflicts with previous work adopted by the community.

As a past co-chair, I'm dismayed @mprorock would even suggest this direction. @kimdhamilton @ChristopherA and I worked hard to create an inclusive community, where any on topic work that had the support of multiple parties would be approved.

This shift to acting as a gatekeeper is an unfortunate shift in direction from new leadership. By starting the conversation with the explicitly stated suggestion that perhaps it is appropriate to limit new DID Methods, it shows a fundamental break with the culture I believe brought most of us together.

There's a reason the first word in DID is decentralized. This kind of gatekeeping is anathema to many of us are here.

If you really want to pursue this strategy, I recommend framing a charter amendment ASAP and start working it through adoption.

I think it would serve the community better if we simply closed it.

mprorock commented 3 years ago

@jandrieu well stated. I think the key thing is to not adopt any additional criteria beyond those already in the charter. As you have noted, this fosters inclusiveness, along with many other benefits.

I am keeping this issue open for a bit at least to ensure we document WHY we are not not adding additional scope requirements, and that we retain those reasons in writing so that the next time this comes up (which I am sure it will as we grow) whoever is in the community including whatever leadership is present can point directly to this thread and say: "see, this is why we started, why we continued to grow, and why we aren't going to close paths off now".