Joe Andrieu: Asked Markus about a pre-meetup in Vienna ✪
Amy Guy: Anyone then roadtripping from vienna to prague? ✪
Markus Sabadello: Yes, he is planning on a pre-meetup in Vienna prior to Prague, two days early. The first day will be Sept 1. ✪
Kim Hamilton Duffy: Asked about TPAC because the chairs have an overdue action item about booking space. Need to find out who is going. Brent Zendel from Evernym and Ken Ebert from Sovrin will be going. ✪
Dan Burnett: If the DID WG is created before TPAC, then there will be a meeting there. ✪
Kim Hamilton Duffy: For upcoming meeting agendas, the announcement page should have details. Waiting for completion of DID calls. ✪
...if there is any topic you want to see on the agenda, reach out to the chairs.
Joe Andrieu: : Wants to talk about new Rubrics Task Force ✪
Manu Sporny: Lowercase must/should/may is not normative. Uppercase are normative, especially MUSTs. SHOULDs are sometimes tested. MAYs are almost never tested. ✪
...sometime people don't notice the difference of using the capital format.
...so sometimes language changes make it clearer that the requirement is not meant to be tested.
...secondly, about what we can do, Manu suggests we go ahead and let the DID calls complete.
ACTION: create an github issue against DID spec. Spreadsheet, mark ones people want to keep as normative
...we may need to create a Google doc and then mark the ones that people want to keep normative to reduce the 83 number to something that's more feasible, like 20.
Topic: Rubrics Task Force
Joe Andrieu: At the last DID call, it was agreed to create an informal task force to agree on the scope of the Rubrics work, and to kick it off. ✪
...Joe doesn't have a time yet, so it may not be next week, but calls will start soon.
Joe Andrieu: Re : rubrics task force, email me at joe@legreq.com if you want to join the calls ✪
Kim Hamilton Duffy: Next topic is the registry meta-topic. ✪
...we have some ongoing work items; registries is one of those.
...Manu introduced a process whereby any group can create a registry.
...If we want to suggest our process as the best way to do this, what do we do?
Christopher Allen: Some WGs are facing time limits, and must finish on time, but after they are done, they often have leftover items like registries. ✪
...the CCG is a logical place to do that, and has agreed to.
...there is a Process Group at the W3C that decides about such things.
...this group has discussed "evergreen working groups" that have been chartered to be continual
...Christopher asked that group about registries
...Some members of the Process Group felt it was appropriate, others felt that it should be a separate process
...their meetings are 7AM ET, so Christopher hoped that someone else could monitor/work on this.
...that said, the CCG still doesn't have our own registry process worked out
Topic: Credential CG Work Item Process Draft, simplified
Kim Hamilton Duffy: 2. Https://docs.google.com/document/d/1vj811aUbs8GwZUNo-LIFBHafsz4rZTSnRtPv7RQaqNc/edit#heading=h.6vb19y4yyl3k ✪
Kim Hamilton Duffy: Hopes that people find this much simpler ✪
...wants to start with the work item process that applies to any work item effort in the CCG.
...Kim hopes the state diagram is clear - it's a 40,000 foot view
...the adoption process is how the supporter finds support in the CCG
Manu Sporny: I think this should be proposed as the default W3C CG process for groups larger than 10 active participants. ✪
...once there's been discussion for at least a week, and there are no objections, and it is covered under the charter, then it is adopted.
...is it an ongoing community draft (such as a registry), then it will just keep going until it is closed after a period of inactivity.
...the other type is a finite work project. It will be closed either when completed or after inactivity.
...ongoing community drafts (like registries) and community report drafts (like specific docs).
...conformance test suite is another type of ongoing project.
...community reports drafts have several subtypes. A draft spec (e.g., DID spec), a community note (e.g., DID Primer).
...notes would not go on to a WG but a spec might.
...moving to 20,000 foot view
...within those two types of projects, what is their process.
...there is a well-known process for community notes as shown in the doc
...rough draft, unreleased draft, release draft (when the editors tag a release in the repo), final release draft
...any of these can exit early
...giving some examples as of May 29 2019
...DID method registry -- intended to be an ongoing thing
...DID Primer is a community note. Currently in an unreleased phase.
...further along in the process is the DID spec—a community draft
Christopher Allen: The DID spec is a published draft ✪
Kim Hamilton Duffy: Hopes this diagram helps clarify these things ✪
...particularly if we add links to the deeper parts
...this is still a lot to know. Hopefully this is only needed by some people, such as chairs.
...It is designed to help broaden inclusion and identify areas where we can make it easier
...in the community report draft stage, it moves into another stage when it moves to github
...for other types of community reports, it's been fairly natural for a lot of the iteration to happen in less technical tools like Google docs
...that would make it easier and more accessible
Drummond Reed: +1 To enable as much work in Google docs (or the equivalent) as possible ✪
Dmitiz: Asks about a subprocess for something in a registry, such as the did:web: method. ✪
Kim Hamilton Duffy: That might be a community report ✪
...it depends on how the registries deal with it
Christopher Allen: There are 2 issues here. One is the registry change. ✪
...so the first one is just acceptance in the registry.
...then the second question is whether the particular DID method will be a CCG work item.
...if not, it would be in a separate non-CCG repo. But if it's going to be a CCG work item, then it goes through the process.
Dmitri Zagidulin: For specs that want to be part of the CCG umbrella—that want a spec and repo under CCG—they go through the community report side of the workflow. ✪
Kim Hamilton Duffy: The chairs will be coaching some new items through the process. ✪
Manu Sporny: We have heard enough people complain that the github process is exclusionary—and even the tech spec have large swaths that are just text... ✪
...so anything we can do to transition the editing cycle to Google docs or similar for as long as possible before the final stage, it will help gain more input.
...we could really use help polishing off that tool chain
...it will have a very positive impact
Kim Hamilton Duffy: Bill Barnhill has been looking into that ✪
...this is absolutely one of the critical pieces to help make the process more inclusive
Christopher Allen: Until the tooling is better, there's nothing that prevents a work item from going from unreleased to final report quickly, i.e., from a Google doc into the final Respec form in a repo. ✪
...that process could happen in a week, and have a version number attached, and it gets published.
...the final step of turning it into an official report might take a little longer.
Kim Hamilton Duffy: Thanks for calling that out. ✪
...that early stage can work in another form like Google doc and the team can get paired with someone who knows github.
...in the following weeks we are going through work item repair (but we won't get to them today)
Bill Barnhill: I’ll report on issue 76 next week. ✪
Manu Sporny: Has the same issues with putting everything in Google. Suggests we just look at an editor as a tool, and suggests that we export as often as every day. ✪
...the goal is to find an easier way for people to contribute.
...so there are ways to solve this.
...unfortunately W3C wiki has not been very easy for many people.
Ted Thibodeau: You have to jump through "some hoops". ✪
Kim Hamilton Duffy: Must close the call due to time. ✪
Heather Vescent: Commenting here, that github is not user friendly for non-technical people, which is a major problem re: inclusion. Not sure I understand why google docs is a problem. Haven't seen that detailed in the notes. (Am not on phone) ✪
Ted Thibodeau: Heathervescent - most significantly, change tracking/viewing has been a major challenge in past work on Gdocs. (That may have improved; Gdocs *is* a constantly moving A-B-testing target.) ✪
Amy Guy: I think we're significantly less 'locked in' to github/microsoft since we own the underlying data through git ✪
Dmitri Zagidulin: I'd be happy to find a non-google-doc alternative that has a good annotation / sidebar comments functionality ✪
Amy Guy: If google decided to take away all our docs overnight, even if we had exported them, we can't reconstruct that environment ✪
Amy Guy: Ugh yes dmitriz I agree, need to see how nextcloud is doing ✪
Heather Vescent: @Tallted, if you use suggest changes, it makes it super easy to collaborate with many people ✪
Ted Thibodeau: Heathervescent (others) - Can you pick two arbitrary versions to compare? (This has been a key feature of wiki-based work in the past, both for reverting changes and for saying "you're doing great at this, can you do more?") ✪
Ted Thibodeau: Yes, google docs lets you do that [scribe assist by Dmitri Zagidulin] ✪
Heather Vescent: TallTed - not sure. I tend to do collaboration with the parties directly. There is less need to reconcile versions because everyone is always "on the same page" ✪
Dmitri Zagidulin: View revision history, and pick two arbitrary versions ✪
Heather Vescent: Vs editing MS word asyncronously. ✪
Amy Guy: Personally I'd be grumpy about being required to blanket agree to Google's terms of service in order to contribute to anythiing ✪
Dmitri Zagidulin: Or wait.. possibly that feature was removed... ✪
Heather Vescent: I think it comes down to level of comfort. As a writer, I am power user for Google Docs. The other writing tools I use are not collaborative. Github makes me super cranky when people try to make it fit with writing. It is not a writing tool and no real author would ever use github to author anything. ✪
Ted Thibodeau: Dmitriz - "revision history" is dimmed on the file menu for the doc we were just viewing ... which may be because I'm a suggester, not an editor... or may be because Google is playing A-B games ... or may be because they broke something, or took it away. ✪
Dmitri Zagidulin: Yeah, could be a permission thing ✪
Dmitri Zagidulin: Anyways though, I think we just need to draw up a list of required features for an alternative. ✪
Dmitri Zagidulin: And see if any other sw supports it ✪
Ted Thibodeau: Heathervescent - *live* collaboration is a different ballgame, to me. Asynch collaboration is far more typical, and (in my experience) far easier when working with larger groups -- because while you're all on the same scroll, Joe may be on "page" 12, while you're on "page" 27, and I'm on "page" 53 -- and each of us may be making contradictory edits to those areas. ✪
Ted Thibodeau: The "live save" model means that each word-level or even character-level change is a version -- and you can have interspersed edits by each of those users -- so comparisons are even harder to figure out. ✪
Ted Thibodeau: This is another reason why wiki page-save or git pull-request changes are better in larger, more asynchronous group efforts. ✪
Amy Guy: From my reading of the google ToS (https://tosdr.org/#google) google has a right to use any content we provide for promotion of google services, use it in any google product other than the one you upload it to for other reasons that what you provided it for, and the license continues even after you stop using the service ✪
Amy Guy: Hopefully they don't find a way to use DID stuff to promote google services though ;) ✪
Ted Thibodeau: Just wait for the new G-DIDs "10% project" to surface... ✪