 All right, thank you so much. Thank you so much, Candice. As Candice said, my name is Jory Burris, and I'm the VP of Standards here at the Linux Foundation. And I'm joined by my wonderful colleague, Joaquin Prado. Say hello, Joaquin. Hello. So Joaquin and I make a really interesting team, because Joaquin's background is really in that standards and standards administration practice. And he's coming and has been working with the Linux Foundation for a few years now. So really leaning into that open source. Conversely, my background started in open source and then grew into the standard space. And that's kind of a good grounding for why we're going to talk about community spec today. And we thank everyone here for joining us. So one of the first questions that you might be asking, and we don't presume anybody here has any prior experience whatsoever, so we're keeping it simple, is really what is the specification and why and how might it be different from open source where I'm used to working. I like to say that a specification is like a recipe. It is not the cake, it's not the finished product itself, but it's going to tell you how to bake the cake, make the product. It's going to give you all of the information that you need to know what you should do, what you should not do in order to be an implementation of that technology or that idea. So it'll give you information like what do you need to have, what is dependency, what must you have versus what you could have, what you should have, what might be optional and so on. And there's some things just like an open source that make a good specification and make one that easier to implement if you're developing a spec. So things like glossaries, performance criteria and using notes documents, again, to call out what might be more illustrative, more helpful and of course, other information like what's the status of this specification? Is it just something that's in sort of an ideation phase? Is it a draft, a pre-draft? Are there other things that you need to have as dependencies in order to have an implementation of this technology? So think of it like a recipe. So why should open source projects have specifications? Why are they important? Why are they helpful? Why should open source software developers think about standards and specifications? Well, they can do a lot to amplify the work that you have going on. They can really help you define products, improve performance, improve interoperability between your technology and others. You may have a project that relies on an upstream specification and so it's gonna be really helpful or useful for you to get involved or to provide some specification that maybe narrows a gap between your technology and that upstream technology. It can help you further third-party development if you're thinking about this from an ecosystem perspective. And then of course, if you're thinking about doing a new specification project to an existing open source project, that can help you really increase your project's adoption rate, enable other, again, interoperability opportunities and of course, provide an open source license for implementation of your ideas, of your technology beyond source code base. One thing that I think kind of scares open source developers away is that big capital S word standard and it can feel like something more formal, but something that I've been saying recently to open source developers is that the capital S standard is another way of saying an agreement. And a specification of course is strengthened through a standardization process. And if you think about a community standard or community specification that you're building, maybe that's okay for you and your collaborators and maybe close collaborators to work on together and that's sufficient. We're looking for sort of like that process efficiency. But as you kind of go down, I've got the arrow pointing down here and you want to increase the level of agreement that's gonna require more proof. And so you go from something that's like, here's a group of folks who have agreed that a specification should sort of be the standard practice for some purpose to perhaps de facto standard because more and more folks have adopted that, began to implement that and are furthering that to maybe an industry standard because this is something that you want to advance through a consortia, maybe a specialty consortia. And then finally, desure standardization, which means that this is a specification or a standard that you want to get implemented into policy, into law and to regulation. And of course, as that agreement level needs to go up, we require more proof and that's what that whole activity is designed to do. What kinds of things might you standardize? This is another question that we sometimes get. You can standardize pretty much anything is what I've learned, but very commonly in open source, you see ontologies, schemas, programming languages, processes, design patterns, and so on and so forth. A lot of different things can be standardized and benefit from standardization. And just to give you a picture, we've got over 200 standards and specification projects at the Linux Foundation. A lot of people don't know that. They know us for the open source work, but increasingly we're seeing a lot of open source projects that are wanting to develop specifications, which I'm seeing is sort of a move from the looser days of open source software development to maybe a need for a little bit more structure, a little bit more norming on procedure and process for to ensure interoperability. So a lot of projects here, some of the projects that you see here are on the community spec. Some of them are on the JDF templates, and some of them are really, really formal. Some of them are just operating using the community spec and that's it. No fund, no extra spice on top of that. So a lot of flexibility, a lot of differentiation represented in this group. So as I mentioned, the Joint Development Foundation has a couple of different ways in which we support project collaborations and there's two that are sort of variations on the theme. Today we're gonna talk about the community specification, which is more focused to the open source developer and the community who is looking to do more collaborative development work and an open source style of workflow in GitHub or GitLab or some Git based on process. They are probably, this could be for you if you are interested in that sort of and have that familiarity with that sort of open source software development process. Conversely, we also have the traditional standards projects which are based on some wonderful templates and agreements that have been battle tested and allow you to spin up a legal entity very easily and quickly and operate in a more sort of what we would call traditional way of developing a standard which some of you may or may not be familiar with if you've worked in other consortia. So the JDF and community spec options really try to provide the right balance of an effort and structure and process. A friend who calls this sort of like meeting the process efficiency curve and I think that's a really good way of putting it in order to get the quality, the agreement, the depth of work in that you need to meet the standard of quality for it like a publicly available specification which is really kind of a level that we'd love to see all of our projects meet. Obviously, you could do something really simple as Joaquin says, it's best efforts. You got two friends and a cat and you come together to agree on a process. Well, you do that however you're gonna do it. On the flip side, farther side you extreme you might have a more de jure process which is gonna require more time, more oversight, more procedure that a whole thing is sort of elongated and community specification is really a tool that we have developed to again meet that right balance of process and of structure and effort while also keeping things agile and friendly to open source communities that wanna move at the pace of innovation which is kind of what we have been kind of describing this. This is a tool, the community specification license and framework are a tool to help you move faster on a specification project while also providing you the base set of governance, licensing templates and so on and so forth and also the sort of developer friendly kind of ergonomics for adopting these things so that you can get started quickly. It's going to incorporate terms again patterns that as a developer you might already be really comfortable with but maybe you're not as aware of as in a formal standards standards org. So if you wanna pursue that if you do wanna pursue formal standardization community specification license does give you that foundation you can build from but if you just wanna move quickly and get some stuff started this is a great way to start. Another question that we get a lot is why is there a need for a special license? Why can't I just use MIT or Apache 2 for my specification project? The simple answer is that open source software licenses we're not designed with this idea of capturing patent licenses as a matter of practice. In a specification project you're dealing with multiple types of IP and development of a specification is really different from developing code. Sometimes there are situations where you can use an open source license in your specification project but in general you want to think about being very explicit and using a more appropriate license so that you're covering all the kinds of intellectual property commitments that your contributors might be making to your project. So this extends to implementations beyond your source code and that is a really critical point. So to introduce you to community spec.dev if you head over there that's gonna redirect you to our GitHub repository and you can start to go poke around there we'll be adding some other features to that site and new resources and documentation as we go but easy enough to remember community spec.dev or you can start the repo. But this is a repo that's gonna get you started with all the core information and process that your spec project is gonna need to start to define the scope and the purpose of your work together on the spec project help you define the IPR commitments for your contributors and for your implementers the requirements for implementers that governments and process in terms of decision-making in terms of how your specification will advance in terms of what your exclusion period and public notice workflows are and we've also included in there a template that you can use to adapt to fit ISO formatting requirements or other formatting requirements again if you want to advance your project to another consortia. So that's in a really quick nutshell is the entry to community specification can hand it over to my colleague Joaquin now to tell you how we, all right, you can get started. So thank you, Jordi. My name is Joaquin Prado I'm a standards community architect here at Linux Foundation and we are going to see now a little bit more details about what we have inside the standards the community license specification. So in the next slide, what we have here is and I need to give you an early warning. In this presentation we have included things that they are not yet in if you go to the current repository but we are building towards that and we thought it was worth it to insert at this point. So one of the things you have is, okay there is a repository and the community specifications to get up account and that repository is called the community specifications very soon we aiming to change a little bit in any other repository to call it to template and the idea is to go to that repository template and click in the use the template and immediately that I will allow you instead of GitHub to copy that template that repository into your specific organization account in this case we call MyOrg and inside of that organization account you name this particular repository as MySpecs as we listed on there but you can have obviously whatever name you want. At that point you have already done the copy of this structure with this legal framework into your repository and now the next step, step three it will be where we are going to see now in more detail some of the documents that we recommend that you should not modify although there is always a step things for everything some of the documents that we call it like an admin documents that you need to fulfill or understand what is the content on there and it's going to give you some of these structure and help you to in the life cycle of your community and the things you are developing but it's more an admin side and then there will be documents that are related more about how to work in group and that it will be the contributing document the organization process document is not yet there but it's something we are trying to bring for you guys in the next release and then obviously at the end of the day the only reason why you are doing this is because you want to build specifications and that will be the side that you go and develop and it will be your technical specifications where you will be creating these documents that you want to share with the industry and we as well advise about to create a release planning that you will see in a moment which is a very light document which is an inspirational document where you communicate to the group that is working on that and exactly what you're planning to do by when so these three simple steps copy into your repository and then customize now in the next slide we are going to look into some of these documents and I mentioned before there are some documents that they are like admins documents if we call it like that and they will be probably the notice and the license documents listed on there the scope it's a little bit tricky it's nothing in a way document but it's a really important one and the reason for that is because the patents they are granted under the community specification process are restricted to the project scope so if there is any patents that have been granted you need to make sure that they're covered within the scope anything outside of the scope you know obviously it's not going to be covered so a scope is a really important document we advise to implement it or fulfill it really early in the process because that will define the scope of the project and therefore the patents will follow into that scope the other two documents they are more pure admin is the notice documents and the license the notice document is it has four sections and that document contains the first one is to provide a contact email for raising code of contact complaints if someone has a problem they need to contact someone so the working group should early in the process to fulfill that section in the say if you have a problem please contact this person and there will be an email address the second thing is to indicate the license licensee accepts the license terms of the project so I see this project I say that's great I really want to incorporate this in my work and I want to communicate that I'm doing that so you submit a pull request against that section in the document notice indicating that you are implementing this particular work a third use of this notice document is to indicate the withdrawal from the working group of any sorry to indicate that you are moving out from the working group this is important as well in some cases where you say okay my company is participating but at this point we want to leave and we are going to make it you know, officially by submitting a pull request against the section of this document and indicating my company is leaving out of today and that will be recorded on there for the group and the other thing is about the community sorry the communicate the exclusion notice remember one thing as soon you take the community specifications you are walking into this more structure framework and one of the things we say here is that we capture the option of the possibility that someone submit a contribution which contains some patents and obviously if they do that the community specifications indicates they are submitting a royalty free license patent but for whatever reason the company decided that was a mistake we need to withdraw that there is a process on how to do it we certainly we don't encourage people to submit something for later to remove it but we are in some kind of structure here and there is a process for doing this kind of things so that is in the notice document that's four important aspect of the administration and another document that we have like any repositories you look into the license document and the license documents in this particular case you are going to find two things one of them is a pointer that takes you back to the community specification license itself and this is the license that you are submitting content to create specifications and the other thing is that if the group decide to create a source code in that case this is where in the case what source code or under what license the source code is going to be contributed and if you don't indicate anything by default it will be under MIT nevertheless it's possible for the group to change that and there will be obviously a consensus on how to do it the other document that we have and this is now you are moving outside of the administrative sites and more on how we work in the community specs like any repository we have a contributing document and this document describes how to contribute the work in that particular repository remember the group potentially can have more than one repository in that case the copy that we did at the beginning where you copy from the template it should happen on all the repositories you want to bring along but what you will have is that in each one of those repositories you may change the way in the way you work you should communicate that to the community say if you are collaborating in this particular repository this is the steps that we follow and something is not captured here but it's coming is that the process document and this is some of best practice and guidelines that you will see by the way in the presentation later where we provide you have advice you can take it or not it's up to you but at least we want to help you to guide you through some of the on how to build specifications so that document eventually we will want to incorporate it into the community specification repository the next slide we are moving now until the I think it's the documents that we do recommend to not modify and you saw a jury presented a slide where you see you know the amount of effort they require us to do our community specifications and there were some boxes stopping each other and this is where we say there are some processes on there that the community specifications is building for you and we pretty much tell you please do not modify as everything in life there are things that could be in some cases for whatever the reasons to be modified and it's the two documents that appear right at the bottom the governance with an asterisk and the code of conduct where maybe some reasons why there has to be some adaptation to that and the best thing is please reach out and we can work with you on that otherwise the documents that we have is the contributor license agreement which is this document basically says as soon you submit a contribution you are doing it under these rules and specifically we are going to see in a moment in the you know at least three documents they are key in say of the community specification framework then we have the community specifications license itself and this is where explain the framework the legal framework for participating and contributing to the development of technical specifications we are going to see some notes on that related with copyright abundance so this is a legal framework that again we recommend don't change it governance is about where we provide some definitions about you know editors or maintainers and so on and it's established it's a very high level that is the reason why we want to bring another document the organization process document where it gives you the granularity of dos and changes as you need and we will give you best practice on top of that and then you have the code of conduct which is the set of values and rules standards and principles outlining for the group on how to work together so those documents as I said we recommend do not modify and then obviously we go into the next slide which is the two documents that is for the group to develop well we had one quick question from Dan Applequist in the Q&A about the code of conduct and so answering this live really quickly some we do provide by default the contributor code of conduct that's what ships with the community specification license we know that some of our projects are affiliated with other open source foundations that may have an existing code of conduct that they would like to extend to this specification project and so that is one example of when you might modify the code of conduct document but the license and the framework require that the code of conduct exists and it requires that contributors a test that they will adhere to that code of conduct so that's that thank you Jory I'm by the way I didn't see the I don't know what there is where but I don't see any questions coming through so now we move into the this is where the experts this is the you are doing all of this because you want to do work to reach out to the community and here is where you develop the technical specifications we give you as well a template you know what is the content should be on there and then we suggest to have a release planning and release planning is a very simple document it's one table really and it's an aspirational plan of what to do and by when is our experience is that when the group is working it's always good to have some kind of vision it's okay we want to achieve these documents or these features by this time and that gives a focus to the group to work forward and and dates and having this in place is always helpful and at the same time when people arrive for the first time they look it's okay I see they are working to these features and they want to release by December so obviously in that case let's go to focus on these topics rather than bring on the topics and then maybe it will be for later on so in the next slide we are going to now dive into well before that we have the community specifications terms and definitions it can be a little bit different from open source and this is one of the things that goes into the governance document and here what we have is the definition of working group which is basically everyone is participating plus the repository you know all you put together that is the working group if you have only one repository your working group is restricted to participants and a particular repository if you have more in that case that this one could be even multiple working groups or even sub-working groups the flexibility is there participants very clear is anyone as well as contributing to the working group activities and that this community license specific sorry the community specification license remember is set up the framework for that editor as is listed on this the persons we could be more than one they are responsible for ensuring that the content of the documents accurately reflects the decisions they have been made by the group and that the specifications adhere to the formatting and content of the guidelines so we provide the guidelines the editor should be familiar with that and nevertheless there is a fair amount of flexibility on things there or there and then the maintainer if you look into an standards organization the maintainer normally is called the chair here we call the maintainer and is this person is responsible for organizing activities around developing and maintaining and updating the specifications the developed by the group and is responsible for determining for determining the consensus and coordinating any appeals consensus is something that we put a lot of emphasis in standards unanimous consensus and we are going to see that in a moment it doesn't necessarily mean that everyone agree what it means unanimous consensus is that everyone has voice their views and the group now understand and move forward and they waste waste on how to do that so I see that there's a question on there how common is there to be multiple maintainers it depends I think it depends on the group Jody if you want to I would say that I typically see like two to three and you know again in a standards org this might be a chair and a co-chair or a couple of co-chairs in the open source world we do typically see maintainer groups that are one to three as sort of the most common and you can do that here crucially and realize it's not necessarily reflected well in this the participants are the ones who select the maintainers and select the editors so really the decision making really sits with participants maintainers and editors are persons called out with special additional duties maybe because it's something they have more time for something they have a little bit more experience with or expertise in but yeah not uncommon to see multiple people in these roles and our recommendation is normally have at least two maintainers if one cannot be there in that case the other one replace and in the editors it depends on the documents that you are editing but it's important as well that even if there are multiple editors they can with some kind of a same approach on how to do things otherwise you are going to be reading the specifications and you are going to see different sections written in a different format and that is something that we should try to avoid but yeah it depends very much on the group on how many people volunteer because that is one of the things like open source this is a member's this driven by the members and it's a volunteer work no one is obligated to do anything but normally people step forward they want to dedicate more time and have ideas on how to do some of this work so if we go to the next slide what we have now we are going to dive in a little bit I mentioned about some of the documents they are admin documents this is one of them this is the contributor license agreement and this is when you submit a contribution this is the document that binds the working group participants to the legal and governance terms established by the community specifications repository and specifically that document says that when you are submitting a contribution you are doing it under the umbrella and they listed three documents on there the community specification license the governance policy and the code of conduct so that is where we establish that binding it can be as simple as the document that we have on there it could be implemented by having a template in the pull request which each time that pull request is created you will see listed this sentence on there it could be a CLA bot you know there are these options that are open and available but the simple one is that you have a document telling you that anything you submit into that repository is binding by these terms so if we go to the next slide now we go into the community specifications license here is where we will be talking about the IP policy you know we are talking about the copyright and the patents and we will see in a moment so the document itself it covers the legal framework for participation and contribution to the development of technical material this is where you establish that legal framework that we mentioned about the community specifications this license is not intended for source code development has been already pointed by Jory you know source codes tend to be more about I grant copyrighted patents to my contribution but here you have a concept that has to come together and that document can be implemented later in different languages and different formats and the source code covers only one particular you know contribution for one particular language here is different and then the other thing as well in that document sorry yeah we jump into the community license sorry yeah I was about to say that if there is if the work is developing any code in that case here is where you need to insert as well what it will be your license for software code if you don't indicate anything it's going to be done on the MIT but the options are there for always using all the open source licenses if we move to the next slide now we are inside of the community specifications license and we are going to focus what means from the point of view the contributor when they go and contribute a document a full request with a contribution towards the rest of the community or to everyone and it means here that the contributor is granting a royalty free copyright license on each contribution to everyone and at the same time is retaining the attribution of this contribution so here is where we establish the legal framework specifically for the copyright in the next slide is about the patent licenses and this is always very tricky when people get this it really gets nervous about patent license and the things we need to say here is we are in a frame legal framework we need to establish things correctly so this is not for you to submit something and then 45 days later retrieve it back this is to say this community specifications has a framework on how to handle this and the things we say is we discourage to anyone to submit something which and the certain patent and later they say oh no I'm going to withdraw it because the system allows me to do it yeah the system allows you to do it because we want to make sure that if there is any error or anything it is a way to do it but it's not encouraged to do submit something too later to remove it and I would like to bring your attention they have I don't even if I can read myself right on the bottom of the diagram is say the contributor it grants to the licenses a royalty free license to each necessary claims in the contribution and this could be in a print draft in a draft or in a specifications that is going to be approved and here when we try to indicate is that the contributor it has up to 45 days to withdraw that particular royalty free license patent in case something happened and it's legally you can do it in the print draft and draft and before it's being approved you cannot do it in a specification that has been approved by the group and if you do that bear in mind that the group is going to be really upset because probably what they're going to do is this okay you are you insert this content here now you're ready to withdraw the patent so let's go to carpet that round and that is no really good practice that you want to have in the group so is assisting on there in case for every company to be aware of that it is assisting on how to withdraw in this case any patent but is encouraged not to use it and I see that we have a question what if the specs are coming out of collaborative real-time working sessions that happen via zoom or perhaps probably in a working document somewhere where the editor is recording details from the conversation that's a great question jr so community specification was really designed for the framework of we're doing the bulk of our work in github and we expect that the people who are participating in this project are coming to the github repository and participating there so we're capturing their input be it in a pull request or you know some other sort of you know they solve the waffle board thing issues and so on and so forth if your group is doing more of its work outside of github in more of a what we would say like is a traditional kind of meeting driven development or of a specification or document driven development of a specification via like word docs and so on then this may not be the right tool for you to capture but it's going to come down to kind of what your group is doing how you like to work and what is the easiest way for you to assure that your maintainers editors and participants are tested to the license requirements as they do that work and the other thing to indicate is it could be a lot of conversations outside we always recommend to submit presentations and make it available to the group so everyone can see even after the meeting what was presented and they can go back and at the same time at the end you have to build specifications you have to build something that people can agree and elaborate and that is the tracking that we recommend obviously to do through github and that is where we establish all the systems in place a lot of discussion can happen outside but at the end of the day what is submitted is what it counts so if we go to the next slide what we have here is now the scope and remember that I mentioned that this is a really important document people in the groups they forget about it no actually no because that is where based on your scope you are defining what is going to be any patents is going to be granted in base of that scope and that is the things you want if the scope at the same time if you make it very white in that case those patents is going to be granted in a very wide scope and a lot of companies they don't like that if you make it very very narrow and in that case you can start doing things they follow out of the scope so it's important always to keep in mind the scope and as I say on there because the patents are granted according with that and the other thing is that the any changes to the scope are not retroactive so keep that in mind if you do any changes later it doesn't necessarily mean that everything was applied at the time it's on the same scope that's something that you have to be careful so scope is an important document that is the one I mentioned is an admin document but pay attention because it can be important in long run so the next slide we have procedures and best practices so this is something that you are not going to find in the current community specification repository this is something that you are going to see here that we would like to give you as a guidelines the group can take it evolve it or they can say okay I get it but we are going to follow something different it's based on best practice so we know that it works and this provides a structure and and help the group to move forward so let's go to the next first one it will be about the document hierarchy remember you're working to community specifications we have light structure but it's still there and this what is telling you is that you have to be careful there are different type of documents there are documents there are policy documents normally established by the governance body is this is the ones we recommend do not touch and you can see some of them on the right hand side then there are other documents that are technical sorry process documents they are the group has the ability to evolve in the way they want this is the one we call the organization process document is not in the current in the current repository but we are planning to bring it forward and then you have the procedures documents with the is done at the level of the working group on some working group and this the date to the activities and that is where you have the contributing guidelines telling you how to contribute to this particular repository that document is under the control of that particular group release planning is an aspirational thing with what we want to achieve by when is under the group and they the group they can define their own guidelines and best practice as they need and in the next slides we are going to show you some of these best practice so the next one it's going to be about i think is the the specification development phases and everyone say oh god here we are process process process actually i this is something that people it does even when they don't realize they're doing it at the beginning you define the scope of what you want to do you go into the development we really advise that once you can't you say this work is complete we say please review it give yourself sometimes to read everything you have written test everything you have done before you formally approve at that point of approval is when the group they say we have complete the work that we target ourselves to complete by this time and then after that they say okay now we have this group did this work is agreed by the group let's go to rubber stamp by the organization so that is where we put the binding with the legal framework where we say now the organization is going to formally publish this content agreed by the group and if we put it outside for the for the community to take and it's at that point where you can expect some feedback from the community in order to do the next release or some back backs fixes that you need to address now call out to Joaquin because i think this public feedback pieces is really valuable to to point out that again because this work is happening in github which is generally speaking a very open environment we really encourage that it allows you to get potentially more you know participants and contributors into maybe you learn about new use cases new requirements that you didn't think of before but this public nature of the community spec is a big advantage yeah that's correct it is very important if you're building something you want to get the feedback out of the community you know is any things that is open for interpretation you do not want that in the specifications because you want interoperability therefore you want to make sure that everyone is understanding in the same way or they say hey now you develop this why you don't go into this you're missing this aspect that I think is important for us is a pain point and that is the feedback you can use to create the next release so if we go to the next slide now we dive into detail and this is just an overview you saw at the beginning the work item and then the publication and this is just in between this is the area where we say the development and our recommendation here for the standards in general you have right on the top where you can see the lines going the requirements which is business requirements not technical requirements at this point the architecture where you define the different components with interfaces that are going to be into those components they can be logical components they can be physical components it's up to you and then there will be the technical specifications and you can see the effort that we indicate you know that it's a good practice is that you dedicate an effort between 10 to 20 percent to develop your use cases requirements and you know you can add an architecture which another five percent it doesn't take more than that a lot of groups they spend a huge amount of time in building requirements and architecture and in reality where you are defining all of this in the technical specifications this is the area where you need to dedicate most of the time and even considering as well if you're going to do something that you may need to test it so testing is something that you have to incorporate as well on those specifications so this is no a waterfall approach it can be very dynamic as well you can see that the faces they can move forward and backwards and it gives you an indication of where you should spend the time and the bottom line it gives you a world of milestones remember about the release planning when i say an aspirational things that we want to build you know it could be the final release by this date but we want to build the requirements by this date the technical specifications by this date so that is where we tell you some of the milestones that are typically in the standards organizations and now if we move to the next slide this is the approval review and approval process this is really important and let me see if i can summarize is that when i say before that in standards we standards is is looking for unanimous consensus it doesn't necessarily mean that everyone agree it means that we heard the voice of everyone and this system we put on there is very simple it's a way to ensure that the voice of everyone is heard and at the same time give to those voices the option to say i submit a comment versus i submit an objection so the process is follow it will be something like this someone goes and submit a pull request in this case it goes for discussion the pull request when you look at that it's okay this is an editorial thing this is nothing you know controversial here the editors they can take that and immediately it can be merged but if the pull request contain a new feature and something that no one has seen before and it could be a little bit controversial the group in that case at a point needs to say well let's go to put this document and the review and that's due to the policy of the group to decide five days seven days whatever they want and people goes and review the document and submit comments so the comments is something you say well i think that they should be this and the other thing they should be in this way but someone say oh my god we go in the wrong direction here this is an objection guys we should not do this and he or they or she put an objection on that document now an objection means that because that is saying on there that document cannot be merged or that pull request as a result of consensus for example the group say let's go to put five days on this document and we receive three okays and it's no objections is received is merged gone but an objection is being presented now that document or that particular contribution cannot be merged and now what is going is the next and the next time the group needs to go and to discuss that and here is where they say okay in my end i put the objection i say no no no this is going in the wrong direction i disagree with it i presented to the group and i explained it and now the group will say okay we hear you Joaquin but we don't agree with you and it seems to be you the only one that is having that thought and i can say at this point well actually i'm sustain my objection and at that point the group the only way to resolve this is to go for a vote and the resolution of the vote is the one is the unanimous consensus even if i disagree even if i am the only person and disagree in that case that is the the will of the group and otherwise it can be merged by the group and i see that we are already final in the time so if we go to the next slide i think we are this is where we mentioned about the CLA we have the option to just mention it in a document we have the option to insert it in a pull request template or we have the options to bring the votes as you can see on there there are two CLA and EC-CLA both and the next is sorry yeah i was just going to say i wanted to just say that the LF some CLA EC-CLA but also is sort of more of a for those who are working for more of that control does collect actually DACU signed signatures against that so we did have a question of on on the CLA attestation how we collect that we can do that and actually get a digital signature and then if you've got this bot turned on your repository we can also report out to you and your maintainer group who has signed that which is sometimes a very useful piece of functionality for the for the maintainers and editors sorry and the next slide is that this is highly recommended semantic versioning is that anything is approved by the group allocate those x y z x means a major chain minor chain after mean after major change it will be for example the first release is 1 to 0 the next release is an enhancement and it's compatible it will be 1.1 if you have a backfix it will be for example 1.0 it's 1.0.1 it's important because that indicates to the industry how is developing your specifications and i think that it was the last slide the next one is just about the wrap up yeah which actually i think goes well to dan apple quest question that i just said would answer live about that easy path you know we kind of went into some detail that maybe if you're new to this as maybe more detail than than you necessarily need at this point in time but if you're ready to get started and you want to you've got you know a simple specification that you you want to try out under this method step one good take a look at the community specification license and look at that with your your project leaders make sure it makes sense to you make sure the the definitions of working group participant editor maintainer of the specification advancement process that we outline all i'll make sense to you ask us of course if you have any questions but then go copy those documents into your project repository and get to work there's again some additional tooling and things that you can add in like the the cl a bot for example you need to go take a pass at updating your scope make sure everybody's on the same page about what your project is and is not going to do and get to work start meeting start collaborating online and and developing your your spec where you do your work so that's that's the hopefully quick quick story on on that and of course if you want to get more feedback on other types of tools we have lots of resources here for you at the linux foundation as well um yeah i see so there's getting lots of good questions here in the last minute um the uh contributor certificate versus uh per using a pr versus in place of the cl a bot okay one thing we should have said um maybe to just ground this is um you know we are not here to provide legal advice to you we are not not your lawyers uh and so on and so forth so with that that being said um the answer here is about in my mind um friction for your project versus concern over risk mitigation and what kind of um a testament you really need in order to accomplish the goal that you have so uh is Joaquin mentioned we provide that cl a contributor agreement in the repository and that may be sufficient for you um you could go a step further and you can say we're going to have a pull request template and we're going to ask you to open a pr uh that attest to that language via pull requests and add you to a participants dot md file which is something that a lot of open source projects like to keep is that sort of list of participants um if you want a little bit more then uh you could add a github's cl a bot which is more like a click-through type of agreement um that's certainly sufficient in the sense that it gets you a list of people by github account that have agreed to those terms for some lawyers that's not quite enough and they like to see a science document and that's where the the beefy easy cl a tool might be what you need because it actually collects a signature it collects a signature from either a corporate contributor from somebody who is authorized to find the company and can authorize people to contribute on behalf of the company and then we can provide some reporting out to you so just you know it's a scale of comfort with what you need and what you want uh let's see last question or another question um if i've got a spec that is already being developed and they're an open source software license like mit can i migrate to the community specification license and the answer to that is yes um so as what kin mentioned the contributor um or sorry the community specification license provides mit for the source code license by default um so this is a the community spec license is a is a is a license that gives the contributors more rights and so that's generally you know seen as a good thing um if you're just kind of getting started and you are developing say some example source code along with your specification um it's a it's it's a fairly easy task to go and to those contributors and get the alignment that you might need which is generally really easy to get because this is a pretty um easy to adopt license quite frankly get their agreement and then migrate into the csl because it's it's as much as possible we've tried to match the way developers like to do work on their software but do it in you know work on a specification instead um so we've done this a couple times and not yet had any challenges um oh my goodness we've just we've had flowed through time any last questions i guess i should put this slide up really quick because we're already at the top of the great okay well um i want to say thank you to um everyone for attending today we really appreciate you coming to our first webinar from the standard scene we're planning to do more content like this and i'd really love to hear from you if there is material resources support info anything that would help you as an open source developer get more involved with the standards project or start your own standards project please reach out to us admin at jointdevelopment.org or you can check out the joint development website um and that will also link you to us um and uh we yeah love to love to hear more from you and any any challenges you see in implementing this we will be more than you know willing to hear from that and and see how we can help and improve things that we have at the moment all right canis thanks uh back to you thanks so much thank you so much jury and what came for your time today and thank you everyone for joining us which is 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