Manu Sporny: Emails to CCG list need [AGENDA] prefix and date/time in subject, agenda in body. followup email with notes also good. ✪

Juan Caballero: Since I didn't send the Agenda link, but there are people from CCG here. Shoudl we have the meeting? Happy to end early, send out proper email, for next week. We could spend time trying to make the next call productive. ✪

Orie Steele: We should cover procedure and run next week's as a public call; as long as no substantive proposals THIS call, I'm happy to provide feedback and talk about the proposal ✪

Manu Sporny: I share the frustruation and want to get the procedure sorted and propose a strategy that adds less work to all of your schedule, but we don't have quorum ✪

Orie Steele: We have given a lot of work to V-H-A and I agree that we don't have enough UCR there; everyone seems to contribute only to the extent that it helps their use cases ✪

Orie Steele: Markus has his own opinion about it; wasn't it originally created as part of a Danube contract? ✪

Orie Steele: We're building stuff, we know what the API should do, to some degree it's not exactly lying but kinda transitive interoperability -- A === B, C supports B, therefore A supports C. There's nothing wrong with that, it's just not good enough. The first version of anything isn't right - the first version of the VC HTTP API isn't good -- took a year to get a revision -- pacing is too slow for our needs - interop space. We've moved the Traceability vocab faster, git pull request -- merged even if they're not super great. Others come in behind that fix them. Mesur has fixed problems I created, etc. We have been operating in a healthy and productive way. It's totally different from what it is like to work on VC HTTP API. Not that future of Traceability API overrides VC HTTP API -- only way for it to become broken would be for VC HTTP API changes. I'll stop there -- other companies, other than Transmute - Direct Exchange problem -- postman collection test work - excited to invest on those flows across multiple parties. Test different interop flows, different mechanisms, doesn't do stuff that we want it to do. In a way it's a fork, but in a way it's not -- doesn't make sense to include them, as Markus agreed in a PR. ✪

Heather Vescent: https://github.com/w3c-ccg/meetings/issues/41 ✪

Mike Prorock: I share the timeline frustration, with both priv and public sector customers ✪

Mike Prorock: Manu, you had mentioned about alternate paths to go tackle issue -- definitely echo frustrations that Orie provided... similar concerns around pacing - rate that we need to move at for our customers -- both commercial and government customers -- that is top of mind for myself -- owner of business, CTO, etc. There is a pace we need to keep up to work on interop ✪

Mike Prorock: That's the big concern that we need to get at from the Mesur.io side -- even if this ends up folding back in -- recombined split... I'm cool with that, doesn't bother me as long as there is a place where we can make progress, ahve these meetings, all the various items that we need to -- notify someone of VC, all those various use cases -- starting to get at. Proposal that orie made. ✪

Mike Prorock: What Orie said, but Manu, want to hear your insight... Welcome your input on this. ✪

Manu Sporny: I sympathize, but i want us to consider how this looks from the outside like a hostile takeover of a spec process by 1 or more companies ✪

Manu Sporny: This is the big tech standards playbook, and it will not look good in retrospect ✪

Orie Steele: Describing what we've done in that way is a self-fulfilling prophecy ✪

Manu Sporny: There are two kinds of forks-- PR forks and spec forks. the latter is dangerous ✪

Orie Steele: I disagree ✪

Manu Sporny: Unfortunately W3C history supports my concern ✪

Orie Steele: I don't think is a work item (yet), there is no working group being forked ✪

Manu Sporny: It is a CCG work item ✪

Orie Steele: We need to move things forward, conversations like this are only one part of what will move us forward ✪

Orie Steele: I am trying to make as clear as possible that this proposal is to extend peaceably the V-H-A ✪

Manu Sporny: But this creates more work for people, incl me and other editors, and i think we need ✪

Heather Vescent: I hear what Manu is saying about the constraints of the CCG Process in which things have to occur at W3C. ✪

Heather Vescent: I saw TallTed make those comments as well in the thread -- I know there is disagreement and desire to move fast and forward, and I'm not a fan of bureaucracy or W3C rules. ✪

Heather Vescent: I think you should seriously consider what Manu is saying -- and the way it is read in the W3C. ✪

Heather Vescent: I do believe the way that Manu described it, is not what you intend. I also hear and respect and understand the slow pace of the work item -- that can address the need to go fast. ✪

Heather Vescent: I'd like to ask both sides to go back into your corners and truly consider other's perspectives, goals, needs -- even if you 100% agree... try to get a view of the other place. ✪

Heather Vescent: Let's come to this fresh, with a fresh view on how to address it with constraints of W3C and companies involved... companies that need resolutionf aster. ✪

Juan Caballero: I wanted to just mention, now or end of call -- hear from Justin and Brian -- they may be at a disadvantage -- everyone has been participating for a while -- seprate work item created, separate branch, next steps are kinda the same either way... sake of setting an agenda for next tuesday -- one thing in multiple threads... this change... multiple models proposed, different models, markus was saying he had a backlog of things -- verifier API... EU ✪

Juan Caballero: However we do it, there are parallel work streams -- not attached to a particular mechanism... there is a lot of work that's held up by ... doing the work... should be mindful of other work relevant to this. ✪

Juan Caballero: The workload on the Editors, might get to be a lot of work if it stays to be one repo -- maybe a heather/manu/markus question. ✪

Orie Steele: It's my understanding that even if work items seem similar, or start on similar items -- all vocabularies start w/ assumption of VC spec, it's my understanding that you don't need permission to create a new work item if it has similarities with other ones... I realize it's uncomfortable, people that don't work with software all the time, don't feel comfortable w/ forks... Is there anything legally preventing us to work in parallel and contribute to ✪

Orie Steele: Well in fairness watching a thing that is not changing at all isn't super challenging :) ✪

Heather Vescent: I don't want to add a roadblock to it -- doing minutes from previous meeting -- don't think it's planned obscuration of VC HTTP API -- these have been raised privately between the Chairs and ... there are at least two Chairs that have concerns. I wish Kim was on this call -- I think it's good community participation to go through the process we have, which I know is annoying and frustrating, but that's where it is -- don't want to roadblock you guys, there are annoyances with working w/ W#C. ✪

Mike Prorock: Many, that's well said, with ReSpec stuff -- what the hell are we testing again, what's this VC HTTP API even mean, which is why you saw my commits last year -- just around README side of things -- what is this doing, try to describe this stuff... if nothing else, 100% supportive of exchange of information and what are we after. I am also supportive of going about it in parallel -- if that's the case, let's correct the perception, key thing ✪

Mike Prorock: If we have an API that does that cleanly, if that spec happens in VC HTTP API -- that's also cool... somehow, something has to happen... that's the issue. ✪

Juan Caballero: For the record, for the future people that might attend CCG calls, topic calls on the subject, coming in late, it's hard to figure out where to start. Kim's broader questions on where use cases are, where requirements are, everyone every customer or potential partner of Spherity doesn't understand where this is coming from. A year and a half of backstory there... that's just my concern, adding use cases to a document I'm not even sure what I'm adding it to... personally, confused about next steps. Tiny bit of explicit guidance would help. If this is going to all stay in kitchen sink repo, feature branches, what's the UCR of that API? ✪

Juan Caballero: Started on Google doc based on architecture -- formatting... how do we get from here to CCG regularity -- retrofit previous works so future work can build on it. ✪

Orie Steele: Speaking as one of the folks that contributes to a large number of CCG items -- you open PRs, you discuss on PRs, you try and make actual changes -- can't just talk about how things should be better... you have to be the change in the world. Speaking as Transmute, we'll continue to support VC HTTP API -- we will continue to help w/ that API, but we can't shape the vision for it -- we can't dictate the vision for it, it's a community effort -- it can't just be one company doing it, it has to be people agreeing to what it will be. ✪

Orie Steele: From a UCR document, a number of us have been working on supply chain VC use cases, DID Core, EDV spec... we've worked on presentations w/ companies on VCs... to say we need a use case for exchanging VCs in supply chain credentials, we have a document for it -- feels like we have a clear understanding for supply chain oriented credentials... we've demonstrated interop on those credential formats... we're going to continue to do that work in parallel. ✪

Orie Steele: I do agree with Manu, if we could get a sane VC HTTP API single source of truth, that would be best scenario -- but often w/ standards, you don't get the best thing... totally sympathetic that VC HTTP API is confusing, it's brutal... vaccination test suite -- use case driven interop for vertical make a lot more sense. I don't think VC HTTP API can tell that story by itself. ✪

Orie Steele: We've already been doing that in test suite today. Relies on traceability vocab, vaccination vocab, endpoints we used were built on top of those vocabularies. There has always been a use case oriented API... haven't successfully conveyed stuff to it... people are asking people to do more work when we've already put in a lot of work... support new APIs, all these things that we want, who is going to do the work. Fundamentally, who is going to do the work? ✪

Orie Steele: I don't know that I agree with idea that use case specific interop is something we should shy away from... easier for us to tell a story, use case based interop can be built on other things... use case oriented interop would do a better job at first -- excited about opportunity to explore that, not something we can explore by ourselves... but if there were PRs merged, shape visibly change, my opinion would change. ✪

Orie Steele: But it would need to have PRs and work requests done to get it there... in the meantime, we need to be able to tell interop stories w/o being blocked by that particular API. ✪

Manu Sporny: I don't disagree with a whole lot of that. i think the standards process is always held up by how much work various participants can or cannot submit ✪

Manu Sporny: Doing things in parallel sounds great to everyone, i understand the temptation. i can't work on it at the moment and there are very few people who can balance this with the did-core test suite, for example. at some point, tho ✪

Manu Sporny: Let me see if next week we could talk about ideal structure ✪

Juan Caballero: Ok, next week could do UCR agenda next week and how to split the work up. ✪

Heather Vescent: I thought you said work in preparation during CCG call. ✪

Heather Vescent: Kim will be moderating, need to make sure she's in the loop on that. ✪

Juan Caballero: I can follow up with Kim. I'll do that. ✪

Juan Caballero: I do want her help regularizing the back history of that group, she was the one pushing for that. ✪

Juan Caballero: We can keep agenda for next week... week after... agenda for this group -- use cases in the... Traceability Vocab meeting -- once we're finished w/ API -- going back to Vocab. ✪

Heather Vescent: Is this a Task Force, a separate call? Is it part of DIF -- have you talked to any of the Chairs? ✪

Juan Caballero: Good question, don't know answer to those questions... ✪

Heather Vescent: Task Force has a formal process and structure, and work item is separate... everyone in this community is stretched thing, so many meetings... just not sure where to slot it, where CCG needs to manage it... want it to go on autopilot and not micromanage. ✪

Orie Steele: :) ✪

Juan Caballero: This was a weekly meeting for SVIP companies... SVIP companies were encouraged to make sure output is useful for CCG and public and published.. I didn't think about why we aren't scribing, not emailing Agendas, thought... I don't know. ✪

Mike Prorock: A little history -- I setup a standing meeting, anyone from SVIP, focused on supply chain / traceability meetings -- ensure we were aligned for interop tests... specific to SVIP topics only, obviously, ther was a lot of "we're also working on this stuff out in the open" ✪

Mike Prorock: What we're seeing w/ VC HTTP API -- the second this moved past, talking closed vs. talking open -- that was immediately the flag, create a work item, open this call up as a public call to anyone that wants to join. Any issues to traceability. That's how this whole meeting started. The four of us on a call, we're here, were discussing plugfest, need public vehicle. ✪

Mike Prorock: Last week, at that point, Juan just emailed it out to a list -- wanted to avoid creation work or backroom discussions that could prevent ... make things not clear -- Trace Vocab, interop tests... that's whole history of how this whole thing got started... internal call -- other companies w/ shared customer. ✪

Mike Prorock: Wasn't anything beyond that... we tested it, we worked on trace vocab stuff... other trace issues on VCs and DIDs, make sure there is ability to talk out in open about this stuff... avoid problems in communities... how did I get input into that... does that make sense? ✪

Heather Vescent: Thanks that helps, you guys have been doing this stuff for years now... I think I might, same goals... this is what I think needs to happen: You guys need to conclude your SVIP work and end that, and I think you've done that... and then it needs to consciously transition into openness, part of that transition, what is that knowledge, what did you build? Watching what was happening, I didn't get what this was w/o sitting in those 15 hours ✪

Heather Vescent: How do you tech transfer this from your internal project and productize and make it accessible to other people in community that have no clue about these discussions. ✪

Heather Vescent: You need to build that community -- you've been working fast... but you have to slow down a bit -- let people get on, let people get onboarded... separately with CCG 101 -- trying to do that as well. That's what I'm thinking of as Chair... make tech accessible to more people... part of that is, formal beginning of what this meeting is... you need to consciously start from ground-zero so it's accessible to new people. ✪

Orie Steele: At DIF :) ✪

Mike Prorock: Obviously engaged on 101 side as well... this is what we want to avoid -- we have a good place to do that... we have people engaged... let's make sure people are engaged... moment it's a possibility - once it became clear, early in the process... this process should be out in the open. ✪

Mike Prorock: Companies working w/ one common customer base... that's intent of this call... but got side tracked a bit w/ API -- otherwise, we'd just be talking about traceability stuff... how do we exchange this stuff... how do we do this right. ✪

Mike Prorock: This does need to be out in the open, there is a balance on pacing... async and github is good, there needs to be good alignment, need to do this stuff and make progress w/o waiting weeks for PRs to get merged. ✪

Heather Vescent: +1 Manu ✪

Heather Vescent: Part of my role as co-chair is to assist -- how can I help in kick-off and make this more accessible to broader community and address other concerns. ✪

Orie Steele: The thing to do is have these calls, in context as Supply Chain Traceability as it's own concept -- let's not start w/ VC HTTP API -- want to start w/ Supply Chain Traceability/Security, why it's important, this call is the opportunity to be more open about it. We've been doing it on Github... and that is where progress is made, we do need to introduce supply chain traceability, non-technical contribution... work backwards from there to standards to support it. Specific issues on some of those standards. ✪

Orie Steele: We just need regular calls that are open... we've been having a closed version of that for a whole bunch of items... it needs to stop, problematic for entire community -- sounds like there is a group of companies for work items, that needs to stop, you need to do that across the board. ✪

Orie Steele: Every other work item needs to be treated equally. ✪

Heather Vescent: This sounds like it's a Supply Chain Task Force vs. just a specific work item. ✪

Orie Steele: I don't know if we need any more process... we'd love to share that progress w/ IPR protected space... otehr work items, as a part of that. I thik we'll continue to do that... don't want more formal process for this work unless we need that for aircover to have open meetings. ✪

Heather Vescent: I'd like to reduce task forces... some have value, but lots of meetings. ✪

Heather Vescent: Work items so far, specific technical work items, use cases and stuff -- does it make sense to have work item that's broader? That would address -- supply chain work items with other things? ✪

Orie Steele: Traceability vocab has nice preamble... that vocabulary -- asserting that if that's not soft enough, let's not create a new thing to make it better... level up in technical complexity -- data model, how do I exchange these things. Today, we announced we want to work on Traceability HTTP API -- would love to be able to talk about both of those things on this call, if folks don't have background on it... can explain why. ✪

Mike Prorock: +1 Intro call ✪

Heather Vescent: As part of kick-off... could you put together different work items... supply chain traceability have that meeting be one of those first meetings. ✪

Orie Steele: We could do that -- PRs to Traceability vocab as landing spot... you really don't want another asset to do the introduction. ✪

Heather Vescent: Maybe as part of intro call... could pull CCG 101 folks into it -- 101 intro to specific set of work items... cover content - intro content. ✪

Heather Vescent: +1 Manu ✪

Orie Steele: :) ✪

Heather Vescent: This all sounds fine, hear your concern, updates sent to list -- sent quarterly, 3x a year -- we can fold in what's going on, what's going on in this community, back to main CCG list, so we have coverage. ✪

Heather Vescent: Main meeting, Markus' meeting -- not meant to be weekly update/monthly update -- just 3x a year. ✪

Heather Vescent: Think of CCG call as a place where we can discuss these things.. if it's short term, we can use CCG slot. ✪

Orie Steele: I'm not sure that's a solution to the VC HTTP API problem. ✪

Orie Steele: This is very clearly a Traceability call... we don't spend a lot of time about VC HTTP API and LDS. ✪

Heather Vescent: Trying to understand what you are transitioning into a public venue. ✪

Orie Steele: Regular recurring call for Traceability -- we've set it up... we'll do intro. ✪

Orie Steele: 2Nd part, addressing VC HTTP API in regular call -- with stakeholders moving that forward. ✪

Juan Caballero: Was just saying that, since we were talking about API at next CCG, and at IIW, send out email next week... Traceability call -- that group can talk about things it wants to propose to VC HTTP API group, just as proposals, still need to go to calls Manu is going to set up. ✪

Juan Caballero: Traceability vocab group will meet as often as other Vocab groups meet, not as Task Force... maybe talk as things in API -- usurp API authority to have its own timeline. ✪

Heather Vescent: Question: who is the lead for running/managing *this* meeting (the Supply Chain tracibility and security call) ✪

Juan Caballero: ...And IIW sessions. ✪

Juan Caballero: Procedurally - "Traceability Vocabulary Work Item" -- that's it's primary focus, if it wants to talk about use cases... that should feel secondary -- group that has been discussing vocabulary - this has been it's regular time, Mike started it, he is leading this group... Mike, Orie, Mahmoud are Editors... keep call time, keep meeting, eventually, we have folks in EU time zone, would like it earlier. ✪

Orie Steele: We can cross that bridge when we come to it. ✪

Heather Vescent: Orie, Mike, Mahmoud are in charge -- Orie... ✪

Orie Steele: I'm the Editor of the spec both for VC HTTP API and Traceability Vocab -- ping me on CCG list, will respond publicly ✪

Heather Vescent: When you guys are ready, for intro for new audience of people -- tell me, send me content, I will forward it out as intro to the list. Show broader interest -- support, give broader context, not clear w/ email that came through. ✪

Orie Steele: I hear you, I will set this up w/ other Editors of call... ✪

Heather Vescent: Great, at your service to support, but do have requirements. ✪

Heather Vescent: Thanks all... Manu? ✪

Manu Sporny: Yep, I feel better about this. ✪