 Hello everybody, I'm Seth. Hi everybody, I'm Seth Newberry. I am a consultant to the Linux Foundation for standards. Prior to that I was the executive director of the Joint Development Foundation which was subsequently, excuse me, joined into the Linux Foundation in about 2019 and I spent about three years with the Linux Foundation developing the JDF within the Linux Foundation and just recently I've just taken a consulting role but I am also the person who manages the ISO pass process within the Linux Foundation for JDF. So what the purpose of this is to give you an idea of what the Joint Development Foundation can do for you with regard to preparing the specification for ISO using the pass process. So let me get started with the slides. So first of all there I believe this link is in the chat window but if you want to know a little more about what the pass process is you can go to the JTC1 and pick up standing document number nine at this at this link here which will give you some idea about what JTC1 has as their documentation for the pass process and then also you should feel free to reach out to one of the standards team we've got some contacts on the last slide to be linked to other documents that we have or call us if you'd just like to discuss what submitting your specification to ISO would be like. So first of all let's just because we're good to assume that not everybody here is a pass expert but you know what is a specification and a specification is very simply a technical description of requirements characteristics and features that a product or a system must possess in order to function in an interoperable fashion and a specification is typically developed by a collaboration of companies using a set of procedures that ensure that the specification reflects the technical consensus of the creators of the specifications the companies who are making it. They prevent dominance of any one company so as I say it's a it's a broadly based consensus product and that the specification that results is well documented and creates a work product that's suitable for developers to implement. So that's essentially what we're trying to achieve when we have a specification. The way that the Joint Development Foundation helps in this area is that we are essentially a standards organization in a box which means that we have procedures and structures that allow a specification to start quickly at a very low cost with the advantages of an incorporated entity and a path to standardization and ultimately to international standardization. So we can scale from very small programs to very large format programs within the JDF family. We are a non-profit foundation. We offer pre-made agreements that allow some flexibility kind of through a check the box process for things like for IP modes for open source software and for copyright and so each project can have its own customized work program but within a framework of a standardized procedure. Since we are a past submitter to ISO which I'm going to explain a lot to you in a bit we do have the ability to gain international recognition of our specifications and we've got over 30 projects and we're growing with very broad technology coverage with a really broad base of members. So the Linux Foundation value proposition in all of this and the reason that we brought the Joint Development Foundation and the Linux Foundation is that Linux has a very deep roots in standard setting and we saw real advantages to merging what we were doing with the Joint Development Foundation into the Linux Foundation. So now with a Joint Development Foundation the Linux Foundation has a continual programs that can accommodate the simplest unfunded free standards bodies into very large customized projects and again with the path to international recognition. The other thing that I think is underappreciated but that is one of the most powerful benefits is the Linux Foundation has one of the largest developer communities on the planet. So the developers any specification measures its success by its adoption and developers are the pathway to adoption. So with this very large developer community the Linux Foundation really does offer one of the most comprehensive support communities from concept implementation to adoption. So there are probably thousands is a big one probably hundreds of different specifications to setting organizations around the world. Most of them are focused on a particular technical market or a market vertical and they produce some really good specifications for their specific requirements but it's easy to get lost in the sheer numbers and so here's kind of an example everybody knows what 802.11 is because that's Wi-Fi we all use it it's part of our daily lives we can't live without it. You've never heard of secure user plane simply because it's a set of technologies that allows your mobile phone to understand its position relevant to a cell tower. Now you rely on several but you don't know it's there because it's an ingredient it's like the flour in a cupcake you can't you can't tell it's there but you enjoy the cupcake. So submitting your specification to ISO through the past process is a way to connect to one of the most premier international standards bodies which in turn will allow you to distinguish and elevate your project and oftentimes find uses that you haven't really considered. So the JTC-1 stands for the Joint Technical Committee 1 very catchy name and it is a technical committee of the international organization for standards ISO and the IEC the international electro technical committee commission. It is responsible for developing and maintaining international standards in the range of information technology and so within the Linux Foundation it's a very good fit for us there may be one or two things that we're doing in the Linux Foundation that may not fit in their scope but 99% of our work will. It's composed of 162 national standardization bodies from around the world it meets regularly and it votes on a on proposed standards and those standards that are developed by JTC-1 and transposed in the ISO or IEC canon are used by governments businesses and others to promote interoperability compatibility and security. So JTC-1 is the organization that manages the entire past process and that's why it's important for me to sort of explain that. So the past program is one where standards bodies apply to become authorized submitters and the Joint Development Foundation did that back in 2019 we were accepted. There are about 15 past submitters at JTC-1. A lot of companies you may have heard of Eclipse, Oasis, Chronos Group quite a diverse body of other standard setting bodies are past submitters. JDF absolutely treasures its submitter status so we're pretty careful to ensure that the projects that we send to ISO are of a very high quality and have strong potential for an option. We also at JDF we have a team of people who can provide assistance to your project for past submissions. So I'm one of those people we've got some others. Jory runs the whole show so the the standards team will know what to do if you contact them and say gosh you know I think my my specification is worth is worth looking at. We also act as the interface between the project and JTC-1 simply because ISO is sort of a closed community and so one of the things that happens is they're unfamiliar with lots of different people and there's sort of a standard language that we talk to the man and there's a standard process and it really helps if we're in the middle because it'll tend to go smoother. So let's talk about what a past specification is. So here's where the alphabet suit comes in. So the JTC-1 IEC ISO pass process is essentially a fast track process for development approval and publication of international standards. Now I'm going to show you a chart in this that's going to help you sort of put this into perspective in a couple of slides so there's no quiz on this slide but past stands for publicly available specification and it's the project it's the process of getting an outside specification into the ISO and so our process tends to be quicker than if you developed your specification inside ISO a typical ISO specification will go for two to three years and and so what happens is that we sort of jump into their process with a completed spec near the end of the process but on the other hand too it tends to be used for standards or a little more experimental a little more rapidly evolving but again the specification that JDF puts in let me give an example here Open Chain is one of our programs that uses that has submitted a couple of specifications to the JTC-1 and been accepted and so what happens is the Open Chain which is sort of a supply chain management specification is now in the ISO canon and therefore allows governments and others to use it as part of a public procurement process because the specification has been adopted by ISO. Open Chain still owns the specification through JDF but it now has the authority and gravitas of an ISO specification so when we create an ISO specification or a package for submission to JTC-1 there are three documents essentially that we give them the probably the most important document is the explanatory report so it is it's a questionnaire it's got a series of questions in it that we answer that helps the reviewers at ISO understand what it is they're looking at gives it context it gives it and it gives it information about the specification some of the very important pieces in that questionnaire revolve around adoption nothing nothing says quality like somebody actually using the specification and so their goal is to see if the specifications mature enough and try them out then it works and so when you are considering whether or not to your specification is ready for ISO transposition keep that in mind it's an important question for you and also I'm going to talk to you in a couple of slides here about kind of what you need to think about when you submit or when you decide to submit a specification because once you submit to ISO you actually have a responsibility you create a lot a responsibility on your organization to maintain it the other thing that's really important in the explanatory report is to be fact-based be accurate and be circumspect about your specification these people are not going to be impressed about what you think the potential of your specification is they're going to be impressed with what it's actually done and so you know this is not a place for puffing the product it's a place for really you know kind of giving hardcore facts and making sure that the specification is of high quality the the other piece is the text of the specification itself ISO has very specific editorial standards that really need to be incorporated into your spec so ISO is they are not a github house they are a document oriented sort of word document based what's the word I'm looking for that's how they distribute the specifications and they use a lot of xml tagging and that sort of thing in order to make sure that the document is somewhat accessible but they also have very specific language in for their normative referencing similar to rsc 2119 but they use a slightly different standard so the the the text of your document needs to conform to their their specifications now and and and honestly their style guide is like 200 pages long so we do have people who can help adapt your specification into their format and I would highly recommend you use that simply because it is there are not that many past editors out there and so it's a it's a big job and you should you should let us help you with that and then the final piece is the file of the exhibits and it's simply a folder that can age graphical exhibits and specification because again they use xml tagging so they need to they need to have the specification itself decomposed into the component part so that they can reassemble it in the in in their document format so the the benefits of the of going through all of this are are are pretty significant um the first thing you get if you are a successful pastor there is you get the gravitas of an iso specification um because it is recognized as an iso specification it gets an iso number uh it's on their website uh companies can buy it from iso so they you know it becomes its own specification but the great part is the submitting organization and that in this case this means you uh uh through JDF maintain control of the specification and you're responsible for the updates and new revisions so it's it's um it's it's it's a it's a really valuable benefit to the outside world the other thing that it does is it relieves the project from the relatively ponderous process of creating a specification within iso itself iso as i said has a very long process it's uh it's a big organization with a lot of contributors and so getting something started within iso can be harder uh than it is if it's within a project uh that has a more specific focus uh like the JDF projects do um the specification must be developed under the JDF rules because you know they certified JDF um and they certified our process uh as being capable of creating a well-formed specification uh and so uh you you need to be one of our programs um and then we have several modes within the JDF we have a traditional mode which is a little more um formal and procedural way of putting a specification together and we have a community specification mode uh which is a little less formal uh and a little more community governed um and again you should reach out to Jory for questions about the differences between those but um but either path will get you ultimately provides a route to iso path submission so one of the other big benefits of uh submitting a pass uh document to the iso is that you're going to get a broader audience for your specification or for your technology um it's a much bigger pond um and so Seth I think we lost your audio are you able to hear me Jory can you yeah can you uh signal yeah I'm afraid my AirPods must have died on me here all right can you hear me all right we got you good okay thanks apologies for that um uh you also you can get alignment with international standards and worldwide industry trends they those uh because iso is such a large organization there really are uh an awful lot of other people that you can interact with uh you get the opportunity to shape cooperation between your your project and other international standards bodies and open source communities uh that's very important and the networking opportunities are also very important so um the the benefits really cross over not just technical but into distribution and again as I say the adoption of the standard is is the thing that most determines its success and this gives you a much larger pool of people to talk to and collaborate with in order to drive that adoption so we've got a couple of questions um in chat that I think um would be timely to to um call out from from Leonard here um Leonard was hoping we could dive in a little bit uh into the role of the project and and like the project's leadership in um the isopass process as we for example preparing those um those documents that you mentioned and then also into the updating process for for Paz what uh how how are updates and revisions handled between our projects and the JTC one committee I wonder if you could spend a minute on that sure so the first place is and uh hello Leonard uh um a lot of you will already have pre-existing relationships with iso committees because um you know one of the things we we tend to take a perspective at JDF that a lot of the programs are not deeply involved in the standards business um you know that and so every so often we get a project that is you know which has leadership that is very involved in the standards business and they're already they're already well connected with the iso uh community and so that presents sort of actually an enhanced opportunity I think at one level um because you already have connections you already have contacts and presumably you've already got contacts that are within your own um area of interest um so pardon me um the uh the since the j since the past process is fairly formalized and fairly rigorous what happens and and I'm going to talk about this in just a couple of seconds there's always whenever we send in a document for uh uh as a package for iso approval there's always a socialization process that takes place because iso is inviting us into their house they're they're allowing us to be part of their community uh and um and so we need to be respectful of the fact that they may very well be working on specifications that are similar to ours um and that socialization process uh is one of those things that we try to achieve before we send our package in um so that the uh relevant subcommittees in iso or iso or jgc one can talk to us about what we're doing because if we're doing something that is just you know a micron off of something they're doing that's a conflict that we don't necessarily want to create we want to cooperate we may not want to we may not want to have our own identity um now at the same time um it's an advisory when we socialize it's advisory so we don't have to take their uh um specific advice but we also have to be recognizing that some of the people that are in that delegation are likely to be voting on whether or not to accept the past uh submission that we send them so that's one of the things to consider uh so i'm not sure if i've answered Leonard's question on that piece i'm going to move on to his other question which is updating and the answer is that um you you you must update your specification or at least re-ballot your specification every five years uh uh if it's a pass submission you are also able to do you know updates uh on a fairly regular basis um so as you advance yours from a version one to a version two and you want to take it up to pass you can do that now you have to recognize that the the pass process itself is six months long and so you don't want to be you don't want five revisions in the six months that you're that you're sending something while it's being balloted so you want to be a little thoughtful about your release schedule versus the uh the pass schedule um and i'm going to talk about that in a little more in detail in the future uh uh but hopefully i've answered the question all right i'm gonna i'm gonna keep going here because this is excuse me uh kind of illustrative of what uh you know what the benefits are for us so for us the pass process is efficient so what i'm showing you here on this slide is it actually came from iso we were in a we were in a jgc one training uh program and i just hijacked this slide from them which is this is the typical life cycle of an iso standard it starts with a new project that works its way into a working draft and that working draft gets reiterated and reiterated and reiterated you know probably 10 plus times in its life cycle and then it moves on to what they call a committee draft which is where the whole committee is pretty happy that the product that they've created is ready to go and that usually takes two or three cycles uh for the committee draft to get done and then at that point they move on to the draft international specification which is the dis box and then on to the final draft final draft initial specification which i think is interesting final draft but that's what they call it so that is that is iso's path forward for when we when we come in with a spec what we will have done is sort of in the red box to the lower left the number one we prepare a new specification and prepare it for pass uh then we format the spec and prepare the prepare the uh uh dis ballot doc for packaging and then we submit it to jtc one under the past transposition process and then usually there's about an eight-week period uh where iso puts the document into their format and then it goes into the a dis ballot um a draft international spec ballot and there it goes it sits for about three months where it's um balloted by the um 162 members now typically about 30 members will vote on it um but that's that's what happens after about three months and then if it's accepted um it comes back to us uh and oftentimes there are comments that are on the on the on the draft and if there are comments on the draft if they are what we call informative meaning they're more they're more um editorial comments but they don't they're not normative which means they don't affect the uh uh operation of the specification they're not they're not technically significant then we'll make those informative comment edits uh if we think those are appropriate and they'll catch things like heading errors and spelling and and punctuation and that sort of thing and then we resubmit that final draft uh to uh to uh for for final transposition uh and and that takes a month or two where they put it into their format and then it outcomes a an iso specification now if we decide that we wanted to incorporate some of their comments that were normative that did affect the specification what you would essentially do is you would restart at item number four here and you would push it back through the balancing process so you can sort of see why you want to manage you want to send something that is fairly mature in your mind because that you know you've got eight weeks plus three months plus another probably two months um so you've got a fairly long cycle and you and if if you're not you're not going to be able to keep the iso draft up to the same level as your own draft if you have a lot of revisions going on internally now the fact is is that you can continue to do that because you're going to publish your draft on your website and that is going to be the um sort of the most current normative version of your specification uh but it will not have the iso improviser on it uh until you resubmit it um excuse me so as i mentioned earlier with the past process um iso iec is inviting non iso member participants to submit what could be potentially competing specifications into their their ecosystem and we want to be respectful of that invitation as i mentioned there's a socialization project with the jtc one and iso committees normally uh the jtc one provides us a what we call a past mentor so in the same way that i become your interface to pass their past mentor becomes the interface to me uh and so we have a we have a past mentor assigned to us uh he will help us find the right committees that might have relevant uh content that is uh relevant to us and and we'll set up a series of calls with that committee and just tell them what we're doing and they'll tell us what they're doing and and and we we sort of make sure that we're at least familiar with one another so that when our when our uh specification comes into the uh uh into pass they're they're expecting it they understand that they've got some context um uh and again this avoids overlap and minor differences between similar specifications because there is no benefit of having two things that are so closely aligned but that are different different specification numbers uh we also just we're always respectful of the guidance we get from the committees uh recognizing that again their committee members may be voting on the whether or not to approve our spec uh but we don't have to modify our spec uh we've had occasions where they uh wanted to change the approach we were using for security and open chain and we just respectfully said no that's that would that would be too much of a difference for from us and we were happy with our approach and that was and that was ultimately approved so uh we don't have to modify the specifications based on their feedback but you might want to consider it. Other thing I want to challenge everybody too because sometimes people get very excited about the idea of doing this but ask yourself why um it's important that you know why you want to turn your specification into an ISO spec um because you know a lot of specifications can be uh very successful without it and um you know the time and effort that you spend making an ISO specification may be better suited building a community around your own um know what you're going to do with that specification once it's accepted at ISO you know and what you're going to do with the ISO version of the specification once it's accepted because this does create a long-term responsibility for your project you need to curate the specification you need to make sure it remains current within ISO and you need to maintain it within ISO uh and so your you will if in five years you um disband uh there's nobody to maintain that specification within ISO and I'll be honest with you I'm not quite sure what happens if we don't renew it after the five-year period uh I've never asked that question um um you also want to make sure your specification is fairly stable as I mentioned before this is a six to nine month journey and it consumes a fair amount of JTC1 and JTC and JDF resources to do it and yours so you know you want to avoid sending revisions while version one is still being valid so you you want to make sure that your work program has enough distance between major releases uh that your that the that the version one is going to be useful once it's approved in ISO because if it's completely deprecated you kind of um you're not using the process to its full advantage um also one of these you want to make sure you re-ballot every five years so you want to like I say you want to keep your local version in step with the ISO version in the interim uh and again plan for a journey this is a journey not an event um so you you want to make sure that you're uh that you're committed to the journey also being an ISO spec does not automatically bring adoption it should it could I've given you all the reasons why it can but again that's a that also that adoption is going to come with interaction with ISO so you also want to have some uh resource dedicated to talking with the ISO uh community from time to time just to find out what's changing in their environment where where your specification is relevant uh and uh continuing to use that community to help uh bolster your your specification and again just ask yourself a question would I be better off taking the same time effort and resource to build a user community to innovate and adopt rather than to go to ISO so ask yourself hard questions before you come in going a little faster than I expected here but uh so a couple of criteria that we we look for for success first of all make sure this is a meaningful specification um and um I mean obviously I don't think you'd be wasting your time on something that wasn't meaningful but you know kind of look at it from the larger international community and make sure it's meaningful to them um ensure that you think that there is broad application outside of your specific community so uh it you should send in something that's got broad adoption potential um you're really you know that's your primary goal of going to ISO is adoption and so make sure that you're you know if you've got a very narrow community it may not be your best move um make sure it's well written and complete uh adhere to the ISO editorial standards uh which we can help you we can help you do um before you get into the process um you really should and I would almost say must have several implementations as proof of usefulness uh and quality uh there are some exceptions to this we've seen but um and and some specifications are uh they're kind of recommended best practice specifications and those work pretty well too but make sure that you've got some some proof that this is a worthwhile specification uh pay attention to the existing standards don't don't write something that already exists um and be ready to engage and work with others on similar specifications within the ISO community as I say this is kind of a benefit uh and then take the time I see sometimes I see programs where they're really anxious to go but they aren't quite ready it's just isn't the you know the the fruit is not ripe yet take time to do a good job get as big a community as you can to uh contribute to it uh standards move slowly and that's a feature that's not a bug and so you you you want it you want to have consensus you want to have a broad user community you want to have a broad contributor community when you go in and then listen to your jdf support team and your past mentor because what will happen is that we will put you in direct contact with the past mentor but we're just going to help make sure that all the all the connection points are working so let me tell you how we can help uh first of all make sure your program is working under the jdf banner uh you know the jdf is the submitter so that's an important feature uh let jdf look at your program and your specification to help you make sure that we think it meets the standards for pass uh we can provide you some good advice here pardon me and uh you know bring us in early it it never hurts to get a little advice and then come back six months later uh work with our editors to get a suitable and compliant draft for submission unless you have actually written a standard for iso uh it's a good idea to use our our folks uh the the the the iso editorial standards i think are only written are only taught at hogwart school of magic and there are very few of them of the editors floating around and uh we you know we've got access to some so uh let us help you there um we'll help you manage the process of getting the specification through their process uh we will connect with our contacts inside and let them know what's coming and and and keep track of it uh we'll track the progress of the balloting although i'll tell you once it goes in for balloting it's a black box we can't see inside that and we don't know until the balloting ends but we'll keep track of the dates and and and and so forth and help you um and uh and we'll keep track of the dates when you need to resubmit so what you ought to be ready for uh as a project is the following put aside some time and money for the project it's not free uh uh if you've got so we've got some projects that go in and there are short specifications maybe 20 pages long and those are not too expensive for us to convert and we've also um submitted the spdx uh specification which is about 150 pages long and that obviously takes a lot more effort and a lot more money um so page count specification quality will drive the editorial time and expense um also you're going to have to devote some of your technical leads uh to the project because they'll need to write the explanatory report they'll need to review the submission documents and they'll probably be important inside the um uh activities we do in socialization um uh we'll we'll we'll we'll guide you but but you know we're not technical experts we rely on you for that uh also your technical leads will be important in the process of the um uh socializing uh that in turn can lead to really important uh collaboration opportunities and so you should look at that as an opportunity not just as a sort of requirement uh and um again we'll help you set up those meetings the process is going to take six to nine months to complete so you need some patience uh but I think that if you sort of follow what we've sort of set here at least you have an idea of what's coming I'm going to come to my last slide so you know putting your specification uh into the uh into into past can be a way to distinguish your project and make it easier for governments and others to adopt it uh becoming an ISO IEC specification is a long-term responsibility and you you need to be ready to respect that long-term commitment you can use the opportunity to develop a network of your specification in other SDOs and that's important too uh make sure it's right for your project not every specification needs it and rely on your JDF team to help you succeed and we're happy to do it so with that I've sort of reached the end of my uh prepared remarks uh I just want to point out the context here Jory Burson our VP of standards and this is her email and then Seth Newberry uh I'm at joineddevelopment.org and I will also be happy to um meet with you and talk to you about all this Seth we've got some great questions um in the chat and and I want to uh take a minute to answer those live um so Leonard has a follow-up question sort of related to the project's ability to participate and lead here um can the technical lead of the project be the editor for um a JTC1 specification um and what what level of uh leadership can the project have when the JDF is is helping to um process their application um I think you need to split that into when you talk about leadership there's two kinds of leadership I think that you're referring to um we're kind of the process lead we help you get it we we help you get it through the machine um um kind of we're your tax accountants here and we're going to help you get through the IRS audit you're the one who's got to explain to the IRS what you did though so as your your technical leadership is going to be incredibly important and again depending on what your project is like and who you are uh you're you're likely to already have some connections uh inside ISO that will make uh make you the uh important lead however from a process point of view we we like to maintain kind of a single point of contact for the administrative stuff when does it go in what are the documents that went in we want to make sure that we have the canonical copies uh because if you submit oh yeah we should have you know you're right we've got a wrong number in this particular paragraph then your version and our version will be out of sync and so we like to maintain that integrity uh from a process point of view but when it comes to talking to the technical leads when it comes to explaining what it's about that is entirely on the um shoulders of the technical leads in the project or two when it comes to editing the document itself and we've made references I think a couple of times to our our our spec editing team Rex Jasky is doing a session for us on Thursday specifically on preparing your specification to meet ISO's very stringent requirements for their format and Rex is somebody we work with if that does happen to be something that you already have a skill set in which um is a rare find but if you have those skills you're of course welcome to prepare your own yeah I I think that is true uh we've never crossed that we've never seen that example uh and I do think there's a certain amount of quality control we would want so if you were if you have done it before and you know the and you know the the secret handshakes uh we would still probably want to do a review to make sure that we didn't see anything that was out of line but uh we would then you know but that that would not necessarily create an expense for you if you if you already have the editorial skills we scroll back here and make sure I didn't miss any we had a couple from um uh Leonard and then um also from Anna on some specifics around the editorial um asking about templates and things like that that may be provided by the JDF um which of course we're very happy to provide to our projects that are um at that point um and I think more of the editorial questions um would be answered in our Thursday webinar um are there other questions from the group on the PAS submission process however yeah I think you you mentioned something there about you know what do the templates look like so one of the things that's uh the JDF does is we give you some very rough templates but honestly the final template that comes out that is your specification we tend not to be uh uh highly directive there simply because depending on what your project is trying to achieve it may have different kinds of requirements as to what they want the ultimate product to look like uh but again we can help you with what those uh what those templates should look like um but a lot of our a lot of our programs uh sort of use their own templates from their own their own history or from their own uh particular um needs but ultimately the process in pounding it into an ISO specification it will look like an ISO specification and have all the sort of right headers and and the right syntax and so forth and that's part of what that final transposition step does for the projects and and um and that can take um you know anywhere from a month as Seth said to you know several months depending on how um how backed up um you know the team the team at ISO are on on that um we'd had a question about the number of um I think this was the question the number of projects that we've had go through um this process and at that but I don't know Seth if you want to answer that for us we've had um two from open chain one from spdx and one from green software foundation and um both one of the open chain specifications and one of and the green software um specification were both validated this year and are in the transposition phase um so they should be out this this fall um our spdx spec um is up for reballoting next year I believe I don't think we're quite that not quite that far along it's five year so I don't I don't I have to you know I have to go back to my my table and find out yeah I was going to say I think I looked at the calendar and we're another benefit of working through the jdf team um as a kind of as Seth kind of put it management process management perspective we do put these dates on a calendar and can help the project maintain the deadlines and the um process and the milestones even as folks may dip into or out of your project because they've been moved on to other things so we're we're here to also help make sure that if there are key deadlines like reballoting and that sort of thing uh that your project doesn't miss it okay other questions before we wrap I think we're at the the 50 minute mark have you got that both of the you and I see like 40 in the chat so um if we've got them all that's great oh uh we had just one last question it looks like from um from Anna have we had any submissions rejected or have we had any problems with our submissions so far we have not had any rejected um and uh I I think uh uh we've not had any problems so far um because a lot of our projects are sort of open source projects it's a little bit of a culture shift for them and so sometimes we have to explain ourselves but so far we've not had not had issues I think to maybe expand on that a little bit I think perhaps because so much of the work that our projects do exists in public github repositories and may have already a number of um related open source implementations or plugins or things that sit around it it bolsters the evidence that we have implementations of the specification that we have contributors that we have use and adoption and that is always well received uh evidence so um I think there's not really been anything that we haven't been able to solve with with a with dialogue um and and that sort of thing and also the past communities tends to be growing kind of in our direction so Eclipse recently became a new pass uh submitter Oasis which has a lot of open source kinds of projects as a past submitter uh Kronos has some open source implementations that they've submitted so there's um I think there's a trend emerging okay I don't see um I believe all submissions have been specifications on open source code to clarify yes we submit specifications not not open source code bases um but but uh again the availability of an open source code base that is itself an implementation or an extension of a specification is is uh beneficial evidence I think that's it for questions that looks like um yeah thank you Seth well I hope this was useful uh please reach out to us if you are interested in going further thank you so much Seth and Jory for your time today and thank you everyone for joining us just a quick reminder that this recording will be up on the Linux Foundation's YouTube page later today we hope you join us for future webinars have a wonderful day