 Welcome everyone. We're delighted to welcome you to this Jenkins online meetup. I'm Mark Waite and the Jenkins project is delighted to host a session today with Liam Newman presenting for us the Jenkins Enhancement Proposal Process, JEP. So we're going to host this session through Hangouts on Air. We're delighted to have you with us. Questions can be asked through the internet relay chat system. Please use the Jenkins CI channel and talk with us, prefix your text with J-O-M. We're glad to have you here. Liam, how about you take us off? Let's talk about JEP. Cool. Oh yeah, and usually I'm the one doing the hostings. It's a little weird for me, but I'll do my best today. Oh, and you can find the information for how to get to IRC if you don't know how already in the description of the video down below. So anyways, thank you Mark. Well, it's morning for me. Hello everyone. I'm going to talk today about the Jenkins Enhancement Proposal Process and how we will improve Jenkins together. If I can get my presentation, there it is. I'm Liam Newman. I'm Bitwise Man on Twitter, Bitwise Man on GitHub, and also you can find me on Gmail. I'm a Jenkins technical evangelist at CloudBees. Jenkins contributor, CI, CD advocate. I'm a JEP editor and a co-sponsor actually of JEP 1 along with R. Tyler. And we'll find out what those last two mean in just a minute as we go through this presentation. What we'll do today is we're going to talk about this new process called the Jenkins Enhancement Proposal Process. It's nine, ten months old now. It took us a while to get it off the ground and get through some early errations. And we'll go over what it is, why it was created, who should use it, how it works, when to use it, when not to use it, and where to get more information. The things that we won't cover in this talk is really like an in-depth discussion of all the details of JEP and the JEP process. It's not super complex. We'll easily make it through the overview in this hour. But there are some corner cases and some things that you'll want to know that you'll need to go and actually read the JEP description, the specification document about it so that you can get a sense of those things. But I think by the time we're done here, everyone will have a good overview of how this works. In-depth burst, I'll define some roles and terms and should go pretty smoothly, I think. So first, of course, what is JEP? JEP is the Jenkins Enhancement... A JEP, when we speak of A JEP, we're speaking of a Jenkins Enhancement Proposal, which is a design document that describes any aspect or new feature related to Jenkins. So it'll describe the motivation for the change, proposes a new feature, describes the motivation for it, and provides an overall specification that's sufficiently detailed for anyone reading it to have a good understanding of how the new guideline or process or feature works. It collects community input on an issue and also discusses the reasoning behind design choices. Now, it's really not intended to replace things like email discussions or anything else. It's more meant to give people an overview. And then the JEP process, when we talk about the JEP process as a whole, it's the process by which JEPs are created, submitted, reviewed, finalized, and then maintained once they're done. And actually, the JEP process is the first JEP. It's JEP 1. So the first JEP that we did, we used the JEP process to create that JEP. And the point of this is to have one agreed-upon process for proposing major new features, collecting community input, and documenting the design decisions that have gone into Jenkins. The JEP process is based on the Python PEP process pretty heavily. The imitation is the sincerest form of flattery, right? So thank you to Python for their work there. And I want to mention right now, the process as a whole is generally consensus-driven. When we talk about consensus, what we mean is general agreement. There's a lot of information you can get on consensus decision-making. Wikipedia, I went up there and grabbed their description for this. The key items, the key characteristics of consensus-driven decision-making are that it's agreement-seeking, that we're looking to find an overall agreement of the people participating. It's collaborative. Participants are... Everyone contributes. Everyone gets in and shares the load of making the decision. It's not a voting or a debate. It's not a one-way process. It's not Fight Club. It's, hey, let's all get together and work together on this. It's egalitarian. Everyone's voice is heard and given even weight in terms of, okay, let's evaluate what you've said and work together towards this. It's inclusive. And it believes that basically as many stakeholders as possible should be involved in consensus, and that will produce a better result. And it's participatory, which is to say that everyone... Not only does everyone contribute, but also everyone is invited to contribute. Please come, exactly. So as I said, the main characteristics of the JEP process are that it's consensus-driven. It's intended to happen in tandem with implementation. It's very agile-friendly. You could do it as waterfall, but it works just as well in an agile model. In fact, it works, I would say better, because you start doing the JEP and then you... and the implementation, they sort of work in tandem. It's opt-in. You don't have to use it. If you are just working on your own plugin or working on your own part that you don't really want to invite others to be part of, you don't have to use it. And the idea is that it produces clear and understandable, bite-sized design documents and gives us a consistent process for doing that. So having said that the process is consensus-driven, we do have at least an out. We have what's called a benevolent dictator for life, BDFL. We just shorten it to that because it's a note. I don't want to say that all the time. And that person is the one that acts as the trusted decision-maker when a unilateral decision is needed. So as a JEP is going through certain parts of the process, the BDFL will review JEPs or designate others to review JEPs. And they resolve any disputes or arguments. Obviously, we're trying not to have those, but if that's what happens, they can be asked to take action to resolve those. Any disputes that can't be resolved through consensus. And finally, they also refrain from using that power as much as possible and leave it to the community to manage themselves. So Liam, if there's something that is so controversial that it needs resolution by the BDFL, are there common examples of that? Things that I assume controversy is okay. It's okay for us to disagree with each other. Are there places where you've seen that happen, where the BDFL had to get involved and say, no, we're doing this or that? I have seen one where the BDFL actually, he was acting as a reviewer though. So I wouldn't say that we've actually run into a dispute where people were at such disagreement that a BDFL level decision had to be made. In the case that I'm thinking of, Koski was the reviewer on the JEP that I'm thinking of, and what he did was he said, okay, this is what needs to happen. But that would have been something that anyone, even any reviewer of that JEP, if there had been a BDFL delegate that was reviewing it. So I guess that's the level of choice, yeah. So we've had a few, but they haven't been as extreme as like, we just can't agree. It was more like, well, we're not quite finding a good path here. Please point us in the right direction. Thank you. Yeah. So let me talk for a minute about the parts of a JEP. There's a required set of the design of the JEP, specifies that we should have a minimum set of, a certain set of sections that you have to have. There's, I think, 10 of them overall. But I don't want to spend too much time on the details of that, but let me give you at least a few highlights. The JEP will include an abstract, which is like the elevator pitch for the new feature or process. It'll include a specification, which says, here's how the thing works. Here's all the details. Here's the APIs that we've implemented. Here's the, or describes the process that it's being proposed. It says how it's going to work. Maybe have a rollout plan if that's needed, that kind of thing. There'll be a motivation section, which will talk about the why, why is this needed, how are things before this JEP was proposed, where what are we trying to solve, all of that. And it'll also have a reasoning section, which is where we'll document the design choices that were made, but generally what the why of the specification or the other reasons, or the other design choices that were considered, but rejected. So it takes a little bit of practice to kind of figure out where certain different information goes. But that minimum set actually is, once you get the hang of it, it's pretty clear. There's other, sorry, what? Liam, does the, then motivation describes sort of the positive sense, this is why we're doing it, and reasoning is the things which we've evaluated and decided not to do, or the further support on why we did it this way? Yeah, exactly. It's just general. So the point here is that when someone reads the specification, they should be able to read it as, this is what we're doing. This is, this is, bam, there it is. I don't have to, we're not going to, I'm not going to, if I'm reading the specification section, I'm reading what is actually in the design and nothing else, right? If I am reading the specification, I go, huh, why'd they do that? I'd go down to the reasoning section, and that would be most likely where I'd find. Yeah, so when we decided to, for example, if it was the green balls plug-in, it's like the reason we decided to make the green, the balls green is because we also, you know, that we considered other colors, we considered allowing people to choose, you know, set their own color, but that was out of scope, that kind of thing, right? Oh, yeah, speaking of the green balls plug-in, let me go back. And so like if we use that as the example, the abstract would say, you know, this plug-in changes the color of a successful build indicator from blue to green, that's your abstract, boom. Specification for green balls would actually be pretty short, but you could have more information about how it does it or, you know, what it, but it would, for example, might say this plug-in uses the standard Jenkins plug-in APIs to change the color of a successful build indicator from blue to green, it uses this color of green, it, you know, et cetera, it would sort of lay out what it does. And the motivation, for example, would be many Jenkins users do not feel blue as a strong enough indicator of success, right? That would be, so we chose to make a green balls plug-in. That would be an example of these four sections, and then there's other sections that include backward compatibility, how backward compatibility is going to be handled, any infrastructure changes, how testing's performed, security considerations, and then links to the prototype implementation as it's happening, if that's happening in parallel with or later on, and then also references which would point to any discussions that happen, that happened in email or on other channels and that people can go. So the reasoning would not actually include like all of the, you know, discussion threads from email. Those would be linked to and references. But perhaps some sort of summary of like, okay, here's what we considered and here's why we chose to go the way we did would go into the reasoning. Thank you. Yeah. Oh, and finally, all of this is actually also covered in a template that we've made. So when you go to CreatorJap, you can go and grab the template and edit from there and the template actually also includes instructions on what goes in what section. So why, Jeff, why are we adding process to a project is not what I would prefer to do, but where we came from, where Jenkins started, we had changes driven by a small number of, you know, small independent groups of individuals that we had no formal process. If you look back in Jenkins history, design documents are pretty rare. And when people have come in to the Jenkins user mailing list or IRC or even on or the JIRA or any of the other ways that you interact with the project and they're like, okay, so I'd like to contribute to this area or I'm interested in this or I use this and I want to help. How do I, you know, where do I find the design information? The responses often read this epic PR thread and that's how we designed it or read the code or read this email or read this JIRA thread or read all of these and then you'll know what we did and why we did it. And that can be really daunting, right? When you get into this area, it also means that it's hard to see what's being worked on and generally this means there's a high barrier to understanding and participation. So JEP takes us into the future. It takes us into the size of the project that Jenkins has become. It gives us a clear, as I said earlier, clear understandable and bite-sized design documents. It gives us a consistent process that we went through the same consensus-driven process to create this process. And so we've gathered a lot of information. There's a lot of things mentioned in the reasoning section of JEP 1 about, okay, we considered this, we thought about that, but here's how we went with this. And generally it's open and inclusive and gives us less chaos and more productivity and it will let us have larger groups of people work together including larger organizations be able to come in and say when we have groups of people or a larger organization say, well, how can we participate? We can say, well, here's how you can propose changes and interact with the community and come in and work through processes with us. We have an index of all of the JEPs at that URL and that's kept up to date as we make changes and that gives us the list of the JEPs and then their status and who's responsible for them. So the question then is who should use this? Anyone. Anyone and everyone, actually. Anyone can contribute. We encourage everyone to contribute. Be part of the discussions and also anyone with a new idea for Jenkins, anyone with a new idea for improving Jenkins can say, hey, I'd like to participate in this process and come in and work through it. Which brings us to the question of when do you do it and when don't you do it? Generally speaking, so far what I've seen people say is basically if someone, there'll be a discussion going on on the mailing list at this point, generally the developer mailing list and people will say, eventually at a certain way through there's been some discussion back and forth and someone will go, we probably need a JEP for this which is fantastic for every time someone says yes. That's exactly right. Basically when an issue is complex or broad enough that it requires collaborating and consensus building and basically if you feel like you or a future you might appreciate a design document that's when you'll need a JEP. Simple or small changes, not so much. You don't need a JEP for, hey, I've found a bug in this thing, I want to fix it. Go ahead and do that. Anything that you would perform in the normal development process, just a single PR generally doesn't need a JEP but basically it's when you start getting beyond just your own area, you want to bring more people in or make sure that you're working in a consensus way, that's what you do. Of course, do I have to create a JEP? No, but these days for any feature or idea of significant size, it's worth considering at least. Thanks. Liam, Tyler makes a good point in the IRC that the JEP and NodeJEP simple and small changes might in fact mean a small change across many places and that probably justifies a JEP. For me, the boundary, I think as you're describing, if it's inside one plug-in, it's probably not worth a JEP but as soon as it starts touching multiple people or multiple places or multiple plug-ins it may be time to, that's a good time to consider is this a Jenkins enhancement proposal topic? You know, I'm not sure there actually because, I mean, so for example, we have the Jenkins configuration as code plug-in which is a single plug-in, however it affects a lot of plug-ins so that would meet your bar that you're suggesting. I would say though that you could have one plug-in that you decided, hey, I want to make this plug-in, I want to support Kubernetes and Jenkins. No, that's not going to do that. That's too big. I want to support my particular testing framework within Jenkins, let's say. And if you wanted to just work on that on your own and you weren't worried about whether or not you were going to collaborate with other people in the Jenkins project, then yeah, you wouldn't need a JEP. But if you were, hey, I've got this testing framework I want to implement for, but I want to make sure that I'm doing it in a design, the design I'm using is good and agreed upon for Jenkins and also I'd like collaborators to kind of help me with it or I want to bring other people in. It's basically when you want to bring more than more people in to work on it and collaborate. Good. So there's one that Jesse Glick just raised in the Internet Relay Chat system about the use UTF-8 for pipeline build logs JEP that was proposed. And the question was, should that be, should, is that JEP level thing? And my mind was, hey, something as big as changing character set across things, that was certainly worthy of a JEP. But what's your feeling on it? So this was, the proposal was JEP 206, use UTF-8 for pipeline build logs. Yeah, that would definitely make sense and I'm glad that he did that because in some cases it's a matter of, okay, I think this is the right way to go. There's enough of a change. It might be controversial. There might be some back and forth. And even if there isn't, it means that having done the JEP means that if someone comes in a year from now or whenever and says, why did they do this? Or why did they make this change? They can go back and look at the JEP and someone can say, hey, look at the JEP. And that is the one, it's a design document. It's the one place and they can go and read. Oh yeah, we had this motivation. These discussions occurred. And this is the way that we decided to roll it out. And just basically it's, in that case, I feel like it's due diligence. Okay, I've asked for feedback. I've gathered feedback. I've done the process as we understand it. And made sure to include people. So it's feeling to me like I'm probably currently more biased towards not creating a JEP than I should be. And if I'm feeling that way, probably others have the same pattern that they might consider. If you think, should I or should I not create a JEP? Think very carefully. You probably should create a JEP. I would lean towards yes, but that's my bias, of course. And the final point I'll make on this is, a lot of people, it's very common for people not to want to stop what they're doing and write things down. I'm like, no, I'll just go do it. I'll write the code, it'll be cool. But having the reason why we have this process is to keep everyone on the same page as it were. Thank you. Thanks for that clarity. So finally, having gotten this far, let's talk about how this works. Well, it's basically just a series of states from submitting a JEP. The JEP will become a draft. It'll get reviewed. It'll then be accepted and then finalized. So that, okay, we're done. I'm going. No, mic drop. No. So to start with, you have an idea. Someone has an idea for improving Jenkins. So that's someone, they have an idea for a new feature. And they start by emailing the Jenkins CI dev list and asking the community, hey, I've got this idea. What do you think? From the moment they send that email or even before they can start doing prototyping, beginning implementing stuff. And as they're doing that prototyping and they have the email out to the community, they'll gather some initial feedback. Given some general positive response, they'll move on from there to submitting a JEP. You know, in the process of that, someone will say, ah, you probably want a JEP for this. As part of that initial discussion, you'll need to pick a sponsor for the potential JEP and maybe pick a BDFL delegate, which will be someone who's an expert in the area that this JEP is going to be in, and they'll review the JEP when it reaches a certain level of maturity. So let's talk about sponsor for a second. I've used that term a couple of times now. The sponsor is the leader of a JEP. They are the primary consensus builder. They are responsible for the JEP in Toto and the state of the JEP and that it represents, ensuring that it represents the consensus of the community. The document dissenting opinions, they might coordinate contributors' work and they ensure that it's in the right style, has good quality, and they'll maintain the JEP after it's finalized. If there's any tweaks or edits or changes later on, they'll be the ones to do that. They're not necessarily the primary implementer of the feature in question. You can be the sponsor and write no code. You can be the sponsor and also not really write the JEP. The majority of the JEP could be written by other contributors. The sponsor would be more like the program manager, kind of person to make sure that everything is moving as smoothly as possible and that everyone's voice is being heard and documented and included. So from that early discussion and early implementation, someone said, hey, you should put up a JEP for this. So the sponsor will now submit that JEP. They'll create a JEP document. It'll be an ASCII doc, the template, as I mentioned. That JEP will link to supporting documentation discussion. It'll link to the prototype implementation. If there is implementation, it's going to be done there. And then they will submit that JEP for approval as draft by the JEP editors. The key thing to keep in mind here, this is an initial conformance check. It's not a design review. So when you put this up, you may feel like, oh, this is something that you want to do early. So that, okay, here it is. Here's the basic structure. Here's the overall early design choices that we've made and that'll move the JEP into a draft state. This should maybe take one to two days at most. Early discussion could go on for a week or so. I didn't actually mention that in the previous one, my apologies. So, Liam, is the mechanism that transmits this to the JEP editors a pull request to the JEP repository or is it something else? Yeah, it's a pull request. That's right. It's submitted as a pull request. Yeah. And this is really just the, as I said, the submission for approval as draft is the JEP editors will just do an initial conformance check. And actually, I'll talk about that next here. One sec. Hey, come back. There it is. So the JEP editors are a small group. There's five of us right now who administer the process. It's a very, you know, sort of editor. Oh, I'm on an editor. It's the least glamorous job of this process. We're just process administrators for the JEP process. So when someone submits a JEP for approval as draft, we'll check that it has all of the sections in it that, you know, generally it has complete sentences and it has, you know, the right, you know, the right format overall will assign the JEP number to it and we perform other administrative tasks like merging PRs, other people's PRs once they say, hey, yeah, this is good. So that initial submission, we say, okay, here's all that has all the sections. It has a reasonable start to the design and has a sponsor and hopefully a BDFL delegate who will review it later on. And then the JEP, we come in draft. At that point, the JEP sort of goes into a cycle here. The sponsor or contributors will gather feedback, modify their design based on that feedback, record the reasons for the design decisions, record the differing views, you know, if there was controversy of any sort, they'll put that in the reasoning section and they'll modify the implementation to match the design and then repeat that. Just kind of continue that sort of cycle of design, modify, feedback, repeat and so on and so forth. Liam, along this line, Jesse Glick asked in the Internet Relay chat if we need to have a reference implementation, maybe flawed, incomplete, et cetera, to file a draft or can we file a draft even without yet having a reference implementation? Could a draft be filed for something that is still in a conceptual stage and hasn't yet got even a skeleton implementation? So that's a little bit of a controversial question. There are people that are like, we should always have an implementation if there's going to be one, right? Some JEPs don't have implementation. They don't have code written for them. They don't have documents. There's a type of JEP that's informational or just like, hey, here's some information. We wanted to record it. Or there are process JEPs that are, okay, well, here's a new process for doing something. The JEP itself is the implementation. But for JEPs that do have implementation, you don't have to have one, but I would say that if you don't, you definitely need to have more design details sort of figured out to some degree because otherwise the problem is we don't want to have, we would prefer not to have JEPs created for things that, how would you call this? We don't want drive by JEPs. Like, hey, we should do this. Someone runs off. A JEP that is not, that doesn't have any implementation or any or sufficient design details probably would be like a bug. Like you would file that as like, we should do this. Or this is a, you know, that's more of a feature enhancement request and less of a proposal. A proposal in my mind, you would continue to participate in that. And so I would expect there to be at least some degree of energy having been put into, okay, this has enough interest. We're going to like, for example, if there were a discussion and there were five or six people that were like, oh yeah, this is really interesting. I'm really, you know, enthusiastic to work on this. Let's get a JEP going on it. I could be like, I could see how that would work. As an editor, I would not stop that from becoming a draft just because I would probably, as long as someone was like, yes, we haven't started the implementation, but we're going too shortly. Because I just want to make sure that people are involved like in a JEP. And the implementation sort of indicates a level of commitment and effort. Thank you. And Tyler in the Internet Relay Chat system noted as an example that Jenkins Essentials JEP came out initially without an implementation. And so, and then it was used to refine and evolve. So it's not a mandatory. And I think Jesse's got a good point that implementations are good and probably should be generally there, but not a mandatory. Right. Thank you. Okay. Let's repeat. As an editor, I wouldn't, as an editor checking for, checking a submission, I would not, I would not, I would go ahead and approve that. I would approve that, mostly because it still meets the conformance point there. It's like the point of that initial thing is to get to, of reaching draft to begin with is to have enough in there to meet the structures there. That also brings me to the other point here is that JEPs can stay in draft status for as long as necessary. So, and it's more of a description of the overall like state of the, of the JEP and not whether or not people think it's good or important or their enthusiasm about it. It's like, no, the design is still changing. We're going to keep this in draft state until the design levels off. Great. So, prefer to have an implementation not strictly required and you as an editor won't reject it if it's lacking in implementation. The process allows it. Thanks. Yeah. This, I, I, this is a little bit of a, like really do we need this? But yeah, it's important to note that everyone can be a contributor. I've said that before, but it's worth, I wanted to highlight it. Anyone who helps write, implement, discuss or offers feedback about a JEP is contributing to that. And, and everyone is, is encouraged to do so. If someone's looking at a JEP and they're like, oh, this, this, I think this should happen. This should, you know, we should change this design. They might send a mail on, on the dev list or they could just submit a PR directly and then have some discussion there. I, I'm a big fan of go ahead and be the change you want to see in the JEP. Go ahead and make the change, you know, propose the, you know, submit PRs and, and that's how we move forward. That's how people contribute. When the design sort of settles down, when there's enough implementation and enough, enough work has been done on the implementation and the over, the JEP overall to feel that there's no further major changes to be made. That we, that the, all the, the design gotchas and other sort of questions have been resolved. At that point, the sponsor will, and then that, that, that point is up to the sponsor to sort of figure out and keep an eye on and decide. And when the sponsor decides that, they will submit the JEP for review. The, at that point, so the reviewer will verify that the, the JEP meets the criteria for acceptance. This is the, the, a completely different thing than approval is draft. This is the acceptance point, which is they'll, they'll verify that it provides a, and that improvement that it represents the consensus of the community, including documenting, you know, dissenting opinions and, and design choices and how they were made. The, they'll make sure that it clearly defines the scope of the features so that it doesn't like, well, we'll just keep, kind of keep going on the open, open-ended. The, it needs to describe a complete design and, as I said, addresses any major questions. And at that point, the, at this point, at the point of review, the implementation definitely needs to be far enough along to, for the reviewer to look at it and say, yes, I believe this ensures that the design had all, that the major design choices and decisions have been made. And that, I should say, that's, that may take, you know, a week or two for that review, depending on reviewer availability and when they have a chance to look at that. As I said before, a reviewer verifies the, the JEP meets the criteria for acceptance, and a reviewer is just our way of saying BDFL or BDFL delegate, rather than writing out that everywhere. That's, just so that we have a single word for talking about that. And a reviewer, though, can be anyone who has a sufficient technical expertise in the area and that, and a standing in the community for, for someone to say, you know, when the JEP is created, hey, will you be the BDFL, BDFL delegate, will you review this? That, that can be something that other people nominate you for, or if you would like to be the BDFL delegate for something, you can stand up and volunteer. But, so the, the role specifically here is either the BDFL or an assigned delegate from the BDFL. That's good. So that gives, that gives Kosuke the chance to be careful about who is allowed to review and accept JEPs. Exactly. Exactly. It also means that we don't have a single, a single, you know, a bottleneck or single point of failure for reviewing JEPs that, you know, that, that Kosuke can delegate the, the, and choose other people to, you know, paralyze that work. So once the JEP has been reviewed, it is, it will be set to accepted. It will become an accepted JEP. And at that point, there should be no further major design changes. The, the people, the contributors working on, on that proposal will, you know, continue to implement code or add documentation or deploy or do all the other things that are specified in the JEP. But, they're, at that point, we really expect there to be no further changes. At least not major changes to the JEP. And a JEP will remain in accepted state for as long as the implementation continues as long as it isn't the, isn't done. When it's finally done, the sponsor will say, okay, we're done. Please set this to final or active in the case of some JEPs. When all the implementation is complete, all the changes are incorporated and, you know, documented. Some, the JEP will become final. Some JEPs such as the JEP process become active because they're ongoing processes that will continue to use. So, the JEP implementation is really just, you know, are we done or are we doing it, right? And that, of course, that's forever. So, we're done. That's it. Mostly. There's plenty that I haven't covered here. You know, what maintenance has to happen for a JEP, how JEPs might be superseded by newer JEPs. I did mention the three types, but I didn't go into a lot of the details there. The first one comes for JEPs. This is the golden path that I would hope all JEPs follow, but that isn't necessarily the case. We mentioned handling disputes, but we didn't go into any of the details of how that's, you know, how that's done and how that's raised to the BDFL or whatever else. So, there's more detail. There's lots, the document has considerably more detail than what I've talked about here. But, really, it's in the best case, it's as simple as this. Right? So, let's talk for a minute about some examples of current JEPs. We did that a little bit earlier, actually, too, but so JEP 1, the Jenkins Intense 1 proposal process is currently active. This is what we're using. That's what I'm describing. We have also another process JEP that was this JEP 4. It's a special interest groups. It describes how we will go about creating SIGs, special interest groups for the Jenkins project. It's currently in draft form, and Oleg Nino shows has been, but the interesting thing here is it's in draft form, but Oleg is also using it and modifying it as proposed some modifications based on his initial following of, you know, he went through the process that what was proposed and went, oh, yeah, this needs to change this. Even though that's still in draft state, we've started I would say testing that process, right? So, and it continues to be modified and updated right now. I expect that relatively soon it'll probably become active. Oleg's pretty thorough. So let's see. What else? JEP 6. Daniel Beck proposed this. Jenkins CVE numbering authority, which was I believe giving us the ability to number our CVEs on our own rather than having to ask another organization for that information. That was a pretty fast one, actually. Went through in only a few weeks or so. It's currently accepted. I think there's still a few things left to do on it. When Daniel feels that it's done, he'll relatively soon I'm pretty sure it will become final. Let's see what else. JEP 200 this was a huge effort and this is a good example of something that might have been done in one Jira or something and a bunch of email lists. Oleg Naneshev and Jesse Glick, if I remember correctly, were the major contributors to this. This was a switch of our remoting from a black list to a white list. That affected hundreds of plugins and had several months of roll out. A number of blog posts and communications that had to happen in order to communicate to people, hey, we're making this change, it's a breaking change. I'm really pleased with this particular JEP. It was an early JEP, despite the number we can decide which number we want, so we just sort of moved that, that was one that we moved up to its own to start a new number, a new 100 block. This went really, really well and also if you read it, it documents the, you know, why we made these choices, why it was important to do this and also why we went about it the way that we did and also describes, you know, how the roll out plan went and the steps that we went through. It's an interesting read and also a really great example of where this process shines. So Liam, on that one, there are, even now after all the effort that went into JEP 200, there are still occasions where something pops up that needs additional, so a JEP in final does not mean that all work on that has ceased or that everything is done, done, and it will never change again. How does, what's your sense there of how that works? I would say that's similar to when you say that something goes, something has been released and then you have bug fixes, right? So if you have version 1.0 and then you have some bug fixes that you make that, you know, if we, in the case of this JEP, if we were trying to wait until all plugins were no longer affected by it at all, it would never be final, right? We would never be able to be sure. It would just be a gargantuan task. As it was, it was still a very large task and it was more that the roll, what this is talking about is the roll out of that. So the change was released, the it's in core, that implantation has finished, has been finished, and all of the roll out tasks that we had in terms of making sure that the major plugins were major plugin issues were addressed. That is, that it, so how do I say this? It described the scope of the work, the JEP described that JEP described the scope of the work that we would do for that, that effort and that scope of work has been completed, so it's final. If we, if there were another, like, if someone wanted to create another JEP to say, we should fix all of the plugins, for example, that would be another scope, we probably would create another JEP that said, here's the scope of that work, and that JEP might never become final, or might say, we're going to fix the next, you know, 50%, and scope your work to that, and then when that scope was done, you would mark it as final. So as long as the JEP sort of addresses the scope that it sets out to, it can be final. Sorry, in this case, the scope that they chose was large and yet accomplishable, right? So now I see on your list, for instance, JEP 300 for Jenkins Essentials is accepted. How is that evolving if the JEP has been accepted? Because Jenkins Essentials, I don't think has released JEP to the world. Is it evolving through additional JEPs, or through revisions to that JEP itself? So both JEP 201 and JEP 300 are what we've begun to call mission and goals JEPs. It's not an actual type of JEP, but we're using it as a because of the size of the things that we're trying to do, we've found that and we haven't actually changed the JEP process to add a new type. This is just sort of shoehorning it in for the moment. Both of these JEPs are that kind of JEP. What they describe is the overall goal, the high level design and both of those actually JEP 201 is also accepted in the market on here. But both of those describe the high level design and intent of a larger and even larger process or proposal, larger area. So Essentials is a huge effort. It has many, many moving parts. But let's see here. So JEP 201 is Evelina Vilkosz and Nikola Deluz. And Essentials is the sponsor for that is our Tyler. So each of those groups, but they basically figured out was it's better to have that we've reached consensus on this overarching direction and that people can look at that design and say, yeah, this looks like the right way to divide up this work. The overall and how we can, the scope is large enough to see, again, both these describe things with large scopes even, you know, and that we know are going to take a while to do and that we know have enough moving parts that might have, that we want to build consensus around the larger overall direction and then design and then go back and look at the case of both these. JEP 201 is going to probably have two subjects. JEP 300 has six or seven now, at least. And each of those JEPs describe one part of that overall effort and but we've are the point here is that we've sort of reached consensus on this design overall looks right. This high level design looks right. We've also, everyone that's looked at it reviewed it sort of said, yes, this is a good this is what we agree that this is the way to go and then individual parts can be worked, we can work towards consensus on the design of the lower level design of individual parts separately. This is sort of a balancing point of like, okay, so this, in the case of, in both these cases they're big enough that we didn't want to get bogged down in building consensus for the whole thing all at once, right. We wanted to be able to say, okay, here's this here's this big scope but a high level view of it and then we'll build consensus on the design the design details of individual parts separately. Thank you. Jesse has an interesting question on that same line of the 200 slash 300 slash so the ending in 00 numbering scheme for goal or big picture meta-geps we're not doing that retroactively do we intend to continue doing that so 201 is really a bunch of things it will stay as 201 are you in general following the goal process with the 00 endings? No that was just an early so the numbering is completely arbitrary if you wanted to have a particular number as a sponsor you could make that request on the way in if not the editor who's approving the submission will choose a number this was just by convention for the 300s we just knew that Jenkins Essentials was going to be a bigger thing the first item it's not actually emissions and goals so it's not really that that was my choice to put it up higher because I figured there were going to be a number of low level geps like the special interest groups or the CV number that we wanted to put earlier lower numbers to indicate longer lived something it is the numbering is arbitrary so the ones that you've seen here by convention so for example JEP201 didn't start as a mission goal as an overall high level design document JEP it started as okay here's the design boom but there was enough people found there was enough moving parts that we had to we went back and went oh yeah no there's actually other parts of this let's and create a couple more JEPs to get into the details so the numbering is arbitrary and it's really up to people discussing it to decide thank you thanks very much now we're at about five minutes to the close of our time are the crucial things that you wanted to be sure that we talked about in that last five minutes so potential future JEPs your ideas here that's what I wanted to say this is where I would like to see more happen I mean I know that let's hear Andrew Baer is going to be submitting some JEPs for changes to the declarative pipeline syntax and also other new features that are coming down the pipe there the Blue Ocean team has submitted a couple of JEPs for their extensibility API but I'm assuming that they'll have other JEPs other extension points or other changes that they're going to make basically as we go along there's a I didn't mention it there but there's a JEP for Jenkins X so I promise I will submit my JEP for optional automated source formatting that's on my list and Tracy Miranda said earlier today she was prepping her JEP excellent excellent so where do you learn more that's let's see here so further reading there's you can ask questions on the Jenkins CI dev list the Jenkins community IRC lots of friendly folks there take a minute to go read JEP one now that you've seen the overall process hopefully that document will look a little less daunting just read through once large portions of it won't apply to most people but having a sort of an awareness of what the overall structure is is worth it and there's a template that you can use to create your JEPs and the JEP index which gives you a list of the current JEPs in their state and finally Wikipedia of course is always good for getting a lot of information it's worth also taking a minute to sort of read and understand how consensus works especially as sponsors it's important that we try to build community and build that inclusive and positive feeling from everyone and that consensus can bring so that's that's one more thing I would also say and actually before we go to questions I'm going to take just a minute to say if you want to talk to me personally or or mark or any number of other people that I've mentioned come to Jenkins World at DevOps World Jenkins World it'll be in San Francisco September 16th through 19th and then also there'll be one in Nice France on from the 23rd to 25th of this year thanks Liam I think we've we've got a question any other the questions that I've seen in IRC I've been interrupting you as we go along perfect so I don't feel at all guilty I think we've done thank you very much for presenting the Jenkins enhancement proposal to us excellent this feels like it's effective and looking forward to using it all right thanks