 Alright, welcome everyone. This is the Jenkins Enhancement Proposal Office Hours. I'm Liam Newman. We have Koske with us as well, Mark Waite, Sam Van Oort, and Tracy Miranda. We will have some other people join as we go along. Alright, so the agenda that I have for this meeting at this point is introductions. I have a topic to just sort of float past people around adding new permission groups for the JEPP process. If anyone has any process questions, we can do a quick status on of print JEPPs. If there's anything you want to go over there. Anyone else have anything they wanted on this? So I may have some questions related to an office hours topic. So where I want some coaching on the optional automatic Java source formatting Jenkins Enhancement Proposal. I have some logistical questions, I think, and I wanted to kind of get some clarification on which venue for particular kinds of discussion around feature implementations. Right, okay. Any questions about the process or... We'll get to it then. You're formulating, okay. I think the more important one is kind of a little bit more clarification on which kind of content goes in JEPP versus JIRA versus Code Reviews. Yeah, that's good. Yeah, that's a good one for me. That's good guidance for me feeling completely inexperienced. I could use some guidance along those lines to see if I'm overstepping in the current technique I'm using. So I'm looking forward to the answer to Sam's question as well. Okay, cool. Great. So let's do a quick status of the PRs and the JEPPs that we have going right now. They're open. So we have a few PRs here. There's a... Let's see here. So the first one here is a submission for draft. Both of these are around configuration as code. The first one I know is in a good state. I just need to actually, as editor, do the process of assigning it a JEPP number now that we have a sponsor added to it as Evelina. So I just haven't done that yet. The other configuration is code, JEPP. I need to get Nikola to kind of jump in and make sure that he's... What he feels that state is in and get that moved forward. Oleg has this platform SIG JEPP, which he wanted it held open for the moment since he's still thinking that there will need to be a JEPP for the platform SIG separate from just the creation of the SIG. I'm not sure why yet, but he asked for it. He's concerned where there I think was that the SIG JEPP has not yet entered draft state, has it? It's in draft. It's not accepted yet. Oh, it's not accepted. So, okay. It was a state-related issue to that JEPP. Yeah. There was a question around whether or not we can use a JEPP before it's in an accepted state, and the answer is yes. It just means that we have to be aware that we will have to continue to update our process and keep things in sync with that JEPP as it moves until it... And if it changes before it hits while it's still in draft state. And then also he had his... I think the other... So he filed a couple of JEPPs there and we closed one out as like, no, we don't need it. The other one, the platform one here, we're keeping open because I believe he has some things that he thinks that that JEPP may have some additional process around it that he once documented. So, I hadn't gotten to the last three JEPPs here in terms of looking at them. I believe they're all submissions for draft state. I think they're all by Oleg as well. No, one's by Jesse. And I'm assuming for the GSOC budgeting, Koska, you're going to be the... You're... They were not going to delegate that to somebody else or should we? Yeah, that's... Yeah, that's my intent. Okay, cool. Then I will... That's... I can just note that here. And Liam, could you put into the queue of questions after you've finished that, put into the queue of questions on the agenda, BDFL delegate request process? Do I recommend a BDFL delegate or does that come in the process? Yeah. Yeah, I'd like to ask about that too. Yeah. Because I'm happy to recommend delegate. I'd be an excellent delegate, Koska. I'd be happy to approve my own Jenkins enhancement proposal. I'm more than happy to do that. Yeah, we need a process for cases where someone who would be a delegate would be a delegate for their own proposal. We need, like, a counter-delegate. No, in this case, in my case, we don't. Maybe in yours, Sam, but in my case, I'm actually not a credible BDFL delegate. There's actually... Just to make sure, there are a lot of cases where I have no trouble assigning a sponsor and then delegate be the same person. Okay. Yeah, there can be. I personally worry about that just because coming from a test background, I always like to have someone else to be the checks and balances person, but it's not required. I agree with Liam. While it might be legitimate in some cases, I would not want to be my own approver for my own stuff. I need someone to keep me honest, basically. I have a write-up bar in the earlier conversations in which I explain why that is. So back then, there was this... Someone suggested that I should... That in itself should be captured somewhere. So I guess for these questions and perspectives, I think, that's forming that point that it should be extracted and captured. Right. I guess I could rephrase that as... I guess the process would involve feedback anyway. So as long as it's got someone else approving it just like a code review, that's probably okay in terms of things. Okay. I'm just going to comment this so I know going forward... Let's see what else. This external logging API plugin was submitted by Oleg, but it has a bunch of comments and it needs an update. Let's see here. Yeah. It needs a motivation section. There's been some back and forth around the structure. Oleg has been questioning certain parts of the structure and how it would be different. But for now, that's the structure we have. So I'm going back and making sure that that happens. And this was... I haven't even had a chance to look at this yet. There was some questions. Actually, Sam, from you, I think about whether or not this should be a JAP or back and forth. So this will be part of that. We can use this as an example. Yeah. That's kind of where some of those questions are coming from, I think. From your... Yeah. And I think it's one that I'm probably end up reviewing one way or another, whether it's a JAP or a PR. Right. Exactly. Let's see. I'm thinking if we have any other status updates. We don't have any other sponsors here to actually make requests for things to be moved forward or to be reviewed for acceptance or anything else. And that usually will happen via email anyways. And so I think we're good to move on to the other discussions that we might have. Yeah. Yep. So I don't think we need to go over all the JAPs all the time. There's no other sponsors here that had questions. So I wanted to bring them up with you in person. So I think we're good to just move on to general discussion here. One of the things that I'm making after looking at this kind of suite in the Vistis, I see people picking the BDF delegates. Sponsors picking the BDF delegates on their own. In general, I need that. I think I need to avoid that. I need that to be avoided, I guess. It's true that I think there's like a 300 series in which the whole area, we're actually in accepting 300. I made the explicit statement that I expected the future area of this to land in Tyler. Right. So that's the one that I'm okay with. But the, for example, the 202. And I felt like I was not, I didn't explicitly pick that person. And then he was actually not the 202, 207. 207 he said to me, delegate it to the JC, but that's not how I want. Okay. Yeah. I was sort of short cutting that and I probably shouldn't. So looking at the list of delegates right now, that's part of kind of what I was about to bring up, but around sort of having a, not necessarily a list of delegates, but that would also be part of this. I guess we just need to take it as we do that. Maybe I'm not going to add to that. I got the BDSL delegate selection clarification. I think I can, I think explaining how I'm using this, I think hopefully make some of this clear. I got a running understanding I can capture. It's like a blanket delegation. Right. Right. Right. Okay. Yeah. So of course, okay. Just for my clarity, then I, it would be, it's not desirable that the person's sponsoring the, the, the JEP actually recommends who should be the BDFL delegate. That's truly something that is in your domain. You'll assign a BDFL delegate. That sounds great to me. Yeah. That's the intent. Yeah. Okay. The JEP itself says that either the BDFL will assign one or that a BDFL delegate will volunteer and then the BDFL will agree. That's the process. So maybe what I can do is, oh, here we go. So what I have is this, like assigned here, I'll put proposed after that for the cases where it hasn't been approved by Koska yet. Okay. That will make sense because then that way we can, that way the sponsor can suggest someone and we can have someone other than Koska sort of be the sort of de facto like, okay, yeah, we're thinking this is who it'll be, but then we'll, then Koska will actually make the final call. Does that sound good? Sorry. Yeah. Sound good. I need to pause and step aside for a few minutes. Okay. Cool. Or not. Or not. So I will, so let's see here. Put this over here. Note that. So coming back around for just a minute. I've been doing a lot of the JEP editor work and also with the structure of the way that we've set up the, there we go, the settings on this GitHub repo. And the only editors and owners can merge pull requests. And I, that's been kind of a weird stopper in terms of sort of a drag on things. So I am, what I've done is created a couple other groups for JEP sponsors and JEP BDFL delegates that they also have the ability to write to the database. And this way they can, so the main, the only problem with this is it means that any sponsor could merge any pull request. We don't have a way of controlling which sponsor merges to which one. Same with the BDFL delegates. I think having that is better than having the bottleneck of the JEP editors and mostly me doing the merging. I don't know if anyone has any thoughts on that, if there are concerns. Why not make it that the BDFL delegates can merge? And not the sponsors. Yeah, because the sponsors may or may not be a delegate as well. That's true. But the intent was that since sponsors are responsible for the content of their JEP, then, but I think even, yeah, just having the reviewer be able to do it would make sense. You'd make a good point. But I could go either way. Like if we want to reduce the barrier to changes that would also make sense. Okay, go ahead. Just one general kind of perspective I want to slant on everyone is I think we, I don't, I don't, I think we need to be careful of the level of formalities and like the process performance that we need to aim for, right? This is, I don't think we need to like, we need to control precisely control. Like every aspect of the details. So, you know, it's just, we have, I think we can assume that there's a certain level of trust within the people involved in these things. So that's, that's always my kind of guiding principle. Assume best intentions, sure. Yeah, yeah. So I think they are currently a lot more functional than let's say, like a US Congress. So there are things where people are like a deeply disagree and there's like a mistrust and so on. Then those like a processes really like is the only thing that holds things together. So you need a very strong, robust things that we just don't even in the face of disagreement. But I think we are not, we are different. And we're also shooting for consensus, which means it should be pretty clear when, when we reach that. I mean, that's, it should be pretty part of it is intended to be like, it's obvious. We've all kind of agreed. We're all good. Great. Let's go. We have other priorities that the US Congress doesn't seem to have, which is to get, you know, get the stuff done like in the least effort and like frictions and stuff like that. Yeah, we're not following Robert's rules of order and whatever else. Yeah, that's all. Thanks. Yeah. So yeah. Okay. So I'll, I'll do both. I'm going to keep them as two separate groups just because that way we're, we're also kind of clear on the list of who's been a delegate and who's been a sponsor. And yeah, we can go from there. I'll send this, I'll update this and send it out as a to the list. There's nothing in the in JEP one about who can and can't merge. So I don't think this is a something that we have to specify. It's not a change to JEP one. It's just like, we can let the, let this be part of the process and, and move forward. Okay. Cool. As long as people are cool with that. So logistical questions. The first one was, so Sam, questions about what goes where. And I think you were saying that the Jesse's poll request was an example of this. Well, I, I, I think I was unclear on this point. We'll put it this way. And the answers there kind of raised the point a little bit more and made me realize that I thought things worked a certain way. And I realized that those have never actually been defined. So I guess if I could phrase this as a question, the question is when a JEP, when a JIRA, or when, when should we just be discussing within a poll request, basically. And I think I'm probably not the only one who's had that question. It doesn't need to be like a hard to fast set of specific rules, we're aiming for a lightweight process. But just some, some thoughts about when to use each. Well, okay. So I can, I'll start this from my perspective, I guess, which is that JIRA is good for bugs, obviously. Like if you have like, oh, something went wrong, I'm going to fix it. No problem. If you have an enhancement, people make a request in there. I think the point that I've had problems with is when the, when you end up with a sort of a long string of people going back and forth with design discussion. And there is sort of a, like four or five different, at least, at least two different perspectives, maybe three. And there's no point at which the thing in the JIRA says, hey, this is our current, there's no, like, description at the top that says, here's the current design. So I don't have to go digging through all of the discussion to find it, right? That would be one point where I'd be like, you know, there should be a JEP for this because what you need is a current state snapshot picture kind of thing that stays up to date, right? Again, a PR, I've seen a bunch of the declarative pipeline PRs go really long with people going, I want this, I want that, I want the other thing, right? So, yeah. So my take, and I think, I think I'm not saying the same thing as you, I don't think I'm going to say anything inconsistent is what you just said. I guess, I can think, like, really, I think it's sort of up to people driving the airport to find whatever media that's productive to engage other people, whoever they think they need to engage, right? And then that's that's really you, you know, up to the person, and then like we trust part of the trust is like, we trust your ability to be sensitively picked the right one. Like we should know, we expect you to know that the JIRA is tracking bugs. So like, and I haven't seen, by and large, I haven't seen people fail to pick the right one. The only anti example that I'm sort of consciously trying to instill in people's mind is something I've seen some cases where the two requests that actually brought the future implementations resulted in discussions around the exit criteria of the future, the design questions and discussion about the design itself. Those are a symptom in my mind that the some of the earlier phases of the conversation didn't happen. And this conversation happening to date. And then that's in my mind a part of the big motivation for bringing Jeff is so that we can encourage people to have those conversations earlier on before code like the significant effort gets invested in writing code. So, yeah, so that's, that's the if you can avoid that one example, I mean, I'd be feeling great. And then one last point is, in part because these conversations happen in lots of different places, in part because the nature of the conversations and the participants and stakeholders are different. And what the in Jeff we tried to link to where this conversation happened right so that the people can find and trace the reasoning and how they unfold it. So that's also in order to help you pick the right media. So, you know, you're so that's how I feel. So that I think clear helps clarify a lot in terms of like if there's going to be a prolonged discussion and you need a single source of truth. It sounds like a JEP is the way to go and that makes a lot of sense. I'm, I'm still trying to figure out what we could do. So I think that's a that's a really good point and I'm trying to figure out there's a way tooling wise that we could help support that for after sort of after the fact questions about a particular JEP like could we use to get hub issues then within the JEP repo or something like what would be a good way for kind of belated design discussions or someone like wanders through and ask, Hey, so could you explain a little bit more about X with this jet? Like is there so could you could you give a an example of that I'm so let's suppose I I'll take an example. Let's suppose that the Google Summer of Code Kafka promoting implementation became a JEP. That's an example of something really clever and really cool. And that would be like perfect material for a JEP because of what it is. It's a big feature. It's novel. It requires some design discussion potentially. So if someone if we, you know, put up a JEP for that and then it got merged. What would be the suggested path for then following up with questions like to be open and get hub issue to be treat that as normal JIRA ticket? Because I think that's like I'd like to keep that as close as we can to the JEP basically because that way the author of the JEP can kind of help with those kinds of questions or can think about what they might need to amend. Like if they need to specify something a little bit more for example. Right. So your questions around. It's more like mechanics like like thoughts about like how do we, I think that's probably not an issue yet but that's something that kind of on my mind because I have some things that I'd like to make JEPs for that definitely will need more than one round of back and forth probably. Well, so the first point. The a JEP when you merge the first time that's that's the submission as draft and then approval is draft. Then it's a draft and the way that I have been directing people to go is you have a question. Like if you have just a straight up question that goes in the email list like you start that question. And then someone needs to go and update the JEP with with the result of that question right. And that's submitting a PR if you have an opinion if you're like hey and I actually prefer it this way if you're like hey I think it should be like this does this look right. That's you create the you can actually just create a PR that that suggests the change that you think should happen and then have the discussion around that makes a lot of sense. So when you say that the email list you're talking about the Jenkins developers list. Right exactly or whatever the list is that that's specified for that JEP. Generally the dev list yes. I think the hard thing for a lot of people is getting getting comfortable with not making comments or asking questions but actually putting in the extra sort of the trade off sort of time. If you're to sort of say I think it should look like this right. Or to make some proposed modification right. That that takes a little bit of a different perspective right, but I think it actually works faster that way. Okay. Yeah, I think the part of the I don't think it changes in terms of hide where you engage the conversation. I think what hopefully helps is like you know who is the the actual person that like you cannot you cannot share. Ultimately that's that provides a backdrop. Like in a right email to dev list not really knowing like not getting any response and not really knowing like okay so what does that mean. And then I need to change the sponsor and like to be the effect that I expect you know the people the actual person you can go to. Yeah. That's I have other questions but yeah I shouldn't ask all of the questions. You know that's it's good to have them that's that's the way to go. So let's for the moment. I mean is it around this or is there a new topic here questions on other kind of details about how to work this out. How to work the system here and how to make things. Well that's part of what this is for so propose a PR changes. Yeah. Okay. The next thing we have them list was BDFL delegate selection and how we go about it. So what we were talking about before was that you know, I think the BDFLs can can volunteer but I think that that we I just short cut at the last for the only one that actually short cut it was this last one. And it that just means I need to need to make sure that I'm putting proposed on there and then you can make the agreement that that happens. That lets us sort of decouple you being around and wanting and having time to review them from people going. Okay. Yes. So maybe since you know, I think for you to understand the the criteria and the thinking behind to the media is very important. So maybe we can talk about that. No, anyway, so, you know, one of so I think the one of the I know some people see the BDFLs almost like a code review the three, you know, like just a second pair of the eyeballs. But that's actually not the way I like, I intend to use this. You know, I expect those like additional eyeballs to come from the other people that see the part of consensus that the law that the BDFL brings to me is a more way of adding a little bit of halo to the person who's like, I'm propping up as a little person to own specific areas. Right. So that because in community, you know, those communities like Jenkins this sort of de facto expertise and authority and ownership in the area happens very, very implicitly. So unless you are already in the know, you didn't know that they'll like this, for example, the sort of de facto leader of the morning. And then in part, this is to do that. And then in part by keep designating the same person for the specific area I'm trying to ensure some level of the consistency. And then this person that can I expect that the BDFL delegate to bring in the other stakeholders other experts in that area. Right. Right. In this case of Jeff T07. The way I'm sort of the I'm putting this effort is external build login thing. Mentally putting under the broader umbrella of the cloud native Jenkins changes. And to me, the person to ensure consistency is like a two to I asked the person to expect to drive the consensus in that area is Carlos. So I expect him to be I intend to nominate him as a BDFL delegate. And the part of my expectation to Carlos is that he should know better that the Jesse is one of the experts. Right. So he should I expect him to know that the part of the building consensus means getting all again to see on the same page. There by the C effect to be playing the say called a view referee role if you may. So that's how you intend to use. So hopefully that's that, you know, that's a I have a longer version of this, like I said capture somewhere. So I'm going to share I'm going to dig that up and then put that somewhere. But that's that's that's kind of where I'm coming from. Okay. So they're more just to summarize there. They're more than just an expert in the area. There are a secondary consensus builder and code review referee and sort of. So there's the sponsor who does some of that and sort of should be trying to do that. But they the BDFL delegate will also be doing that and also trying to bring more people in and sort of have a certain cloud in that area. Right. Exactly. Right. So constecate when Go ahead, Sam. I was going to ask, would it be fair to paraphrase that as the role of a BDFL delegate is to act as a mediator and to ensure that experts are brought in where needed to weigh in more than to weigh in on their own opinion? I think actually both, I think. Yeah, so the mediates. So they're definitely a mediator. And so this isn't to say, like, yeah, so they're definitely mediator and go in recognizing that there are other stakeholders and so on. The third historical context and all that stuff. That's part of what I expect. Being the leader of the influence or the lieutenant in that part of the area. But I also don't like mediator, according to everyone, but it sounds to me like a mediator can imply this mutual like impartial third person that arbitrates things that that's not like this person expects. I have, I expect to have opinions and like thoughts and so on. It's just that I expect this person to know that that's not the only thing that matters. So, so interestingly, a lot of what you're describing is what I would generally attribute to the sponsor of the. But I guess what you're also saying is that there that that the BDFL delegate is then sort of the lieutenant sponsor, right? They're the second person that sort of has a broader responsibility over multiple, multiple ones, not just the sponsor for this one, Jeff, but sort of larger. Is that makes is that accurate? I think so. I mean, I think of sponsors that people do the after walk. Okay. And that's that's actually, yes, sort of a disconnect there. The sponsor, they tend, they tend to be, but actually they, they're, they should be doing just as much of that consensus building as right. Yeah, you're right. That's what you're describing. So both, they both should be doing that. So my, my wrestle with considering the sponsor and the way you're describing it is as a sponsor of a specific one right now. And as more that I can see coming, one of the reasons I'm sponsoring is because I lack expertise. So I'm flat out not a credible BDFL delegate. And I suspect there are probably sponsors who are not credible BDFL delegates. Whereas the value of having a BDFL delegate is I've got somebody who really knows their stuff in this area. In my case, maybe let's call it developer workflow. Right. The experience that a developer has doing development work. And there's somebody in the organization or a BDFL delegate who really thinks about that and keeps consistency across multiple gaps. Okay. May talk about code formatting or use of fine bugs, switch to spot bugs. You pick, you pick your various choices, check style standards, things like that. So it's, it's really good to have somebody other than the sponsor. And, and I'm relying on people with a lot more skill than I have in the topic. Sorry, I got cut off. There's a, there's like, I have to do a local network, taking some support role yesterday and today. So I had to take this. Sorry. Okay. So, right. Okay. That's good. That's good. I'm glad we had this. This is a good discussion for this because I agree. It's good. It's also good to have the, your perspective because again, how you're choosing those delegates. Let's see. I'm wondering, we might want to have like a list, like a list of the BDFL delegates, like someone sort of tracking if you have defaults. Yeah. We want to. Yes. I think that would be good. Okay. Yeah. That sounds attractive because it does give a chance then to categorize things in ways that Kosake described categorization already, right? There are some broad categories where the BDFL delegate, he can, he assigns that person and we start to realize, oh yes, this is one of the key experts in this area in the Jenkins project. Yeah. So what I'll do is I'll create an informational JEP that we can manage this inside. The informational ones don't have to be run through the same consensus process. They're more just like, okay, here's, here's what we have, right? And so that way we can sort of post that in there and have, keep that up to date as well. That's what I meant earlier to bundle that together with BDFL delegate selection in my mind. Okay. Yeah. So, you know, this is a line of reasoning. This is how I'm using BDFL delegate. And then here's the other result of those things. These are the people who own different areas at the moment. Perfect. So let's set up an informational JEP. I agree. And then we can iterate on it as needed. Yeah. Perfect. Cool. Okay. So, Xandas, answer questions around, around how they're selected, that kind of thing? I think the questions around how they're selected weren't actually me. Okay. I think that was someone else. Okay. Cool. I'm just making sure that you're involved there. All right. So what else? You had other questions, though? I think most of them have actually been answered at this point. Okay. Cool. So, let's see. Oh, so, Mark, yeah, you had, you had wanted to talk about your. So the, I've, I've launched the conversations on the Jenkins dev list, learned a bunch of new things as a result of those conversations. So that was exactly the right thing to do. Now I'm starting to formulate the text, which is going into the poll request that will be the, the initial proposal for the JEP. I realized I'm not sure where I'd describe the Envision Developer workflow in, in the JEP. So the abstract, 200 words, present tense, that part I understand. Is it the specification or is it someplace else where I should be describing and, and how would people describe, for instance, some other thing that involves a workflow or a, how, how work happens, a use case? So, yeah, I would put that in the specification that, that the thing that happened with JEP 201 when we were rolling out the, the white, was that 201? 200. 200, yeah, the white. Yeah. Yeah, exactly. So what we did was that we added the rollout plan, for example, in with the specification. Okay. So most of the stuff that talks about what is, what's going to, what, what, what, you know, the process itself or the design in general, most of it goes into the specification. Great. The, the default, I guess, what I would say is if you don't see where else it fits, it goes into specification. Okay. Right. And I mean, there's very clearly things like motivation and the reasoning and the other items on the, the other top level sections. But if, if you, if you're like, huh, it doesn't fit in any of those, it goes in specification. Okay. And the next piece then for me was, is there any guidance that can be given on how to avoid over specifying. So my specific example, there are things that are very, very important, like that terminal, that it's automated, what phase it occurs in, those kind of things. But I'm, I'm tempted to also put in things like, hey, we'll be using Google Java format. And it's intentionally this, is that now over specifying or in fact, the right level? Well, let's see. So let me go to actually JEP 300, which is a, what we've been calling, it's, we don't have a JEP type for this. So it's an interesting sort of situation. We might create one for this at some point. It's a mission and goals JEP, right, which is designed to be sort of a high level view of, okay, here's our overall direction. Here's, here's what we're, you know, the areas that we will be working on and what our intent is. And then we've had subjects that actually discuss and design specific areas. There's no reason why you have to separate them out though. And I think for what you're doing, it probably makes sense to keep it all in one place. So what I would do is have like a goals. So you have like a goal section under the, you know, target audience or end or goals under the specification to say, here's, here's who this is intended for. Here's the, here's what we're trying to achieve. And then here's what it tries to achieve. I'm trying to decide whether or not the stuff like the goals would go into motivation, right? But I think it still belongs in the, in the specification. I think there's sort of a toss up there. So motivation is more talking about the history. Like what, you know, why are we doing this? Like, why would we need this thing? Well, because otherwise you have code that goes everywhere and no, no standard format and who knows what's happening. The goal of the thing itself, that, that, not that I've been talking about. It's like, no, that's actually the, that would be belonging specification. You say like, so here's the use cases. Here's the goals. I think the, the, the point of specifying one specific thing is like, if there's any contention around it, if there's any controversy, if there's like, huh, why are we like, we chose this, if there's the potential for there being like back and forth about, well, should you have chosen something else, then definitely that goes in, in, in the job, right? And sometimes you don't know until you actually include it or you say it and then someone says, oh, but we should do something else and then you end up. So, I don't know. I mean, I guess I would say if you think it's, if you think it's important enough to, to, to be specific, it probably is worth mentioning. I mean, you don't want to, I don't know that we have to be, you know, you're not going to be including the implementation in the, the job. The, the specific, okay, we're going to do these five things, but I don't know. Do we have any other thoughts on this? It is still a design document, right? Okay. All right. Yeah. So I, in, in this particular case, I think the, the target format is worth stating, if nothing else, and to test that it's not too controversial, that that's the one that's been chosen. And, and then also, I mean, the other reason why you might say that is so that you could say the, we're using Google Docs and here's the folder that you would go to to, to, to get, you know, more information on that, like you would, that would be how you would link people to that, right? So if someone, maybe the other way to say this is if you, you know, put on your beginner mind, you know, hat and be like, okay, I'm someone who doesn't know anything about this and I want to know what's going on. I should be able to, you know, read the JEP and at the end feel like I am, I guess, ready to contribute, like able to participate in the discussion going, any discussions going forward or I mean, you don't want full documentation of like, you don't, there's documentation and then there's a design document. So it isn't like going to be the level of detail that you'd get out of, you know, in depth, you know, use documentation, but at the end of reading your JEP, I should be able to go, okay, so if I wanted to do this with mine, I should go look at these, like, if I wanted to use your, the formatter, I know at the end of having read this, what went into the discussion and sort of what purpose it serves and where it came from and here was, oh yeah, there was some back and forth about using this, putting it there, do that, okay, I don't care about that though, I'll just skip that. And then getting to the bottom and saying, oh, here's the link to the documentation, here's the link to the plugin, et cetera, right. And, you know, so you might not include actual instructions in the JEP to say how you would add it, right, but you would point to a document, at least, that would say how you would add it. Okay, all right, I'll try to work from there. I think I like the notion of put the description in as part of the specification, if we then later throw it away, that's perfectly fine, okay. I just seek, on the JEP you've got on screen, it's got a target audience, which I hadn't considered and I'll certainly put a target audience, it's a good thing to note in this, who are we focusing on? Right, okay. One kind of related broader narrative that I want to insert, I haven't talked too much about it, so it might come across incorrectly. I feel like I want to have people to have a little bit more attitude on how does this thing, like a JEP can help me get changed as opposed to how best I can conform to this. So, I mean, part of the effective views in the past of the JEP was like you need to, you can kind of prevent the issue from endlessly getting rehashed, right? So, you know, like say, if Mark is, for example, anticipating like he wants some of this code formatting things that might be controversial, like where he could use a little bit of selling, then this could be a great vehicle to do that, right? If you see like a configuration that's kind of like what it did, but it tries to like accept the stage to say, well, these things we kind of already agreed on among contributors. So, if you are coming on board from that, that's sort of the expectation I set on you, right? So, that's part of the intended implied effect that it achieves. You know, like, and just because we have this process doesn't mean like you have to do everything through it. So, you know, the optional services like this, and then if the first round of iteration is like, you just hacked up something that, hey, it works great for me. And then, you know, that often if you feel like that's a productivity go forward, I don't see anything wrong in studying from that. It's only going to become like more relevant if your goal is trying to influence more people is maybe how I feel. So then in asking that question, like, so what do I need to influence other people about? I feel like often the answer of like how this can help me. So, looking at this, for example, like there's back and forth around or is it a good thing that the compile phase is changing the source code and what does that mean? So, these are like, that might be like an example of, you know, like, your platform or like a pitching, why you picked the way you did it, it's probably a little bit more. So, I hope it didn't come out wrongly. That's the... No, no, no, quite the opposite. It's, I think, I want to be sure in my abstract that it describes the real benefit, not the mechanical what, but the real why. And for me, the why is about easier stop rehashing, right? I want to stop fighting people about injecting spaces or my source code into the source code. I want to stop... I want the code reviews to be faster and easier because it's consistent. And so, those are, those for me are compelling things, but I also don't want to damage the developer workflow because that would be a big negative. So, yeah, I like that. So, like maybe another analogy I bring is like, so there are these things in like a Japan called like a tea ceremony, right? And then it's like, you're supposed to, on one hand it's supposed to like a little bit of occasion around to like enjoy the presence of each other, but it's also very formal. So for somebody new, like I know they're doing it for years, like you get in there and then you always feel a little uncomfortable, like, am I doing this right? Am I embarrassing myself? Like, how am I supposed to do this? Like, do I bring up the left hand here or like a right hand here? Like, how many times do I like move the T-cup and all that? And that's not the, I don't want this to end up like that as opposed to like, this thing is really meant to help you, like, help you get to get to what you want or what you need, the changes that you're trying to achieve, you know? So, sometimes it's not always like black and white and it's conflicting all and all that, but... So, the point you're making is that the point of the JEP is to try and help us get to not rehashing, is to achieve a goal. It isn't just to... One of the goals, I think. Well, I mean, but specifically it's not there just to be an additional process that we have to slog through or whatever that we have to conform to. Exactly. I think the one thing that I want to inject in there, though, is that from, at least from my perspective, the audience of pretty much any JEP is someone who does not know anything about what they're about to read. They're like, okay, I want to know about this. What is the current state of this? And there's a lot of back and forth that's gone on a bit. We're still in sort of early days of our working with this. There's a lot of back and forth that's gone on about what goes in what sections or what goes where or people saying, well, I want it this way. And I haven't been very good about trying to communicate this but trying to basically keep people to hold in their mind. Look, the reason why it's structured this way, why we have it in the sections of the order that we do, etc., is to make it so that someone coming in can get up to speed and understand this thing. And in that respect, so, for instance, if you look on the screen right now, this abstract is way too much. It's really interesting, but there's somewhere in here is the abstract that should occur. And this is JEP 200 we're looking at. And this is just me. I'm not criticizing this one. This is one of the early JEPs. It's like, okay, so for example, this rollout plan should be moved inside. I should have put that up in the specification, for example. Part of what makes these things works is a conformance to a structure. And when we move further away from that, it's similar to code formatting. If we don't have that structure, it makes it harder to come in and know where to find things. If I understand JEPs, I should be able to understand any JEP and know where to look. But as an example of something where it's like, okay, this abstract is way too long. But it's something that people are still kind of trying to figure out where things go. And so I think there's sort of a balancing point that needs to happen between adherence to process and also because, and the reason we don't adhere at all is because that means that someone who is new will be able to look at this in the point. For example, I can read the abstract and then sort of decide whether or not I want to read the next part of the specification. And then if I'm interested, after that, if I'm interested, I can look at how was this before. But I might not be interested in all the design decisions, the choices that were made back and forth. That would be the reason. Why did they choose this versus that? They did. I'm good. And then finally, the only thing that I think we have sort of out of order in terms of someone getting up to speed is that the references which would be, hey, where would I go next kind of thing are at the bottom. But I think we could even have that be someone could easily add links to documentation or something else to earlier in the document. So I agree. I don't think we want to have too much process, but I also think we need to kind of maintain the consistency of process, right? Yeah, definitely. I just want people to have their perspective, make sure that they keep the perspective that this is meant to help us. So that's something, so I'm not asking like this isn't... Well, I don't know. I think I'm not disagreeing with anything you just said. I think, in fact, the format has been great in putting out the kind of things that often left unsaid or like known as a... Because the people who are having these things, they share so much context, you know? They don't often do the sufficient job of explaining why they did something. So you talked about the importance of capturing that, and I agree. I really like that approach that it's like a common format for readability, but it's not a completely rigid format. You know, you adjust it as you need it. It makes it sound a lot more appealing, I think, in terms of being able to put one together that fits the needs for any particular use case you're trying to document and get feedback on. It means you can kind of flex a bit where you need to if it's a particularly weird one that has a whole bunch of other... It just doesn't quite fit the normal format, basically. There's a lot of room for kind of edge cases there, and that handles them well. Cool. Mark, did you have any other sort of stuff you wanted to discuss? No, thanks very much. Got the answers I needed. I've still got a lot of work to do on that particular JAP I'm working on, but I got the answer I needed. Cool. And I think we're actually over time, so we should probably let everyone get back to writing more JAPs. Yes! Great. Thanks, everyone. Thanks, Ian. Thanks very much.