 Races now we're on YouTube. Excellent. Thank you for that. Welcome, everyone. It is another episode of the cross project council's OpenJS Foundation cross project council meeting. Today is the 5th of May, the five of five, the Cinco de Mayo. Thank you all for joining. Today is going to be another code of conduct working session, working on processes and documentation and all that good stuff. Before we get into things, are there any announcements? Yes, we've got some things to share. Lots of things happening today for those interested in getting involved. Immediately following this meeting, we have the collab summit planning meeting. And so that's at 1pm Eastern. We have a lot of stuff to work on. We have summit registrations that are live. There's 110 people already registered for the collab summit. And so we're really excited to be together that the program and, you know, so come please and chip in if you like. We also have our standards working group meeting today. That is immediately following the summit planning meeting. And so that's at 2pm Eastern. I'm not sure if that's a very full agenda, so maybe short, but hey, it's a good group of people to hang out with. So come say hello and participate if you like. And then on Wednesday, we have Wednesday morning and Pacific and afternoon Eastern is the node red AMA with O'Leary and CJ and Dave, I believe. If you have anything you ever wanted to know about node red, you can ask us now via a form or you can ask us on YouTube or Twitter. And you can hang out with us folks on Wednesday morning. And we also have some blog posts coming up that are exciting project announcements, but I'm not going to leave any of those details. Other than on the blog and what else am I missing? That's all I'm thinking of right now. I can't think of anything else. Is that you typing miles. Yes, sorry. Okay. Great. Thank you, Jory. Anything else before we get into things. I would just add, hey, this is Robin. If you all could also register for the conference as well. I know sort of folks are wondering and we did reduce the PII that was collected on that. But we really would love to have you register it helps us sell sponsorships and just so all of our presenters know how many folks will be tuning in. Great. Thanks. Cool. All right, so we can get into business here. As I had shared in the issue and now in the Google doc, we're thinking maybe we do five minutes on a voting regular member updates as we were a little stalled there in terms of just landing on a tool, letting folks make sure they have any sort of candidate statements that they wanted and such, but I'll let Jory jump in here and give us an update. Yeah, so as you all know, we need to elect two voting members from the regular membership pool. And we've collected three nominees at this, I believe three nominees at this exact moment in time where we're saying that the nomination and period should close end of day today so that we can kick off that, that actual election process. I would love for us to move forward using the tool OPA vote, which I can administer as soon, you know, as soon as the nomination period is closed so first thing tomorrow morning we can open that up. And I would love y'all's like plus one on that approach or suggest any suggestions to change that process, but yeah, that's the TLDR. Great. I am a plus one. I don't know if anybody has any objections to that process. Plus one as well. Likewise. I do have a question though. Oh, what voting strategy are we actually settling on, because there are plenty even in the OPA votes. And so I think it's also important to be clear about that because the data will look different and the outcome will look different depending on which one we choose and it's way better to have that conversation before than after. It's harder to have the conversation before, but I agree it's better to have it before. What are the key choices that we have to make. I'll pull that up really quick so I can share. Okay, here we go. And was some maybe I need to do this because there's an attendee that needs to be there we go. Frankly, I mean haven't done that in the past like actually reading the doc and figuring out which one we should pick takes a bit of time I don't think now's the right time to do that. Very honestly, and I don't have a good answer, or I would suggest it. So I suggest someone takes the responsibility of like reading that up and making a recommendation to the group. Even a presentation to the group to explain them. And why would be good because it's sort of a lot to research on your own and like it could be really time consuming to grok things if it's not presented well. I'm not a voting process expert so I hesitate to volunteer. I know Jory's pretty busy as well. I'm looking at the issue here too. Maybe for simplicity. And so this is just something nice that open vote provides, which is a list of recommended methods based on what type of election you are running. And for electing a group of people, there's some variants of the single transferable vote method that it recommends. Yeah they're suggesting the Scottish one on their page if that's the recommendation to go with this I'm perfectly fine like I just think that we need to have to make this decision upfront not after this the only thing I'm suggesting. I think Jory you'd suggested that we choose something for this vote and not it wouldn't necessarily be the precedent for all votes. So just taking the suggested recommendation in that context seems easier as well right. Yes, I still would love for us to do like the post mortem on on just our election process. You know and how to make this. I mean obviously it's our first one that we really we did so we can sure give, you know, to take all that, you know, but it'd be great to just do the to to to move quickly on this. So we're not like blocking the vote on like a presentation only said maybe. I would suggest we go with their recommendation, which is the Scottish to be just because it seems like they probably thought about it a lot more than us and then we can evaluate it afterwards and see if it makes sense going forward. Plus one. Yeah. Okay, great. So, sounds like, at least on the call there's a consensus for just using the Scottish STV method in open vote to conduct this election. Making a note here and notes here. Great. Excellent. And that's, you know, we try to keep that short. But I'm glad that we've got process to move forward. So, nominations will end today, and we'll start the process tomorrow right sorry. That's correct. Excellent. All right, cool. And we were suggesting the 15 minute time box on charter language as the next agenda item, and then the remaining time on focusing on the issues that are related to code of conduct that are blocking onboarding. And thinking that that is kind of the thing that we should focus on first, and then we can work through the other things we need to work through. Cool. So, we started a doc, I will share it in the chat. That's a Google doc there that has the place to start fleshing out the charter, the code of conduct working group that then we can PR into the cross project council. I think that's correct me if I'm wrong Michael but I think that you kind of threw some stuff in here is the top part and then this morning I tried to go through the ideas there and propose an alternator or something that we can. Yeah, as we were talking through it last meeting, I think those were the notes that I took. So, yeah, how should we, how should we workshop this. I'm just reading through your, your more complete written right up. I'd say like you know let's start with what you wrote up and then say is there things that are missing or things that shouldn't be in it, or concerns, you know, that's probably a good way to start. So I'll just read the kind of short paragraph and then they're the bullet points of responsibilities. The focus of the paragraph first the purpose of the code of conduct working group is to update it is, is to define and maintain a set of resources slash processes that will be used by the foundation and its team slash groups, and can be reused by projects when implementing their code of conduct processes and enforcement. We want to say more or less or what do people think about that. I know miles you've you've written a couple of these before the evening thoughts. Would you be able to screen share. Yeah, I'd be happy to it's a great idea. Thank you. So, can you see my screen here, I can blow it up a little bit. Yep. This paragraph is what I was referring to the people think there should be more or less here. This is merely the chartering in the for reference folks this is the working group stock in the cross project council. And we would be PRing language into this establishing a code of conduct working group this is the standards working groups, code of conduct. I mean sorry charter. And I was sort of using that as an example to flesh out this year. So for a small thing. Please go for it. I just got to say overall I thought it looked pretty good but so so go ahead. Just what says, maintain a set of resources slash processes that will be used by the foundation and its teams groups. That sentence is just like a bit of it seems like it's running on a bit. I'd be maybe say, maintain a set of resources and processes that will be used by the foundation. It's the comma, it's projects, comma, or maybe even just the foundation and its projects. Or I would suggest actually and it's teams like teams is probably the most generic. Teams could cover projects groups, whatever projects are pretty specific. But would you consider I know I'm being pedantic here but would you consider a project to be a team of the foundation that doesn't seem to be inclusive to me. Yeah, I just to give you some some insight into what I was thinking that this this first part of the sentence and I've put a period there to make this the sentence here was particular to the foundation and like the cross project council and you know the team working group and then follow that along talking about the projects that that it can be used by the projects. That makes sense. Okay. So I would I would then change like these processes can serve as a or these resources can serve as a basis for projects when implementing. I don't know if you want to add it. I friend, you know what if you want to add in at the front like one of the goals is that these resources. The only subtle difference there is like, in one case is saying they could be in the other cases like we want one of our goals is to make sure they can be right. So I guess kind of like an additional thing to consider with this, like I know it's something we've gone back and forth on this. Like the code of conduct is one of those things that we will be setting as like an expectation to projects. So I think that it's important for the language here is explicit because can serve as a basis, implementing their own seems to imply the they can kind of do whatever they want but this is like something they could use. Yeah, we have, you know, we haven't said that we're going to tell the projects how to implement the code of conduct only that we've asking that they use a shared code of conduct right. I would say that. Yeah, so I think that's one of the key issues right now that are is actually relating to the things we're going to discuss here in a minute. That's, that's tripping us up and onboarding. And so, you know, we've said, you have to adopt the foundation code of conduct and projects are like okay, how, how would you like us to consume this how would you like us to, you know, point back to it, etc. And to that end there, they need more detail they need that explicit implementation guidance and this group should theoretically be the body that provides it. And I think there are some resources that will very clearly and obviously be optional for the project COC teams to use as at their discretion but then there's going to be some other things that that I think this group will oversee that that we do need. Yeah, I agree with that. So how do we phrase that. I Maybe it's more about a line about saying, you know, the purpose and like and to provide the resources needed by projects to, you know, implement these processes or not implement and just like it is about providing what the projects need to do that the parts which which are not optional and if the parts that are optional like you know provide resources they can use. So maybe that these resources should serve as the baseline. Something along that. That might be a little strong for some of the like if I read that is from a project that might be or you're going to tell me my whole like how I, from my reports and my point of view it looks a little bit too much. Be honest, I would try to like if for smaller projects, these might be problematic for biggest projects kind of fine we can have complex processes in place and so on but for a project. Which has one or two individuals contributing. It's and we have a few like that like three five whatever it's not feasible to have complex processes like it becomes unsurmountable. To some extent. So, I think this is an interesting challenge though. Mateo because my understanding is that the foundation wants to create a team. Joe you're showing messages as a headset. Thank you. The, like the intent here Mateo I think, and people can interrupt me if I'm wrong, is that the foundations like code of conduct panel or larger body. That's foundation wide would be able to be, you know, the people facilitating that for the smaller projects. I don't know if this working group would be the people who are responsible for that. But I think that's important to keep in mind while we're drafting that or at least be honest. Miles I don't think any project would like to outsource completely their code of conduct to somebody else in the foundation. I'm not sure that I mean I think I think what you're pointing out Mateo is that there are a lot of different points of view and preferences, and that those also vary by the size of the of the project. Who governs a project to some extent. And I think one of the responsibilities of this group is going to be to take those considerations. Very seriously, you know, to make sure that new policy as it pertains to the code of conduct has as much input from the smaller projects, as it does from larger ones, and sort of like. That's my hashtag two cents. Maybe a way to frame this could be like the working groups responsible for creating a baseline expectation, or like a minimal requirements for projects regarding code of conducts and to provide resources to projects in order to implement. Because Mateo I guess like the thing I'm trying to reconcile here is like I understand that we don't want to create a new expectations for projects. But if we say the projects must have code of conducts there must be something, some expectation of enforcing it otherwise there's no point in having it. Yeah, and when I think baseline I think behavior I don't think process. Right. And I think what Miles just said, she's an, you know, processor, but like requirements like so to define the minimal requirements and provide resources to projects to help them implement those. That sounds like this, you know, we haven't just agreed where the line is, but this team will have them the responsibility to define that. Yes. We have a question, please. Is it necessary to have everything inside the code of conduct. I'm asking this because from my perspective code of conducts more like a human basis relationship how to to deal with each other in a community as a group, but not necessary as a process on how to do the work itself. Is it necessary to have everything in the code of conduct and should show that we have a split it split it documents for that because when we're talking about human relationships and those kind of things like respect and each other. This should be the base foundation of code of conduct, but each product each project has their own process. And I believe the single code of conduct will not work for everyone. So, and so I think, you know, thank you for sharing your, your perspective. I think it's important to, to point out that that that question of whether there will be a single code of conduct or not for all projects is has been settled for quite some time. And I would not recommend that we revisit slash reopen that that question at this point, because there are just other policy things. Yeah. Yeah, no, no, I just, I appreciate your, your input, though. And I wanted to thank you for it. Yeah, just to be clear to we're just trying to establish some language here that would charter the working group so we don't. Yeah, we don't, we don't need to have all of the things listed out here but just some guiding principles and the responsibilities that we expect here from the group itself, not of the code of conduct. And I almost wonder if we can just drop that second line, like leave it as the first, leave it as the first line. And then, you know, you had fairly good coverage for what we've been talking about already I just added one line which is like to define the minimum requirements and provide, you know, guidance resources to help them implement those because that's specifically what Jerry was calling out we have said, you know, we should use, we have a common code of conduct, but the projects are like okay we need some more guidance on how to how to implement that right. Yeah, I think the only thing I would go for point. I was just going to say that that that captures what I very well what I was thinking, Michael, thank you. The only thing I would say if we limited to the first line, I would just want to include projects, because we only say teams I'd say the foundation, its teams and its projects. Because I personally think the distinction is important, but if people don't agree, it's not a. I agree with that statement two months. Yeah, you know, I'm a little bit more concerned about it. I want that first line just says we'll be used by them it doesn't say how or what the expectations are Mateo, but I don't know how we can make it less. Any less than that would be saying that we don't expect projects to actually maintain a quota conduct. Well, no, that's already part of the requirements. So it's in here you're defining you want to. So, from my point of view, if we want to force something on a project, it needs to be a CPC. Decision versus sorry, if it's a recommendation, it can be completely delegated. I don't know if the line is blurred. I don't know where if it's clear where I want to put the line is the way the point of chartering a working group if we're not empowering them to make decisions. I am not. I just think it's a essentially if this working group decides to all projects should be all CPC needs to be handled centrally I'm not happy to to even allow that. Sorry to be clear. I'm just, I know, but I think it's a pretty big jump from saying that there's processes that will be used by projects to take control of all for the context. I don't see how that jump is. But I do I do take Mateo's point that you can read if you just read the first line. You can take it as that if you look at the second bullet point and responsibilities when it says to find minimum code of conduct requirements. And just to say, you know, this the whole thing that the process we're defining for the foundation and what and what will be done at the CPC level is not the same as what's going to be required of the projects that could be substantially smaller. So on the flip side, if we don't define the projects in that first line, then it's somewhat implies that the code of conduct committee will be making things without thinking about the project needs and thinking solely about the teams of the top level foundation. Like, to me I see I see this as like a commitment to adhering to the needs of the projects not taking control from them. That's what I read from. Yeah, I like the correction that just like anonymous dingo made right now for use by the foundation instead of that will be used. Yeah, I think does does that sort of elevate your. Yeah, it does. Yeah, it's essentially it's. It's not my overall concern is not to be as autonomous as possible. And if I just don't want to some extent to create to reduce this autonomy in any form. Yeah, that's not the intention. Joe one thing you said for use by the foundation and its team and just projects that you would be for use by the foundation comma its teams comma and its projects. Yeah. Yeah, it's okay. It's okay for this. Yeah. So, as a to give you to give an example what I would like this to be is to essentially when you want to set up a project. Oh, it is the process that we, you can draft your own process for CC relations or whatever, but it is ours, take it or do what you want. Okay, and this will what I would recommend this to do versus saying, oh, this is the process you're following. Yeah. I appreciate your concern I hear you holy Mateo and I and it's funny that that small alternative language does help with that. So they just wanted to clarify this. The bit because it's for me it's significant the difference between one versus versus the other. Great. So, um, Go ahead, mouse gun. Um, in the responsibilities where we say code of conduct processes, should we say code of conduct and moderation processes I think it's important to call that out in all the places. Sure. Yeah. I would suggest that we, I mean, we can spend a moment on these responsibilities but maybe it would be best to just PR what we have here in and we can work on it further and in the whole request, what do people think. I think they look good unless you know unless there's anybody who has objections or concerns that it might be worth talking about those specifically. I'm happy to let folks finish their thoughts here we can, what I'm suggesting is maybe we move on to the next time box. Things on the agenda here which was focused on unblocking onboarding specifically related to code of conduct issues. Moving on to that I'll let folks finish their thoughts in the doc and then I can PR that into the working group file. Just one point of order Joe Chris Hiller needs to be promoted. Sorry, can you do that for me. Oh yeah sorry and I think I lost the view from, yeah, because we were sharing. Sorry, Chris. Cool. So I can stop sharing. And jewelry I would I would ask maybe since you are probably most familiar with what is blocking on boarding would you mind going through some of those. Yeah, so. Also thanks everyone for for that conversation now just now on the the charter I think that really is quite and helpful. So, one of the reasons we're we're focusing on this obviously is that we have a bunch of projects, some of which and haven't completed on boarding projects, some incubating projects who are just getting into to this step and are looking for guidance and the critical questions that we really haven't answered definitively for them relate to how they consume our code of conduct. And, and where where our canonical, you know, COC, like is now I think at this point most of us understand we do have even a URL for that at code dash of dash conduct dot open jsf.org. And, but I think that there's still some question within the community about whether that is, in fact, canonical. So how do we ask them to, to consume that canonical. And then the, the next bit of blockage is related to how projects escalate to us. So what is that system looks like. And I think, and I'd be very keen to hear from Toby and Matteo and others on the call who have projects that they're, they're bringing in through and Jordan bringing in through incubation that that would at least unblock the immediate problems areas. And, but if there are other points I'd love to, to hear that too. I'm happy to speak from the perspective of amp. I think what we add here is that I don't think it changes very much for the amp. So I think that's one of the working group as to where that documentation is stored and how that process works as long as the underlying flow, if you will, is well accepted and understood and I think there's agreement as to what the underlying flow is which is project handle this at their stage and there's an escalation path. So where exactly it happens I don't think the the CRC group actually really cares, we just like to have clarity so that we can actually resolve that issue and move forward. What do you mean by where it happens like how does somebody escalate or no like exactly whether you have a code of conduct that is in the repository of the of the project itself was an escalation path written down in there, the code of conduct for the whole foundation has ways to have emails for the different projects, like that part, sort of like that implementation of the process to be more specific doesn't really matter to us like the only thing that, you know, the the amp project cares about here is to have something to work was and just implement that and, and, and be done with it. I think it's going to effectively change a lot of things with the caveat that something has been brought up multiple times is in a situation of crisis that involves, you know, bringing up a code of conduct violation, you want the process to be simple and clear from the perspective of the reporter of the violation. So, I think that perhaps a comment that I added on number 515 and I'm just going to go grab it and pop it into the chat so we all can see it may may illustrate this a bit. Which is, you know, this, this is a pull request that's open about adding the reporting emails to the code of conduct itself so that if an individual hits our code of conduct. They can quickly find the reporting email associated with whatever project they are. They're, they're looking up at the bottom. I added some comment for additional context, and that kind of points to how this is being handled in a variety this this path that Toby describing is kind of being handled in a variety of different ways. And one of the questions I would have is like, you know, are there a couple of different ways that we want to support. For example, in the JS foundation, and it used the former the artist formerly known as the JS foundation, we had a code of conduct file and every project. This project adheres to the JS foundation code of conduct with a link to that document, and then it also included the reporting email address in that file and that so it's a very simple two line file. And that's my comment that's that's number three here. Then we have their other variability beyond that, for example, they may have consumed the COC file that we require, but not repart not not put anywhere within their, their documentation, the reporting email address. So, you know, the question becomes, is there a specific pattern that we want all projects to follow here, just for simplicity, or do we want to provide a couple of options for documenting that path. And I guess there was a long conversation before about whether a reference or inline was appropriate. And I think the, I think what the way I remember the outcome of that is that people wanted to have the code of conduct be inline as opposed to a reference to somewhere else. Well, just to clarify this, I mean the referencing, for example, at the organization level of amp already happens right there's only one code of conduct for the whole organization of amp. And currently that one is hosted in a meta repository on the amp organization from the perspective of amp like whether that is there or like at the foundation level doesn't, I don't think it changes a lot. But if there's like too much back and forth, I think that was the thing that Nana brought up, which is, if you have someone it's in the, you know, main amp repository. It has their witnesses or like it wants to report a code of conduct violation goes into the code of conduct of the main amp repository is pointed to the you want to make sure that that path is as as direct as possible and doesn't do back and forth too much. I think I'm sorry, but I think both options where that is locally or at the foundation level of work from the perspective of that particular use case that particular scenario. So I think to like the request that Matteo had before as well. I think it's reasonable to allow projects to make a decision here about what works best for their project is as far as like, vendering or pointing is concerned every project is going to have different needs. It seems to me reasonable to allow projects to to have their own with more or less the expectation that they keep it up to date. And I think that this is something that if we wanted to and maybe this is like something the code of conduct working group could work on. And to be able to create, for example, like a GitHub action that at a regular basis can check to see if the upstream code of conduct has changed and automate the process of sending a full request to update it, for example. But to me, I think like if we're if we're talking about trying to have some degree of flexibility. This one seems like something we should have flexibility on. So I think Jory you were saying there's like we could we could say here's a few options right it's kind of like. You could do this two line one that's the simplest or you can create a copy. You know you just need to include the reporting the escalation section as part of that. Yeah, I'm a fan of optionality here. Personally, I think that there's a number of of at large at large projects that would just be happy to, you know, and do like the short and sweet two line option, but and you know respecting the agency here of projects that have really robust and and C O C and groups to, you know, be able to maintain their documentation and just add our escalation path like that seems very considerate so, you know, I think, like, that's great, what what we don't have at the moment is just that set of options is defined. And so it makes it very hard for us to affirm that a project has on boarded correctly because, you know, you know, everybody's not sure if they've done it right. Yeah, I guess like the one thing that we may want to confirm here would be, you know, what level of modification is acceptable for the downstream code of conduct. It seems like we have we have consensus that folks like need to be able to change the reporting address. Perhaps it would be reasonable for us to be explicit. If that's kind of the only moderate if that's the only modification that project should be allowed to make seems reasonable. Yeah, and I think I mean I'm just looking at our foundation code of conduct requirements I mean that it lays out the requirement that it needs to adopt this this code of conduct I think modifying it means it's no longer that code of conduct right. But they need to be able to modify it to put their reporting address so I think that we just need to be explicit that you're expected to update the reporting address but that should be the only church. The other thing that we could point out to and this could just be like a resource non official documentation is, we could potentially keep reference to extensions that projects have so the Node.js project for example has like our membership expectations, which is not part of the baseline code of conduct but is like, you know, obviously related to to it. And I think that showing some of these practices can can also be a great way to point out to projects like, here's how you can do some things that go above and beyond, without having to modify the baseline code of conduct that we all share. That makes sense. I, we only have seven minutes I'm just wondering, in terms of unblocking the current projects. We, it sounds like we've, we've kind of come pretty close to agreement on one of the, the key issues which is, and what are the acceptable options for consumption of our COC and so I think something we need to do as a next step is open a PR somewhere that describes these options and get some thumbs up on it and included with that, I think is a, a paragraph or sentence or you know some some bit that describes the escalation piece. In terms of where, so, you know, to, to, well maybe that's, maybe I, maybe that's not even needed right now. I'm just wondering if it's you know what I'm just looking at say this just pasting a link. And it talks about, like it provides an escalation report. Okay, that's not the right section but I'm looking for, you know, basically that that is the email address that we that project should refer to in terms of escalation. We'll see that and this is actually a, a, this section and is something that I think some projects have reported being uncomfortable with. So, like this, in exceptional cases where a reporter wishes to challenge the response from the project's COC team or from the CPC. Like that, that space that piece specifically is something that at least one project has said I'm, we're not comfortable with that being permitted. Because it kind of feels like a usurpion of the project's authority. So, particularly the word challenge or, or, you know, if the word differently with that. I think it's just the whole process of being able to go beyond the projects, you know, determination. Yeah, I think it's, I think it's just about going beyond like the, the projects autonomy so that the concern is well, you know, we said, you know, we gave a, we applied some intervention here. And then the person is appealing it through the COC process, the COC escalation email at their own behest and what if the COC escalation group reaches a different conclusion. Yeah, that's a pretty fundamental question as to whether, I mean, if, if the project can say no to an escalation, then effectively there is no escalation. Right, like there's no, there's no required escalation path, which was one of the, and that that's in there. Because there have been past complaints of, you know, hey, we made reports to a particular group, the people who were in that group. You know, weren't impartial or whatever. We had no way to escalate, you know, or, or, you know, and it's, but it's that, you know, that is the fundamental question, will there be an escalation path or not. I think the escalation to start to interrupt, I was just going to say, whether it's like an appeal, or whether it's like, I don't feel comfortable reporting to this specific group, you know, perhaps because their membership is problematic in some way. Yeah, and I don't think they're this, this project's particular concern was like, you know, for the, for the individual using this email, because they may be having difficulties with with the people on the coc group themselves like, like that it wasn't that use case it was the, it was the, you know, we've made a decision and now this. Now this person wants to appeal that decision to an ostensibly higher authority and where the project clearly wants to be the highest authority on their coc. Yeah, but what happens if they report to, I mean, so somebody says okay I'm not going to report to the project because I'm not comfortable they're going to make the right decision. I'm not going to be any happier with the cocp then getting involved in that situation. And I, I don't know I mean this isn't, I'll be completely frank this is not my point of view I'm just trying to, you know, you know, this does come back to the, like the minimum requirements for being part of the foundation. It's, do you have a, and where you draw the line right at the way that this was written before was the minimum was that you know you agreed to have to come to conduct, and that you agreed that this was an escalation path. I mean, I think it's, it's, I think this does this question does point out, though, you know that there are different interpretations of escalation, and that there's also, in some cases, variability even in among members of the same project right so so there's just a lot more conversation that we need to help and support projects to have within their own coc groups, you know, to kind of be able to bring those to the to the to the broader CPC so we can actually help resolve them. And with that we're at time. But I think this was a productive meeting. Appreciate everyone being involved. We should determine what we want to do next week. I've got the PR already open for the charter for the code of conduct working group. You know we can continue to use this meeting time or we can spin off a separate meeting. I remind everyone to check the issues and PR is in the cross project council repo, especially the ones with the agenda label, so we can keep other things moving forward to be any any closing comments or thoughts before we call it a wrap. Let me ask really quick, you know the PR I suggested that we open kind of documenting implementation options. My gut would be that that is something since that would be sort of like some guidance for how to do this would be that it could go on the either the coc repo or even on the onboarding repo. Does anybody have a strong feeling about where documentation like that should live. I would second that. I was just going to add one thought which is maybe we should just reach out to all the project leads and say, like, hey, what do you think about all this. And just say, do you care, or are you just going to follow whatever the foundation tells you do you have a strong opinion just to sort of get some feedback on that from the leads because I know like for dojo and intern we're just going to be like, we're just fine for us we're happy to follow it because that's like the path of least resistance and we're cool with that. And I have a feeling a lot of the projects are going to feel that way as well just because it's one less thing to have to, you know, customize or think through themselves so we might be like boiling the ocean a little bit here which is good but I mean I also think that most projects are probably just going to be like tell me what to do and I'll do it because you know you've thought about it a lot more than I have and that's good. I definitely think that, like, as part of this just can check again with the projects, all of them, you know, maybe even, especially those who aren't regular participants here. Well, we'll call it a wrap. Thanks everyone appreciate you and your time, and we'll talk more soon. Talk to you later. Bye bye. Bye.