Markus Sabadello: I’m Markus of Danube Tech. I’ve worked on digital identity for a long time. I run the Thursday DID calls. We’re making progress on PRs. I made progress on implementing BTCR scheme support in Universal Resolver, which I created. ✪
Christopher Allen: There are currently weekly DiD calls on Thursdays. 2100-2130 UT. There is a meeting page where they keep track of their call. If you’re interested in helping with a wrap up report on DiDs that’s a good place to be. ✪
... Do you have any idea how long the DiD calls will continue?
Drummond Reed: I expect we'll need at least another month to get to the Community Final Draft of the DID spec and a first draft of the DID Resolution spec. ✪
Christopher Allen: There are a number of identity events that have lots of people this summer. If you know of any let us know and we can add it to the CCG community list of events. ✪
Kaliya Young: I will be attending ID4Africa in Johannesburg the third week fo June 18-20 hopefully next year this community can have a place on the agenda there. ✪
Kaliya Young: The last week of June is Identiverse in Washington DC and it would be great if we could have a DIF/CCG/SSI meetup of some kind at that event. ✪
Kim Hamilton Duffy: Actually, I’ll address this portion of action items. The latest draft of our work item process is greatly simplified. We can probably discuss it over the mailing list over the next week. There is one work item I’d like to talk to... A doc to spec conversion tool. There is a concern about the process being very technical. I think we have some proposals for how to push that off to the very end of the workflow. ✪
Christopher Allen: @Identitywoman Can you post an issue with details in https://github.com/w3c-ccg/community/issues so we can add it to announcements (unless you want to directly to a PR to the announcements repo) ✪
Kim Hamilton Duffy: Next one on the list is issue #75. This is the registries meta-process. A process that should apply to all registries. Manu wrote it over a year ago. ✪
... Next week we should be able to discuss that more.
... I’ll yield to Manu.
Manu Sporny: We should ping Sandro, and marcosc on the doc to spec tool (#76?). Bill Barnhill also offered to contribute on that tool. ✪
Christopher Allen: We’ve been through several versions of these. Basically we wanted to move up from a ‘anybody can propose anything’ from two years ago to allowing for a little bit of filtering. ✪
...we went a little too far with informal items and other things as tasks. In this version everything that is a work item is a publication of some kind.
...It is something to give to the WG, or something like a report on registry process.
...There are some requirements we have: ..see document.. Of important note, we must make sure that what we create is note portrayed as a standard. What we do is create WGs that can go through the process. We are very focused on Verifiable Credential architecture, incl. SSI,verification of proofs, etc.
...Anything that advances on of those issues is an acceptable work item. For a work item to move forward it needs at least one group member to volunteer as being lead editor and one member from a different company (excepts negotiable) to be a co-editor.
...URL above is the credentials official page on the W3C site. It has two major sections at the top: final reports and drafts. The final reports were part of the CCG before 2017, where we created a community report on verifiable claims, data model, and use cases. That is what the verifiable claims WG used as input.
...if you look at the drafts that we are currently working on you’ll see the Decentralized Identifiers work. One thing to note as a fundamental difference is that their is some extra rigor required for a final report.
...Basically there are things that can become final reports, an example being the DiD community speciification or other community specifications; community notes; and finally community commentary. The last is a note that is not intended to transition to a WG.
...I’d like to talk a bit about Community Drafts and then the stages of a final report.
...We are perpetual, but WGs are not (they have a 1-2 year time frame). AFAIK we are the first group to tackle registries and other things not intended to go final, but intended to be ongoing work. Also I want to make sure people are aware that the W3C has a process WG looking into how to handle these perpetual items.
...I want to make sure there are no questions or comments on these high level things before we go into more details on the process.
Manu Sporny: I noted two things: kimhd was accidentally dropped as one of the chairs. Second thing is that we may be missing some of the drafts in the list. I feel like we are working on more than just DiDs in the group. ✪
Kim Hamilton Duffy: I think it required existing chairs to add (we were able to do that with Joe) ✪
Christopher Allen: Yes. To be clear, I just added DIDs. As for the chair we’ll do something to fix that, may require a community resolution from the group which we can do at a later meeting. ✪
Manu Sporny: The final reports, especially with the DiDs spec...it was exceedingly difficult to get licensing committments for the specification. ✪
Christopher Allen: We’ll be talking about that. With a lower level IPR reviews in the early parts of the process. ✪
Heather Vescent: I think the usability of the document, it does a really good job for use cases, but not in how to use it. I’m wondering how to explain it in a more accessible way: welcoming for people to take ownership and for people to adopt the process. I think that adding a more human aspect narrative, with examples, will improve understanding of the process that we’re following and will encourage people to stand up and take ownership on things [CUT] ✪
Christopher Allen: I agree completely heathervescent. What we are currently calling community commentary, that process is very light. I definitely think we could have an example of how a community commentary became final. ✪
Heather Vescent: I don’t think this document should be considered complete until that is in there. ✪
Kim Hamilton Duffy: Regarding work items (see URL above). Back when we started looking at this process, it’s the last part of cleaning up the pipeline. We had a blanket thing on the W3C CCG landing page, saying we do iteration on everything. However, when I look at the page now that’s not clear. So we can post something every now and then to show activity. ✪
Manu Sporny: +1 To as much iteration as possible w/o developer tooling. ✪
Bill Barnhill: My question is a simple one... more process. I signed a CLA when I joined, is that the same thing as the licensing agreement that you're talking about? [scribe assist by Manu Sporny] ✪
...Also, regarding your question heathervescent. Making this more accessible, talking about github and respec. One of the things that could work is iterating in Google Docs. If people are are comfortable with using Google Docs, as the version history is not as easy to go over. more technical docs might be version controlled in Git, but for use cases and such Google Docs should work.
Billlb: Is the license agreement we discussed different from contributor agreement signed when I joined? ✪
Amy Guy: I agree with being inclusive and I don't think that requiring people to have a google account to particpate achieves that ✪
Drummond Reed: +1 To Manu's point about making it easier for newcomers ✪
Manu Sporny: It is the job of the people who wrote the process to determine where a newcomer is in the process, using perhaps heathervescent’s suggestion of pairing people up. It is not the responsibility of the newcomer. ✪
Kim Hamilton Duffy: I can't repeat this enough -- we will need community assistance to help make this happen ✪
Manu Sporny: +1 To "one person needs to know"... not "everyone needs to know or care" ✪
Christopher Allen: Right now the problem is our goal is for anyone to create a work item. If we say you don’t need to understand the process to create a work item, then we’ll be in trouble. ✪
Kaliya Young: Ok. I put all the events in the announcements section. ✪
...Right now the chairs cannot be the people responsible for that.
Kim Hamilton Duffy: Note that what we had been calling "informal work items" can be rough drafts. Meaning: just get started ✪
...Right now, what I’ve proposed is that rough drafts don’t need to be in a CCG repo, they can be in a Google Doc They can be in that rough draft stage, iterate, etc. At the point someone wants to make it a CCG thing then it goes into a CCG repo using #respec format. In the case of specifications we already know there are advantages to using Github issues for things.
...The release drafts and published drafts...When the editors have some level of completion then they number it with a dot version and release it outside the community for comment. We’d like to have more published drafts on there. Then people can continue to iterate, though a number of things need to become final at some point.
...That’s the categories, stages, of a final report. Could be we should separate community commentary into one less stage, and even community commentary has to become a final report.
Samantha Mathews Chase: It’s about putting something into a common tongue that is managed by the chairs and can be easily understood. ✪
Christopher Allen: There are tools that can help, but there is a limit on volunteer time. We need each group to have at least one person who understands the process reasonably well, we don’t need everyone to understand the whole process. Ok, I’d like to talk a little bit about how this process works. Item 3- work item drafts can take several yeas. ✪
...We have a special new work item template. If you go to issues on gituhub and say new work item it will ask you questions to help with a work item issue creation. The key is that the group has some kind of document (Markdown or Google docs), and the editor(s) should be listed. At the initial stage there doesn’t necessarily have to be two editors. The tool that kimhd wrote will label a work item appropriately. That’s the end of the proposal phase.
...The next phase is the Adoption Phase. Typically the proposal will be discussed for a week on the mailing list, and call. If there appears to be enough interest then the chairs will move the work item forward in the process. We have seen examples recently. If we can’t get a second editor to commit though then we have to filter due to the amount of work items we have currently.
...The recent issue, hopefully tha person will persist and get community adoption further in order to continue and perhaps get a second editor.
...The next phase is actually working on the drafts. As the editors are ready we might create a Google repo. We’ll work with the editors to work on those drafts through the process until there is some form of closure. This means we may pester you to see how things are going. We also have some phases to manage IPR risk. For example, to make sure are all controbutors have signed the IPR agreement.
Heather Vescent: Question on the work items: what's going on with the UNKNOWN work items? What happens when a project is abandoned? ✪
...Finally we have the finalization phase. Also, there is a TBW (To Be Worked on). If the Chairs note that an item seems to not have had progress then it is at the chairs discretion to notify the editors that more progress is needed, and if no further progress occurs, then the editors may be replaced or the work item put on hold until there is more interest to drive progress.
Kim Hamilton Duffy: They are not known :) we're trying to figure out ✪
...Again, the registry process is deferred for discussion for now.
Heather Vescent: Much appreciated to bring organization to the work item chaos. ✪
Kim Hamilton Duffy: If we are talking to you about informal work items you can just work from the rough draft section and get started. Some of this is to address what we see as possibly stuck because we don’t know what’s going on with some of the work items. ✪
ChristpherA: The pinging may start next week. This document is still in a rough draft stage, and will eventually be a community report. People can work on the rough drafts as long as they want before they make it an official CCG proposal. We do still have this requirement that editors must ensure that substantial requirements are made by members. This is why actual changes have to be accepted by the editors. The goal is to transition them to become a respec ✪
Document after becoming a rough draft. Note: MIRA was in this form originally. ✪
...We’re going to make it easier for people to go from a rough draft in Google Docs or other form to a respect document. We don’t want to use the valuable time of the weekly call for rough drafts. We at least want to get people to the CCG internal release draft stage. A Github tagged release number is an important marker for us. The version must be less than 1.0.
ChistopherA: When editors want we can make it a public released draft. The editors trigger this, and then every W3C member gets an email saying “The W3C CCG has published the draft ...”. The IPR risk mitigation tools are only used at the last stage, the final report. ✪
...The final report stage is something we haven’t done yet. Any questions on the stages?
Moses Ma: Bye everyone! Thanks for all the hard work! ✪