Kerri Lemoie: Okay everybody think we're good to go here welcome to the MonDay verifiable verifiable credentials for Education task force it's October 17th today we're going to review the open badges 3.0 candidate release. ✪
Kerri Lemoie: You I'm some introduction introductory items. ✪
<kaliya_identitywoman> sound itsn't working for me on chrome
Topic: IP Note
Kerri Lemoie: Anyone can participate in these calls however any substitutive contributions to any of the ccg work items must be done by members of the ccg with full IP are agreements that are signed the links to this are in the agenda emails that we send out so please take a look at that if you would like to work on the standards and participate in this work with us secondly. ✪
Kerri Lemoie: All recorded and they're archived we also have a robot transcriber that sometimes understands us and sometimes interprets Us in other ways if you would like to see any corrections in the in the transcription that would be very helpful for us when we publish you can do so by doing a civil reg ex substitution I'll put it in the chat for you now see you do s slash wrong-word slash correct-word. ✪
Kerri Lemoie: Also we follow a queue system and these calls so if you have something that you would like to say ask a question introduce yourself once we get to that part of the agenda you can just type Q Plus and if you'd like to you can say the reason why we're adding yourself through that will help us integrate your you into the conversation a little bit better and then to remove yourself from the queue just uq-. ✪
Topic: Introductions & Reintroductions
Kerri Lemoie: Okay so with that why don't we start with them introductions and any reintroductions so is there anyone who's here today that is new to the call or his rejoin the call or they give us an update on what they're working on you left you I hear from you. ✪
Kerri Lemoie: Thank you TallTed for the correction in the Scribe. ✪
Topic: Announcements & Reminders
Kerri Lemoie: Next is anybody have any announcements and reminders. ✪
Kerri Lemoie: What I typically do here if no one has any other announcements is put the link to the ccg events calendar so that you can see what's going on with that. ✪
Kerri Lemoie: And then I'm sharing a teacher in the queue for announcements. ✪
Sharon Leu: Thanks Carrie this is just a reminder that if anyone is participating in plugfest we're having a technical conversation this coming Wednesday and I'll send a reminder also on the mailing list. ✪
Topic: Main Topic - Open Badges 3.0 Candidate Release Review
Kerri Lemoie: Awesome thank you Sharon and actually that is an excellent segue into our main topic for today for part of plugfest look like that's what we've been doing is implementing open badges 3.0 as part of stage so in the first book Fest we implemented A variation of open badges. ✪
Kerri Lemoie: I was sort of like in time box for where it was then because we knew that it was sort of still a moving Target for plugfest to that I'm we're in the process of right now open badges 3.0 is in a candidate release and we thought it might be helpful to review where it is right now because it's not final yet but it is in release and to tell you you know you know what is specific to the open badges 3.0 implementation. ✪
Kerri Lemoie: Credentials you know how they how they made choices to do this alignment and then we can have a discussion about that and then Wednesday is called the plugfest technical call we can talk about what the example should be for a plugfest implementation because we haven't provided those examples yet we wanted to have this discussion first and then on Wednesday we could talk about that more and by the way even if you're not participating in like this you can join us on Wednesday as call that's why Sharon is sending this to the public. ✪
Kerri Lemoie: Hey I'm still some history last June not last year in June of last year we met as a group and decided that we're going to encourage that open badges be aligned natively with verifiable credentials and by natively what we meant was integrate with verifiable credentials so that it used the the structure of the VC data model and also the verification R-Spec right the the identities the proofs. ✪
Kerri Lemoie: And want to Tech which is used to be called IMS Global they've been working on that all year and so what we did as is for VCS use we provide our proposal we said this is how we think you should do it and then they created a new Charter for open badges 3.0 and also added a charter for their comprehensive learning record V2 so that they could align those models along with aligning with verifiable credentials as you can imagine they have a pretty substantial. ✪
Kerri Lemoie: Our standardized way of doing things when I text so they made some decisions along the way that we should review today as a group so you can understand what it did what they did and then we can we can open it up for discussion. ✪
Kerri Lemoie: I think you know often times we have those members of the working groups and IMS who attend these calls so there's anybody here from those working groups who want to clarify anything that I say that would be very helpful to us thank you. ✪
Kerri Lemoie: Well you know what I'm going to give you the link to the slides because it'll be a lot more helpful for you to have this link. ✪
Kerri Lemoie: Yeah I where you can click on things. ✪
Kerri Lemoie: Let me just go back to this page to this is the second page of the slides the first thing is the original proposal that was done this one was done in the last version of it was August 11th in 2021 the GitHub repo is an open repo and you can view if you look in the repository a V3 you can see the work that's happening in there you can also see prior versions of open badges. ✪
Kerri Lemoie: Is what we're going to be looking at today and we're not going to go in through the hole specification we're going to go through the basic open badges credential there's a lot more in there that you can look at allow more way more properties and we're going to be able to cover today but that you could read in there and also if you have questions about the specification the open badges repo is public and you can submit issues you're going to see that we have some issues that we've submitted already with some questions about 3.0. ✪
Kerri Lemoie: Basically reflection of the specification and as you implement a 3.0 you can test against this they from what I can tell pretty much in sync that they make adjustments to the schema and they happen in the specification somewhat automatically I think so I'm this is something worth knowing and then we're also going to look at the sample open badge this is their basic very basic sample. ✪
Kerri Lemoie: Example that we're going to use for breakfast also going to be very simple and we're not going to be looking to adding for instance like alignments to competencies and that type of thing right we're going to be looking at issuing a verifiable credential in the form of an open badge from one issuer or from an issuer to a wallet right so it's about transporting and displaying an open badge as part of the plugfest. ✪
Kerri Lemoie: So what he did was should have list out the required elements that are specific to open badges 3.0 that are different from a verifiable credential like I mentioned before this isn't everything I this is sort of the main elements that would be looking at as part of implementing this for breakfast too so first what I'm going to do is show you the example. ✪
Kerri Lemoie: And I must give you the link to this right here in case anybody wants to pull it up. ✪
Kerri Lemoie: But this is an example they provided a little from batch. ✪
Kerri Lemoie: You can see from the structure that it looks like a verifiable credentials so this is what is intended as you know an alignment with a verifiable credential we have a context we have a type and ID issuer a date a credential subject and then we have a proof. ✪
Kerri Lemoie: I'm going to do is go through and explain what all of these elements are in the context of matches so context so a verifiable credential has context is json-ld and we use this to determine what the properties are in the credential so minimally we always have the verifiable credential context at the top open badges credentials will have their contracts file. ✪
Kerri Lemoie: Since about this one I'm not sure why this one is here so I'm going to ignore that for now. ✪
Kerri Lemoie: One thing that they've added so it's verifiable credentials and ID is optional with open badges they've made this required and it can be a URI not necessarily a URL as presented here it could be a uid but it should be as they said in their spec and unambiguous reference to the crunch so this is a unique ID / issued credential. ✪
Marty Reed: Yeah I just wanted to speak on the ID being required just because I know that was a. ✪
Marty Reed: Um interesting kind of decision from a verifiable credential standpoint but the reason why and it was debated amongst the group significantly was this is a transition. ✪
Marty Reed: From very centralized spec to a you know support decentralized verification so as we kind of transition from centralized to decentralized some things like ID are very useful in a centralized format and so and so that was why it can remain required to provide that kind of transition between specs. ✪
<phil_l_(p1)> Just to clarify - list of items in Kerri's slides are differences between 1EdTech vs. the VC v1.1 data model.
Kerri Lemoie: Thanks Marty does anybody have any any points to make about that. ✪
Kerri Lemoie: Thank you Marty and I just you Phil Long's message in there I had to clarify the list of items that I have in the slides are the differences between the trade between what one edtech has implemented and what's in the VC data model. ✪
Kerri Lemoie: The next type tape is something very we're accustomed to and verifiable credentials we have a type of healthcare Angela and then we have the type open batch credential. ✪
Kerri Lemoie: Which relates to what's in the context. ✪
Kerri Lemoie: Super issuer issue or a verifiable credentials an issuer can be an object or it can be a single ID in this example that they provided it's an object and the object actually the issuer from what I can tell must be always be an object because it has to contain a type this type array which references profile. ✪
Kerri Lemoie: Profile I put a link to in here is a series of fields that can describe the issue. ✪
Kerri Lemoie: Should the profile elements are not required but the type profile is required. ✪
Kerri Lemoie: And sometimes looking at this and calculating this been pretty sure that this here refers to this ID here. ✪
<keith_kowal> Can the issuer ID be a DID?
Kerri Lemoie: I'm name is not required as part of this year. ✪
<dmitri_zagidulin> @keith - yes.
Kerri Lemoie: But there is a name that is required. ✪
Kerri Lemoie: And hear me close that sorry everybody is human state is part of the v-spec and that is required as part of the v-spec the open badges spec requires name and this reference is the string and references the name of the credential subscribed for display purposes in the wallets. ✪
Kerri Lemoie: I thank you for bringing that up that's been a historically sort of question open badges to over the years it's been interpreted differently what's been happening and I discussion in the V2 group. ✪
Kerri Lemoie: That's great thank you for bringing that up so long. ✪
Phil_L_(P1): Yeah that's actually going to become even more significant as we get to the point of trying to retroactive a retrospectively convert issued credentials from years past into a verifiable credential format and and so it's not unreasonable to think in a relatively short time someone will have credentials from 10 years ago or eight years ago that an institution issued as a PDF or whatever and. ✪
Phil_L_(P1): It is to convert that into a structured. ✪
Phil_L_(P1): She'll have been developed and that big difference than will become pretty significant. ✪
Kerri Lemoie: Thank you David that's really good to know. ✪
Kerri Lemoie: Hey I'm going to move forward so the one the field we were just up for the conversation was a name teamwork this example is teamwork badge and this is a required field in the open badges spec. ✪
<david_ward> In OB3, there is an activityStartDate and activityEndDate allowed in the credentialSubject to specify those dates.
Kerri Lemoie: Then we were talking my potential subject I think what I just said was ID is the subject ID of the claim being made in the credential subject I'm in the open badges fact they Define this credential subject as an achievement subject I have questions that we've submitted about this being an array but the type of potential subject for an open badge is an achievement subject and then in the open badges specification. ✪
Kerri Lemoie: Spell out the fields that are required in an achievement. ✪
Kerri Lemoie: It's the little bit this is the the schema did I let me find the chart for you so it's a little bit easier to read. ✪
Kerri Lemoie: And so these are the properties of the achievement subject. ✪
Kerri Lemoie: For part of sorry about that so the we have the type the required type of credential subject is that you've been subject and then we also have a required achievement and achievement is interesting human is something we actually proposed as part of the original proposal for alignment because we were talking about this at least a year and a half maybe two years ago about how bcig we are suggesting that this could be. ✪
Kerri Lemoie: Has achievement or has credential based on what is in scheme. ✪
Kerri Lemoie: So this was a carryover from that and coincidentally achievement was being used in the CLR model so it made sense to I use achievement here rather than has achievement. ✪
Kerri Lemoie: I'm you can see here that there's an ID for this achievement object in the ID is also required as part of the achievement in the open badges specification much like the credential ID that Marty and I were referencing earlier this one can also be a uuid does not have to be a URL and I'm sure Marty my degree my you could come on in and say this too was also sort of about bridging to previous versions of open badges. ✪
Kerri Lemoie: Where the achievement was actually called the badge class. ✪
Kerri Lemoie: As was hosted at its own URL and so this is a little bit of a reference to that I I believe. ✪
Marty Reed: Yeah I can I can jump in that's exactly right and there's a concept if you think about the two specs that are that are currently under development at one attack one being this ob3 the other being the CLR to and so in order to kind of better align those said that a CLR can actually be a collection of ob/ob 3s this was kind of part of that that transition but you know we're. ✪
Marty Reed: Learned and as people start using the collection. ✪
Marty Reed: Generality within CLR I'm sure there will be there'll be more maturity as it as it goes along but yeah you're exactly right curious kind of aligning so that CLR can be a collection of open badges. ✪
Kerri Lemoie: Thanks Marie and the other elements that are listed in the achievement here are the required ones so we have a criteria we have type achievement and once again I'm not really sure why this is an array so I've asked this question too because I don't know what else what other type would go in here criteria is required although the elements that go in the criteria are not required so that is also. ✪
Kerri Lemoie: Have the think seven from IMS already made a comment that that was the same way in 2.0 so I think I'm going to start need some clarification that if there's a criteria object what is is what is required as part of that criteria and then description and name are also required as part of the achievement. ✪
Kerri Lemoie: You're the key you have the floor. ✪
<sharon_leu> @Marty, probably an offline convo, but curious what is the use case for collection (clr2) vs presentation of badges
Kerri Lemoie: Right yeah that's really interesting and that you know what I think as we get further into VC edu we're like at the beginning. ✪
Kerri Lemoie: In these alignments it'll be interesting to explore that you specifically to I can see why it could be an array I don't see why it's required to be an array. ✪
Dmitri Zagidulin: Like I know the answer to that. ✪
Kerri Lemoie: Oh yeah that's a good question we should post that question so feel free to make a an issue about that in the repo cause that's a good question but Dimitri does he answer to good Dimitri. ✪
Dmitri Zagidulin: So the reason there were already was an issue in a long argument and somebody was arguing hard for Criterium and I think the consensus was although that is technically correct it's sufficiently it's officially exotic that would just not going to worry about it and make this exception because everybody interested right area. ✪
Dmitri Zagidulin: The other thing I wanted to mention briefly though is I think the requirement for the irony thing is going to perform is going to encounter a lot of friction in the verifiable credential world I know it breaks our libraries as well because. ✪
<john_kuo> +1 i recall this discussion. clarity > accuracy...
Dmitri Zagidulin: Breaks but it requires a dish a lot of additional code because it's valid json-ld to have either a single element or an array and so what a lot of credentials end up doing is just having. ✪
Dmitri Zagidulin: Litems and which will which will fail against the obv three schema. ✪
Dmitri Zagidulin: So I certainly strongly disagree with over that design decision. ✪
Kerri Lemoie: You think so jbm there's an issue for that submitted after that discussion. ✪
Kerri Lemoie: And I think what I don't have on this list surprised that I don't is this proof section. ✪
Kerri Lemoie: So for a verifiable credentials one proof is required but with open badges it doesn't require proof that it does require these elements it seems if the proof exists I have some confusion about about that so I think it's not it's not really clear to me and what is going on and what is being determined by the proof because I know there were some discussions about what is required for certification of open badges 3.0 versus the. ✪
Kerri Lemoie: I meant with the v-spec there are some things. ✪
Kerri Lemoie: A proof value that is required for proof value is specific to certain since your methods so I submitted some issues about that too so on the fourth page of the slides these are some issues that have been submitted to sort of ask these questions and and I know some of them they're already being worked on right now and people are having discussions I'm sure I think there's a call this week in that group and I'm sure they'll take a look at this because they're aiming to go in. ✪
Kerri Lemoie: And some of these yeah we'll see where they had with them I think I've mentioned most of these as we walked through them already. ✪
Kerri Lemoie: Oh this is okay well why don't I just look at the proof ones real quick here so one was that. ✪
Kerri Lemoie: Yes this is what I had mentioned that the spec doesn't require a proof but VC spect US Open badges 3.0 doesn't require one but BC spec does however if I'm proof is there it does require it to be an array. ✪
Kerri Lemoie: Is similar to the other array questions for a types right proof could be an array but it doesn't should it be required to be an array and then the other one was a season twice but the required items that I'm not really clear that I didn't really understand why these are required specifically because it seems to be a method specific some of them and also I'm not sure if they're saying that a specific method is required for open badges 3.0 or not. ✪
Kerri Lemoie: Think hey so that's that's what I have for today in terms of explaining where match 3.0 is so they'd open up the floor and see if anybody has other questions or wants to talk about it or I'll do my best answer I haven't been part of the working group for a little while so I don't have exactly the answers but Marty's here and we can also pass along questions if anybody has any. ✪
<phil_l_(p1)> Perhaps those differences that are salient to the plugfest might be a good focusing factor?
<marty_reed> yes, they will be discussed in the workgroup this Thursday
Keith Kowal: I just wondered I saw I'm not been in the community conversations you know a big element of previously of previous open batch some respects where this the public web page I'm I'm sure that that's still an option and open Box 3.0 but how does the community seeing the role of public web pages associated with achievements moving forward. ✪
Kerri Lemoie: I'm going to ask Marty answer your question but before I do Keith you mean in terms of what used to be called the badge class those achievements or the entire verifiable credential. ✪
Keith Kowal: Maybe I'll just make it more simple like you know in open badges 2.0 the you know having a web page displaying your achievement was a fairly you know fundamental thing that you could post in your LinkedIn profile or post on your Facebook so will that still be a key element of these credentials moving forward. ✪
Kerri Lemoie: Right so one of the required items for the verifiable tarantula probe measures 3.0 is that ID and ID can be the URL but it doesn't require to be URL it could also just be a uuid. ✪
Kerri Lemoie: That from my perspective from the point of verify the credentials learner or person who's earned this credential should be able to decide what that URL is and it shouldn't be public unless that individual has decided to make it public which I think is is the opposite of what 2.0 and other versions of open badges were which is that open badges data was always public because that was how it was verified and it was a sort of the platforms to negotiate that with the learners but not part of the specification. ✪
Marty Reed: Yeah I just I think it's important I just want to reiterate the the concept of the transition that's occurring right now with these specs as far as trying to better align with verifiable credentials but not lose functionality that was already built into open badge and to CLR and so this this alignment with verifiable credentials. ✪
<dmitri_zagidulin> Marty are you saying it'll be fixed in OBv4? :)
Marty Reed: Position but also the idea behind the transition of the spec was let's not change too much that we've already that we've already built into the spec that is valuable to the already existing community. ✪
<dmitri_zagidulin> awww hahah too bad
Marty Reed: And I'm not saying that Dimitri I'm just saying that this is where we're at today and will learn a lot in between here and here and there. ✪
Kerri Lemoie: I'm ready I this is just my opinion on that is I appreciate bridging strategies because we're going to need them for everything and and I appreciate that that is being considered another bridging strategy that could be considered for those who are already implementing 2.0 Badges and want to implement 3.0 badges is to do both of them is to keep the 2.0 system they have going and then add 3.0 to that as another layer for instance saying to your users on your platform. ✪
Kerri Lemoie: Warm hey would you like to put this in a wallet and then using the. ✪
Kerri Lemoie: Functionality but then letting the 3.0 spec live on in other ways in your platform that that's just another way of doing bridging so that's like two different ways to really look at it one is to say okay let's convert to 3.0 and do that and the other is to keep both going the same time. ✪
Marty Reed: And if I could respond that is you know in our open source project with North Dakota open credential publisher that's exactly what what is there there's a publishing service that takes the CLR 1.0 spec but it also applies to OB 2.0 and it transitions it or packages as a verifiable credential so so it can be done. ✪
Marty Reed: There's something out there that does it. ✪
Kerri Lemoie: Thank you Maddie and David you are the floor. ✪
<david_ward> OB3 does still allow for "baking" a badge into an image as well, so that it could be shared.
Kerri Lemoie: That's right that's right thank you David David word rings ever interesting thing in the chat that I totally forgot that should definitely be mentioned it's a huge part that I didn't mention at all which is the image aspect of open badges historically open badges were portable because they were baked into an image that was required up to 2.0 is required that the data. ✪
Kerri Lemoie: I be baked into the image so that the image. ✪
Kerri Lemoie: Read in that way it wasn't always mostly how people used it most just put it on a webpage and displayed the badge which wasn't really actually part of the spec but it was always sort of required to do the baking and a badge image was always required but with 3.0 is optional so you can still do the baking and you could that's really interesting when we should talk about and BC edging what it means to bake a VC into an image and then also you can. ✪
Kerri Lemoie: It image if you want to as part of as part of. ✪
Phil_L_(P1): Yeah well I just wanted to extend what you just said in that if you included image in the v-spec you're including just the image in you're not.you're not doing the baking in that by including the image in the v-spec you're giving an image that goes along with the data that's in the Json lots of study at that link to that image is also contained so there is a there are ways of making or or layering. ✪
Phil_L_(P1): An image in the context of qr-code but those but that's a different process. ✪
<davidc> David_Chadwick pointed out that there are two separate issues: privacy and validation. In OB2 they were baked together. With VCs they are separate
Kerri Lemoie: If the baking that we're talking about is specific to how open the open badges specification is saying that it could be done and also images are URLs they aren't embedded in the in the in the batch. ✪
Kerri Lemoie: Anybody else have any questions or things that you see in the spec that you would you'd like to discuss. ✪
Kerri Lemoie: And Transit plugfest we're going to be discussing it's going to be probably be a very basic open badge and with issue or information and an achievement information and will work with the cohort Wednesday to determine you know what that will be and what the structure of that will be and I think it's really great that we have a specification that is aligned with verifiable credentials it is spurred so much conversation over the past year. ✪
Kerri Lemoie: Verifiable credentials and really brought so many people together. ✪
Kerri Lemoie: Considered it before and it's really sort of like shifted the conversation in digital credentials so it's really great it's really great that we are at the stage where it's happened and we're going to keep working on it and towards it as Marty said right the we're not like it's not done right we'll keep going on this he Keith I see you in the queue and I put you on the floor there. ✪
Keith Kowal: Leonard I guess it's close to the high-level use cases for open badges 3.0 but you know looking at the schemas I see the achievement schema which I'm you know which I think we're pretty used to and then I see also see Lady endorser schema which I probably am less familiar with ordered using like this scheme is a framework that we could talk about like the high-level use cases you see for the I mean people Envision for the for this new version of the spec. ✪
Kerri Lemoie: So I don't know if I'm the best person to speak to that but I see that Marty put himself in the queue so I'm going to call him Marty do it the dress so he's question. ✪
Marty Reed: Well I can I can speak to I guess some of it not all of it but I guess the one thing that you mentioned Keith about the endorsement portion that the use case they're just selfishly from our application is for Teacher credential there's a endorsement of that teacher for a specific content area and they have to be endorsed for a Content area in order for them to speak and that. ✪
<john_kuo> Phil Long did a presentation some time ago on the Endorsement use case
Kerri Lemoie: X-ray we're another thing that I didn't mention today because it's not a required element and we're not using it in the in the plugfest but we did talk about it a long time ago and people were very happy with it and I think it comes to addresses these cases question is achievement type. ✪
Kerri Lemoie: This is the first time in open badges where achievement type is was was listed I before I was an open bed was a batch and we always said well open badge could represent anything and that was always the case but it never explicitly said hey what is it representing which many people find very helpful just to know that right we do have to leave it up to interpretation it specifically says is it it assessments and an assignment is it a bachelor degree is it is. ✪
Kerri Lemoie: You forget and this list that I'll link to in the. ✪
Kerri Lemoie: Aligned with the list I think mostly if not all atom with the ctd L list with Greg credential engine which is awesome right so that if a credential engine is these properties are listed in credential engine it will map to what's in an open badge which is an incredible accomplishment in terms of aligning aligning content and sort of understanding and meaning behind the digital credential. ✪
Kerri Lemoie: I mean when other thing I'm going to mention here to is evidence and I mentioned I just because it's my favorite part of a Meadows and I think that there's some tremendous there has been tremendous opportunity with that in previous versions but also in future versions especially especially considering verifiable credentials and some of the work that's been happening with hash linking and how to say I am going to verifiably. ✪
Kerri Lemoie: Demonstrates this achievement when over badges first started the evidence was actually a very like primary discussion is part of all of this because the evidence was deemed to be like one of the most important parts of demonstrating with the recognition was but over the years it's just sort of like falling back because there's a lot to handle in terms of like media and assets and you know that those are really big questions that a lot of organizations just really can't tackle but it's something to consider. ✪
Kerri Lemoie: As you're thinking about doing verifiable credentials as open badges. ✪
Kerri Lemoie: I don't see anybody else in the queue we're about 10 minutes to the hour. ✪
Kerri Lemoie: I'm glad you brought that up because we talked about that the spring about about using using the evidence property and determine the same thing that it was possible to do that thank you for mentioning it because there is different use a little bit of different contexts there Dimitri. ✪
Dmitri Zagidulin: So the the tricky thing about reusing the evidence property there is the top-level evidence field is specifically the evidence of the verifiable potential and the VC wonder One data model is a little vague on what evidence is supposed to be for but General consensus is that it's you know what kind of documents or whatever well what kind of supporting evidence was submitted at the time of. ✪
Dmitri Zagidulin: But to do what evidence of the achievements you can just reuse the top level evidence field from the VC data model the achievement itself has to have an Evidence field so it's an easy thing to mix up. ✪
<davidc> David_Chadwick pointed out that the VC evidence field is a set and therefore it can represent the evidence associated with the open badge credential and, as the NGI Atlantic project is doing, evidence related to the authentication of the user
Kerri Lemoie: One thing I missed was recommended and I think would be a good idea as if you have any questions that you'd like to spend about open badges that we may not answer today we have an inch today or you can submit them here do you go to the repository and you click on issues and then you click new issue and all you need to do that for that is a GitHub user account. ✪
Kerri Lemoie: Of them as 3.0 because that helps them figure out that the question is related to this version. ✪
Kerri Lemoie: And then they'll take it up in the working group and discuss it there and let us know how it goes. ✪
Kerri Lemoie: Okay thank you everybody we have a good week and I will see many of you I hope on Wednesdays take off for the plugfest. ✪