Kubernetes Steering Committee, 12 Oct 2020

Previous Meeting Next Meeting

⏯

youtube image

►

From YouTube: Steering Committee Public Meeting 20201012

Description

The Steering Committee is a 7 member body, overseeing the governance of the Kubernetes project.

A

Okay, uh good morning, good afternoon, good evening, everyone- uh my name, is chris blecker, and this is the october 12th edition of the kubernetes public steering committee meeting.

A

um We have a pretty package angel today, um but before we get into it, I'd like to remind everybody that uh this meeting and our community is subject to the uh kubernetes and cncf code conduct, so please be excellent to each other.

A

um So I'm going to hop right into our first subject here, which is the steering committee election results.

A

Excuse me, um so changes in governance are always a um a critical time uh in in any community of any size um and in ours in particular, they're they're. You know very critical that when we we choose the folks that are going to be um making critical decisions that we have like a um a solid uh process behind it.

A

um So, first off I'd like to thank our election officers, um jay singer, demars josh burkis and uh eur who um conducted conducted our election made sure that everybody got the update that they needed when they needed them. There's a lot of manual leg, work that is done as part of the elections.

A

So, thank you very much for for taking on that very important role in our community.

A

um So without further ado, uh I'd like to announce the three winners that will be taking the the three uh currently vacant steering committee seats, um so congratulations to jordan, liggett, bob killen and dimms, who will be uh taking rejoining us with the third seat.

A

um I'd also like to extend the congratulations and thank you to everybody that participated in this election. um You know whether or not you were a successful candidate or not. um We had an incredible slate of candidates. People from all corners of our community and the elections process um is made better. By having um such a like, wide-ranging slate of candidates um can participate in the election.

A

um We had uh roughly the same amount of voter turnout as we had last year. um Percentage-Wise uh we'll also be you know. In the coming days and weeks, the elections officers will be um uh putting up like a bunch of the raw voting data and that kind of stuff for transparency reasons.

A

So uh with that.

A

With that, we will keep rolling through the agenda.

A

So the yi I'm going to rearrange the agenda a little bit um so knocking on that that that previous issue um nikita you had uh you mentioned about the retro for uh the election, I'd like to tackle that next.

B

Yeah um I was going to talk about, so we need to create an election. We need to have a meeting uh for the election retro. I know we had a lot of things. We wanted to talk about there, uh things that we discussed in the previous retro that we probably also wanted to incorporate in the next election us I would.

B

I wanted the retro to be scheduled in the next couple of weeks, if possible and uh get the changes in uh after the retro instead of waiting for the next election, and I can like take the task of creating the doodle and figuring out the scheduling and stuff, but I'd like to get that going if that works for everyone.

A

That would be fantastic.

B

And I'd like.

A

B

Yeah I'll take up the task of creating an issue in the steering report.

A

Great um and I'd like to uh make sure that we extend that invite um to the retro to like everyone involved in the election, so not just the elections officers, but also, if you are a member of the steering committee, a previous member of the steering committee, a candidate for election.

A

um If you have any feedback on any part of the process, please please please uh participate in the retro, provide that feedback either in written form or come to the meeting or something like that. As you know, anything that we can learn to make this process better um would be beneficial. It can only uh enhance our enhance our community, especially again in these like sensitive important, critical governance, changes.

A

Okay, any other comments on the election or the retro. Before we move.

A

A

C

So the next thing we've got on the agenda: sorry, jim yeah. I would like to thank all the candidates. There was a lot of energy this time, um so I was really glad to see all the positive vibes uh towards the community towards the election. um So well, we'll talk more talk, talk more about it in the retrospective for sure, but we should figure out a way to harvest some of these energies going forward as well and make sure that we are able to invite people in.

A

A

Okay, so next thing on our agenda is the working group reliability charter?

A

There is a linked pr in the agenda dock.

A

Why tech are you online.

D

Yes, I can cover that, I'm not sure like. I can go over it and um uh describe what is there or do you prefer or do? Maybe you already have some questions or concerns or.

A

um Maybe if you can give us like a two to three minute, like brief summary.

E

A

Like what what you view or the goals of working group, reliability, um and then we can get into if any of the steering committee folks have questions.

D

Sure um so so, basically the goal or the mission for the group itself should be ensuring that our users can run kubernetes in production and.

F

I think we may have lost weight there. Oh no internet.

D

Like reliable way and statement for that is, is defining what we're not entering it.

A

Yep, sorry, we lost you there for a moment. um Sorry would you would you mind, starting back over, we lost.

D

A

At the beginning, and you had like a 30-second outage.

D

Oh sorry, um so we are planning to have in scope, for the group is basically first um defining. What's what reliability really means for kubernetes and how we should be measuring it? um What we or how I would envision, that is that it will. We will define a set of slos. That um um kind of, if satisfied, will will mean that, like the kubernetes is reliable, but it's like the exact details are to be done.

D

um The next thing is like measuring reliability in tests and based on that, like providing um a criteria for blocking the release.

D

If the reliability bar isn't really met for a given release um and then like also providing or getting a survey of survey of like end users um to to understand what kind of outages and issues related to reliability they are facing, um and based on that and based on, like our own knowledge, what what our potential, like um outages or gaps, um creating and prioritizing list of like necessary reliability, investments um that should happen um and finally like based on that list, like working with relevant, seeks for um delivering both the infrastructure that are needed to address those things like, um for example, some testing infrastructure like upgrade tests or like chaos, tests, or something like that, as well as like working in individual with individual.

D

The individual. Six, on, like specific um improvements, um mostly like what I envision uh is that we won't be like what is out of scope, is like designing or executing like of individuals that are clearly falling into like individual six charter, like I can imagine that, like the best example, is probably priority and fairness like, which is clearly a reliability improvement, and it's happening now, but it clearly also falls into like sig api machinery charter.

D

So um what like this group will be focusing more is the potential improvements that are like cross, seek cross, cutting multiple six, and I think hopefully this part is um it's not super controversial? um Well, okay! So maybe, let's, uh let's move.

D

Let's move into deliverables now because, like it's pretty connected, so I think I mentioned most of that in like when, when talking about skull, but to make it explicit so so the the expected deliverables are like first document defining what reliability means uh then, like the list of known outages and and failure, most um list of specific investments, that should happen in this area and, finally, um the set of processes that we would like to introduce to avoid like um degradation of reliability over time- and I think that is hopefully not super controversial.

D

One more thing that is potentially more controversial is that we would like to to get the power to block some feature-oriented contributions from individual 6. If requested, reliability. Related improvements won't be addressed by those six like um the exact.

D

What what exactly it means is like to be done like I, I don't want to propose anything specific at this point like we will. We we definitely would like to get like once we have a more concrete proposals, what the criteria for that will be. um We will definitely get back to sig architecture and sig release and whatever other six, you believe should be involved in like approving that decision.

D

um But it's something that um I think it's pretty important to be able to actually um enforce the like uh being able to enforce that people won't be ignoring the reliability.

D

And I think that's mostly what is in the proposed charter, except from our except from like standard boilerplate and.

D

Yeah, I think we can get to questions and concerns there.

A

Okay, thanks for that white tech, um so I'll first start off by addressing to steering uh or does anyone have any questions in particular for white tech, uh dibs.

C

So one thought that came to mind while I was reading it this morning was uh we need to somehow involve the cncf end user community um and try to reach out to the oh, the people outside this call.

C

Otherwise the usual culprits will show up for the meetings and we need to expand uh our outreach to make sure that we uh talk to people um outside um who are not developers who are more yes, operators, more uh product uh people who who run this in their own companies. So we I would like some verbiage in the charter for it. uh That would help, I think, because then we are like okay, it is in the charter, so we better try to do it.

C

I don't know what form it should take, but uh we can try out a few things. I think um so. That was one thing. The other one was um uh the working group itself. um You know the the only previous uh special superpower that we have is with uh the scalability sig. Where us this. The sig is interested to uh revert back stuff right, um especially uh in the european time zone.

C

When uh the west coast is asleep, we should be able to uh turn things back, so um that is the only superpower we have so far uh as a president. uh Here we are um we need to. When we are talking about it, we need to figure out. What does this mean um in terms of like? Are we stopping things from going from one you know alpha to beta? Are we talking about like being able to leave the features switched off?

C

So what are the possible places where we could use this super special powers that you're asking for that would be one the other one would be the working group. Does it recommend to sig architecture and sig release and basically who's going to what is the communications and who's going to actually stop things from happening like is there enhancements that needs to be kicked out from a milestone which is sig release? uh If it is, uh you know similar.

E

C

Like which subproject of cigars needs to be involved that kind of stuff, so we need to think that through that a little bit more, but I don't think we need to do it at the charter right now. uh The charter right now as it is is, uh is perfectly fine, but I think we need to hash it out a little bit um in the initial calls when we get this going.

C

D

Yeah, I sorry I absolutely agree with that. I mean like the final proposal that we need before we will be able to block anything, definitely needs to address things like under what conditions we can do, what what exactly we can do, whether it's it's kicking, an enhancement from the release or whether it's blocking individual, pr's or um potentially other other ideas.

D

I think that this all needs to be fleshed out, um and I I like I have something in my mind but like it needs to be discussed like in much wider group before we will be able to so. I I didn't want to block the creating the charter based on that, because I think it's I don't want to block creating like starting the the group from doing something useful in the meantime.

D

But yes, I guess it will take at least a couple weeks to figure out something more specific and something that can actually be approved by by others.

A

Hey thanks tim thanks for watching uh derek.

G

Yeah uh a couple questions if it's okay with tech, so uh one thanks for putting together such a concrete proposal uh to dim's comment around um special powers, like I kind of view this document as basically implying a future, maybe governance update to sig arch itself right like so I just to make sure I understand.

G

Do you anticipate the work group uh dissolving before it exercises these powers and then just the subproject of sig arch is going to be the one that's actually exercising the power um and if so, maybe tim's or john or myself could look and see if the sig arts charter needs to be updated. So that was my first thought on that and then the second question was: um how frequently are you guys uh is everyone intending to meet um in in the working group? I I didn't.

G

Maybe if I missed what the current cadence is, that you're.

D

Sure I think I think it's not yet anyway, so to to your first question: we we we are also considering where we were like briefly discussing it like we were considering making like production readiness, a project of cigars to be to be the the one who will be exercising the power, but um we will definitely keep you in the loop if, like before, we actually open it for like wider approvement approval.

D

um I think there are multiple options still on the table. I don't want to like make a decision here, because it's it will be just my opinion. So um but yes like definitely we want like full sig architecture buying, like, I guess, all of three at least all three of you, so so we you will definitely be on the loop there um regarding um cadence and frequency I like for now we are. We will be starting that, like there's. No, like the first meeting still didn't happen like we are.

D

We were trying to do it but like we are still waiting for all results and stuff like that, for what time will work better, but what we are initially at least planning is like every every one hour, bi-weekly so by weekly meetings taking one hour so pretty much the same as cigars, for example, is happening now and we will like after a month or something we'll see if it's enough or we need more or maybe we need less, which I doubt at least initially. But yes, we will be adjusting it potentially.

B

Later, um to just add on to what cinderella said uh in the chat, would it make sense to uh split the special power thing into like that? The working group will have us might have a special power to uh block features in the future, and one of the deliverables would be to figure out the process for how that would be done.

D

I'm fine with that, whatever, like you guys, prefer, I think it's. It translates to pretty much the same actions. So it's just a matter like of documenting it differently. So that's fine for me, too,.

A

Speaking speaking for myself, um I I kind of agree with those comments like I. I I'm also just interested in the mechanics of like how you know how those feature oriented contributions are going to be blocked like is that a block at the cap level in the kept stage?

A

um Is that or they're actually going to be like working with sub project owners to say, like hey, no, don't merge this particular thing to this um directory in kk or or something like that.

A

Like there's some there's, I think there's also some mechanical details uh around blocking merges, because I don't think that we've necessarily had that explicitly as a lever uh before I know we've in previous, we have like it's been leveraged to block releases that, like hey, this thing needs to be done before we will actually cut a release, um but blocking it pre-contribution, pre-merge um or having you know or having the power to revert.

A

Is it similar to like scalabilities uh uh powers there, like yeah I'd, be interested in some of the more mechanical details as well? In addition to the criteria, that's all that's already called out.

D

Sure so we well. We were talking a little bit with like sick testing, folks about that so, um but I think it was back then, when we were thinking only at the level of like individual pr's and not like caps or features themselves. So what we were discussing back, then it was actually written in the original google doc before I open this charter. So what we are thinking about it is basically extending or pretty much using like um doing that at the pro pro sorry in the.

D

Sorry, I I missed the word so basically at the emerge, bot more or less level, um basically by saying that only prs like specifying a sigs that are currently blocked in some way, probably in some, some like somewhere in some config of pro and blocking all the pr's that are that that are annotated with that seek and like kind. That is not like test test fix or failing test or um flake or regression like basically blocking features and feature or oriented pr's.

D

um We would need to extend a little bit to ensure that, like every pr has to be annotated with kind and has to or labelled with kind and has to be labeled by with seek, but I think that's already either happened or is happening more or less so, um but yeah this is proposed.

D

This proposal is like, and it seems that, like we were talking with like uh and with uh sick testing faults, and it doesn't seem to be much work, but that proposal back then was purely oriented on like blocking prs, and we may also consider just blocking uh blocking, for example, feature graduation and not the cult itself. So um I think.

D

I wouldn't I wouldn't take what I said uh as something that we we actually really propose. I think we may we might change the decision to to be cad based or or something a little bit different. So um this is also why I didn't put the mechanics um anywhere yet because I realized that, like blocking prs, may not be the final decision.

A

Yeah that that that makes sense, I think we should probably call that out then, like that you know just adding on something to the special power section saying like these things, in particular like the mechanics of how we do. This has not been decided yet just so that it's clear that, like this is still like an open discussion, because I could see that particular discussion not only involving cigars who's been called out, but also testing and release as well. Yep.

D

E

Hey so um so, josh had a question in uh the chat that I wanted to since the sig release chairs are here. I wanted to give a chance to address.

C

Possible, um can you speak it out, uh stephen, so, uh for the recording people can't see the chat right. No.

E

No I'm saying josh should should do that and then oh.

H

Okay, um yeah! No, I just wanted uh one of the recent or the current release lead to speak um because.

H

You know if we're talking about an extra step required to merge things, um that's also going to affect the release train, um and so you know, in addition to the details that others were asking for I'd like to see some details on how this would be coordinated with the release, team and or the patch release team, depending on which one is relevant.

E

Yeah, so I would, I would say, from from the perspective of like large sweeping changes, um whether it be like some of the issue triage stuff that recently came out. We try to do that earlier in the cycle, or we try to coordinate ideas like that earlier in the cycle and then not action on them unless, uh unless they're easy to do and not crazily wide sweeping this is this. This would be a huge change um and I wouldn't expect it to to happen until at least 1 21..

E

um With regards to blocking merges, we've discussed this for years right. um We've, we've discussed being able to block releases on things like this for years um and- and I think the gates that we currently have in place are gates that are human gates right. um I would be really curious, and I know that they- I know that the um the details were explicitly left out of the proposal I think partially, because we don't know what they would be right now, we've done.

E

We've we've had this discussion so many times throughout the community, and I don't think we've come to an answer. I think that the closest thing that we have to do in terms of blocking merges are pre-submits right, like that's, that's, that's our gate right now, um anything that uh anything that comes into kubernetes kubernetes as a result of a as a result of an enhancement, a cap completion.

E

um There are multiple people working on that at any one time and there's no guarantee that all of those people are on the same page and are going to do the right things. So we have to have the machines block and that has to happen at pre-submit.

D

Like one quick clarifying question to stephen, so um I agree with what you said basically, but um do you have any specific concerns with like how the charters currently um how it currently looks like, or is it like more common for how we should be executing on that later.

E

Oh for sure, no I I approve the charter too. um I I believe in it I believe in it, and I and I think it was clever to explicitly leave out details for the implementation that was going to block formation of the group. um We testing architecture, this group uh and and release all have to get together and figure out how to do this, because it's it's not easy. We haven't solved it yet so true.

D

C

Okay, um so the first uh thing that I wanted to say was: how do we know something is going to be reliable or not it's like only after we check it check it in merge it, and then we figure out. Oh, this is not working right like, and then we realize, oh, my god, we need to either revert or switch it off or do something like so that mechanism itself. I think you know I'll be interested in figuring out for sure, but the second one is in the charter.

C

I think what we can do is we can explicitly say that how and where we apply the special powers is still under discussion and will be they'll. Add another document when it is done and leave, leave it like that right. um So that way the charter can go ahead and then, when the process document gets returned, then we can get explicit sign off from all the sigs and then move on um that will help unblock both. uh Does that? Does that sound like an okay idea.

D

Yeah, from my perspective, absolutely regarding your first comment. I think it doesn't necessarily mean like that. We will be blocking a particular feature because we believe if it's it's, it may be unreliable, but it may also mean that, like other features that are already there, that are owned by biasic aren't reliable enough, and we we want the sick to address the reliability of already existing features before they actually create a set of new ones.

D

I agree that like preventing, um like checking whether like um a new feature, will be reliable. Enough is a little bit more more harder, but I think we can do that with like proper processes too. Things like each feature slow but like I don't want to go to get into like details. Probably at this point right.

C

So worst case scenario is like cron. Jobs are bad, so we don't like sick apps much anything.

D

Yeah, I think we need a reliable like reasonable criteria. I don't think we we will be. We should be able to say something from like two years ago or four years ago, in case of like cron jobs is not reliable. You can't merge anything now. I think we need it needs to be something like if your very very old feature isn't reliable.

D

You have like, I don't know two releases or three releases to fix it, and if you don't do it by then, then we will block something, but that's some that's how I think about it. But yes, it's it's just my personal opinion at.

C

This point, uh so we would help by quantifying what is the threshold that is going to be acceptable for the work that the city is going to do. Okay,.

A

Okay, so uh I'm going to put a time box on this- maybe like eight more minutes of discussion um today, uh because there is one other uh item that I'd like to make sure we have time, for uh it, looks like aaron and then derek.

F

Hey you have to talk not as a steering member for the first time, uh so I just um I agree with most of this charter, except for the special powers thing um I I guess I bristle with the fact that this has been raised a number of times before the desire to block things. We've never done it. I feel like this is a more specific case of we want to force the project to pay down tech debt, and we need to find a way to incentivize people to do that.

F

I'm not sure if this is the appropriate way- um and I also question like why is it that reliability is the thing that gets to block stuff like? Why isn't it security issues right like? Why, wouldn't we say we're not going to contribute anything else until we've cleaned up the results of the security audit or test flakiness or whatever right?

F

So I- and I don't want to like- have that block the idea that we as a project want to start focusing on reliability, and there are a lot of things that we can add to the project to do this, but I feel like the conversation around, how do we focus as a project shouldn't be about a super power?

F

So I kind of am more interested in how we can help sig release kind of ship focused uh releases or we can focus our contributions. There um yeah, I guess that's all I'd, say.

A

Thanks erin uh derek.

G

Actually aaron, I really like how you captured that, um and so I think, a lot of the charter. I like around documenting what it means to be reliable and measuring our present reliability. I think you'll have to reflect a little bit on what aaron noted for jumping right to the the carrot and stick is the right outcome or not, but I guess we can iterate on that. The question I just want to ask clarify on is: um what's the intended scope of the working group?

G

Is it covering that which is covered in cube conformance, or are you intending to measure reliability across every sub-project in the sigs um that may or may not be within um what we might think of, as as conformance I? I read this as you're, focusing on reliability of that which is exposed in a cube, conformance suite, but um I want to make sure that that was an accurate understanding.

D

um I think that that's a great question. I wasn't thinking deep about it, so I think at least for the initial I would say that it's it should be things that are in conformance more or less yes, I'm I'm fine with doing making that explicit in the charter. Yes,.

G

D

G

Like if you do intend to have a stick right, oftentimes, it's because pockets of interest within cigs that can get um motivated by particular sub-projects. That might be outside of the scope of what you were trying to measure and to some degree you're trying to shift attention away from that. And so, when we talked about like great merge right powers, it's not meaningful if you can still merge in other sub-projects within your sig and you're, just kind of blocking merging in the kk repo or something like that. So details work out but yeah.

G

If you could just add some language. That says where you'd focus. um I think that's a great first.

G

D

Yeah, I think jordan just mentioned me um offline, uh that there are better features that actually destabilize, kubernetes and better features are enabled by default. So maybe we don't want to make it like only conformance um yeah. We probably need to discuss that a little bit more.

G

Yeah, I'm thinking even like things like I don't know, six scheduling has a descheduler component right. Are you intending to measure the reliability that I I doubt it right? I don't. I don't think performance is a first priority and so just kind of like clarifying um your order, but then, if the outcome was that a great superpower is going to be developed to prevent sig scheduling from checking into the scheduler but still merge into the d scheduler, um uh I doubted that as well, but either way just focusing on.

G

If it's add-ons or you know, the core release, binaries is probably sufficient.

D

Okay makes sense, sure.

A

So one question that I'd like to throw out there uh directed towards uh steering members. um We've had a lot of discussion. That's focused on uh the you know the special powers to block merges um outside of that section, which obviously needs some some refinement.

A

Is there any other uh questions or comments or concerns about other parts of the charter? In particular, I'm looking at scoping and stakeholders and.

A

Deliverables taking silence is a good sign.

A

Okay, um I've got about two minutes left if there's any other questions or comments that anyone.

A

Has okay great, uh thank you so much wojtek for um attending uh appreciate that um we can take those refinements uh back to the pr um and if everything looks good at that point, then we can um call about to.

C

To look at merging uh dim christopher, do you want to summarize what you would like wytek to do to the rock.

A

uh Yeah, so my under my understanding is there's going to be particular revisement around the special power section. um Looking towards noting that, like mechanics, have not been decided um that specific mechanics will probably need to be worked out with uh testing and release um we're also, it looks like there's still an open discussion point around conformance and what what the scope is of like what types of reliability will actually block uh merging if it's only conformance if it's something outside of conformance, um but I think those are like the key.

A

The key takeaways that I had um is there. Is that your understanding as well then.

C

Yeah sounds good.

A

Okay, great, uh thank you so much wojtek. um So we have uh one last issue that we're gonna discuss uh today uh looks like term limits for steering committee members uh nikita.

B

Yeah, um so just builder paris worked on it, a lot more uh which she had to drop off, so I'm just gonna walk through the pr, um so the pr, let's drop the link in the chat um documents term limits for the steering committee. We have discussed this pr in one of the previous uh steering committee meetings and we came to the conclusion that uh what's written as is looks good, but we also wanted to add a few additional things.

B

um So right now steering commit so like us pr steering committee members uh would cancel only two consecutive two-year terms, so in total they could serve two consecutive terms for four years and a lifetime of four terms. So, like a lifetime of eight years on the steering committee, we will not be considering uh the bootstrap committees and the initial election that took place which nominated folks, which electric forces for one year I think and terms that result in uh equal to a less than one year.

B

So this could be due to changes in company or, like someone decides to step down or for whatever reason. um So, in those cases, if someone is on the committee for one year or greater, their term would be considered in the term limits um measurement, but if it's less than one year it won't be. uh So this is what the previous cheering committee had decided. So I just wanted to bring the pr out here in case anyone had concerns, or if this looks good to go.

B

What do folks think.

A

So we had had a number of discussions uh about this in the last term of steering committee, um and we had decided that this is. This is probably a a good fair bar to set, but that we should probably wait until post-election before putting it in.

A

um I think that again, as we've, just like we've just brought in three new string committee members, I think we should probably not vote on this today, but I think we should probably add this to our um our our next meeting agenda um to actually uh review and potentially vote on um once the new members have had a chance to to kind of review it. um I think that the uh my opinion, uh which I've stated before but I'll just say it again, to kind of get any conversation rolling on this.

A

um The the bar that we've sat is is kind of a mix of like not wanting to um like basically wanting to give an opportunity for people to fairly serve terms, but also allow the project to set itself up, for you know healthy succession uh and being able to kind of pass the baton around to um different different folks.

A

So we have different voices, a different representation um kind of like at that highest level of um you know, office for for the kubernetes project, just to ensure that we don't get stagnant and people don't burn out.

A

um You know if you know okay, this is this is the limit of what I can do and I need to you know, set something up for that in such a way that you know the decisions that we make as a steering committee can uh have traction not only with the folks in the seats who made those decisions, but that those decisions could kind of like hold over time and that the project can change directions if it needs to at some point in the future.

A

um Any other comments on this today.

A

F

Yeah, I don't know if you want to do this after having served two consecutive terms, I think you really need the time off for what it's worth this this was. um This was part of what factored into my decision to move on, because I, I just believe like service rotation is extremely healthy for the community and it's really healthy for the individual.

F

So I liked what was proposed here for what it's worth.

G

Aaron, that's like your vision of washington's farewell address and I think it's a great way to and uh uh both your your both your terms on on steering. So I think, that's well said.

C

Thanks a ton aaron for all your hard work on the project plus one. Thank you.

A

um Any other comments on tournaments, um I'm just looking over the chat. uh Jordan made a comment uh that scheduling for next meeting sounds good to give opportunity for uh contacts or discussions.

A

Yeah, hopefully we'll be able to to do that um because again, when we're changing when we're changing issues like charters and elections and that kind of stuff for steering- and we should definitely have plenty of sober thought on the changes in their potential long-term implications.

A

Okay, if there's no other comments uh that brings us to the end of our scheduled agenda. um I would like to call out uh once again thank you to all the steering committee candidates. uh Congratulations to the uh three folks that were elected and uh an extra special thank you to um aaron and lockheed.

A

um Thank you so much for your your. You know your service on the project. It's it's been amazing, working with everyone, um and you know especially like I, I like to call it lockheed who, who stepped in mid-term uh to to to fill a fill a gap in our governance.

A

um That was, you know, really really super appreciated, um and it's made such a difference over the last six months. um Yeah these are for anyone that is is not a regular to this meeting like these are extremely extremely dedicated, hardworking, folks um and um they're.

A

Yes, you get you get a pension now.

A

There aren't enough words to express like how how much these folks do for the project, so thank you.

A

um With that, if anybody, if there's no other comments, we will wrap it up for today.

A

F

Everyone thank.

A

You so much happy monday. Everyone.