 Hello, folks. Can y'all hear me or is there a really bad echo? Hello, no echo. Yes, I was having a bad echo yesterday and I had and then today I still have the same setup and here we are with no echo. It's weird how technology works. Or doesn't work. Yeah, I didn't do anything yesterday. That's like the worst part when you're like I touched nothing. As I always say, someday I really want to see a Star Trek where they like dial up the aliens on the Enterprise. And the captain is like, Hello, can you hear me? And the alien is like, What? What? Are you speaking? Oh, there's an episode. Yeah. Oh, yeah. Yeah, he pulled that once. In the original series. Can you try turning your comm system off and back on again? Yeah, I'm just going to jump in and out of warp and we'll see if that clears it up. Well, wait, like one minute, maybe less for other folks to join and then we'll get started. Josh or Steven, you're also going to take it away at the zero hour mark while I ghost out of here to another meeting. Cool, cool. But we have some container D folks on the call with us today. Hello. Welcome to the container D folks. Derek, as I mentioned, on our last call came to contributor contributor growth working group. And was just kind of like what's this about. And we talked for a while. And we got here. So, welcome. Let me summarize and then Derek what I want to do. Actually, let's just do a round of intros because we like always usually know each other in this group. So we don't do intros anymore. But I think that's actually important now that we have half of y'all have not been here before. So, my name is Paris. I work at Apple. I do this cool fun stuff for projects with help with governance and contributor strategy. Josh, who are you? What do you do? I'm Josh Burkus. I work for Red Hat in our Ospo. And I got involved with this because among my many interests I'm a governance geek. Starting with the open office project back in 2001. Hello, hello. Hey, I'm Steven Augustus, primarily focused in the Kubernetes community. So do governance see things for a few places there. Also a dex maintainer and generally interested in just how communities get together and work efficiently. So I thought this was a natural step. Nassie. Hello. Sorry. Hey, I mean, for all, I'm multitasking and not doing it well. And I am on the Google open source programs office and I work a lot with GRPC, which is a lovely CNCF project that everyone shuts off and has an adorable mask. Maybe. Yes. A mascot is phenomenal. Carolyn. Carolyn Vence Lake. I work at Microsoft. I used to work on Kubernetes a bit. So I work in the broader community working on a CNAB cloud native application bundles and Porter, which was just submitted to CNCF. And I'm here mostly because I usually end up writing and doing a lot of the contributor growth activities on any project of mine. So I just have lots of opinions. All right, let's see. And then now we're getting into the container D team. Derek. I'm Derek McGowan. I'm the software engineer at Apple maintainer on container D for a while now. I also do some other stuff on like OCI as well. Sebastian. Hi, I'm Sebastian. I work at Docker and mostly work on the Docker engine. Also help maintaining container D and whatever open source I can find my to get my own song. Oh, that's cool. Hey Sebastian. And then Mike, that wraps us up. Well, I'm a maintainer on container D did a lot of the original work with land towel on the CI functionality that's in container D now. It'll be default plugin. We're integrating it into container D container D in the one divided release. I worked on operating systems that blue screen of death behind Sebastian. I did some work on that. It's not be on my work. I worked on OS OS to OS three and NT the original version. So you'll find my name down in that deep bowels of that code. Welcome Mike. All right. Thanks everyone for doing that. We never really do that because it's usually just us the first the first half of that crew. So the summary that I took away and Derek I want you to actually take it away from me is y'all want some help with contributor growth topics but specifically in some of these areas one role identification and building sounds like you also have some probably roles already in mind maybe even have, you know, have built off that from the last time we talked. And then also community management strategy and goals to maybe help the help maintainers out figuring out how to actually sustain that part of the function and then ultimately the outreach for that said thing. So whether remember we talked about whether or not it's like a group of people to help out with community management, a person, some kind of like strategy and or goal setting there. Did I summarize that right. Yeah, I think that's accurate. I think in the past container D's had some of that but as people have kind of moved on and as even the maintainers have like, which are different companies and stuff like we haven't had like a full time community for a couple years and yet it's kind of hard to like keep up with like other projects and such as a graduated project like keeping the same level of visibility. Yeah, for sure. And talk so actually go into the past a little bit so you said that one point you had a full time so one point full time. What were some of the other things that you maybe used to have as far as the community management side that you don't necessarily have any more. I think a lot of the roles we have today just even just like interfacing with CNCF and like organizing like who's speaking at different conferences and the different like speaking opportunities. Like keeping track of the people who are coming in and interested in container D and like mapping them to either the right people or like helping them like it started and stuff like all that stuff's been done directly by the developers, which it's kind of hard sometimes like stuff like falls through the cracks or like, we really have to be on top of anything. He said so for media to I think at one point right like you're y'all are doing your own tweets and stuff like that to you right. Yeah, I do most of the Twitter work. You like it don't fit. All right, and then let's go into a little bit more of the background around the roles do you and because I can't remember from the conversation that we had before. Do you currently have any other roles identified outside of like the standard whether it's maintainer or what have you do you have any tell us a little bit about the roles that you have. Yeah, so we have three roles today so we have maintainers, we have reviewers and we have a new security advisors role reviewers and maintainers are the more active roles. So, the difference really is just maintainers are almost like part of our governance process in terms of like voting on issues. And then actually like with right access for doing merges, but otherwise like the roles are pretty much the same so like it's just the active part is just reviewing code for both of those roles. But yeah those are the only roles we have identified today. I have about 800 more questions so I'm actually going to open it to everybody else though so anybody else want to day into either these two areas, either asking questions or either offering suggestions or advice. So, yeah, I'd love to know like what's working, or what isn't working today, it sounds like you have some new roles. How long have you had the roles, are they doing what you intended, and are there places where we could offload, or where you could offload work from that's classically divine and one of those roles into a new role. I mean, I think my goal is that I want to have a lot more reviewers so we've added the reviewer role for about a year or so and a Sebastian may know better about, we added that but we've tried to grow that number. Because that's really like what allows our project to scale in terms of like review and especially project like container D something that's really low and has high stability requirements we want as many people kind of looking at each of those poor requests as possible even for the small things. So that that's one of the things that I think we could do better at. And the others just like, I think, kind of at the project management level and just so for example like, there was some issue around not having like a security MD and like our container D project even though we had, it's like a GitHub requirement. And even though we had kind of listed like oh here's how you list things there was some issue or somebody was trying to file something. They couldn't find it. And see and see if actually kind of got involved and said like hey you need to have this like specific file and stuff like that. And as maintainers just like. I'm sure like, we don't know like or we don't really care too much like how stuff's like laid out from like a, like a GitHub perspective but if that kind of stuff's like important. Like, we need to know about that kind of stuff and like preferably have that stuff proactive like if somebody has some like requirements for how that stuff is laid out like something that was like known to us. We're not actively engaged in finding the new checkmarks that we're supposed to be filling in right in container D. So we're missing that level of communication. Right. Additional requirements to be a CNCF right maintain project. I think for the reviewers part and that's something I see in many repositories is that I think the occasional visitor of a repository considers the actual main thing is to be responsible for doing the reviewing. And I think in general it is people should be become more aware that basically anyone should be able to review whatever repository. I mean it's open source so input is always welcome and input is welcome. I guess if you get more people that are aware of that and maybe get involved into in that you can also pick actual reviewers out of that as to. Hey, this person is a great reviewer. I've seen a couple of reviews of this person on some renewable requests. And I trust this person to be doing actually proper review but getting them message out maybe one thing that I think could help the project. Do you have documentation on how to do a review for container D. That's a great one. Derek. We have anything other than just say review. We generally make sure that the people that are, you know, getting the review tag, have that capability already as opposed to, you know, giving them a set of instructions on how to make it. Right. Yeah, but we do give a lot of individual, you know, one on one kind of efforts to try to get people to review step or maintainer stuff. We also have what Derek mentioned, we have experimental projects that are, you know, non core projects, you know, sub projects that are extending and enhancing community but haven't, you know, been brought into the main main core set and in those we have their own maintainers. They're not core maintainers that are sub project maintainers sort of like Kubernetes, you know, SIGs and then, you know, and for types of projects. So, so few questions falling out of that to to kind of tag on to what Josh was saying. Documentation is huge contributor documentation if people. Things are a lot more accessible if people are given explicit instructions on how to do them to would be a question on how you select reviewers in the first place. Is it just kind of because sometimes it's like, you know, finger in the air like they've been doing stuff for a while and it probably seems like the right time, but having explicit instructions about how to become a reviewer would be good and then you mentioned one on one sessions and I think I think all of us do one on one sessions to some extent, but something that we've, we've seen to be pretty successful in the Kubernetes community and and Paris is the queen of this is exactly what she just said in the in the group chat video yourself doing a review are doing one of those one on one sessions and make that available on some YouTube playlist. Right that that becomes you know that scalable right because every time you get a new request for hey we were wondering about food right record a video on food and then put it up on a playlist right and that's you answering the question for however many to be to be fair we do have documentation to describe for you know coming on developers and documenters how they can, how they can make modifications and changes and review stuff. And we do also have contributing guidelines for the project is just not, you know, to the level of detail that you're asking about. Layer two of project maturity level contributor documentation, I think that's the, that's the way you have to look at it now like you've grown to this level of contributor documentation as a project and now you need to grow into the other layer, and that other layer is the like the documentation for your reviewers and for your approvers and for your maintainers. And the reason I was asking that is just that the documentation serves an important purpose beyond instructing people. I'm almost instead of instructing people because realistically, it's hard to cover everything somebody might need to know in terms of doing an actual review. But if you have a piece of documentation that says, here is how you as a contributor can do a review. That codes people into the fact that they can do a review follow me because your biggest barrier to getting more reviewers is that even people who contribute code to container D. Don't think that they are qualified to be a review. Yeah, I think having more documentation around that is definitely one of things we're looking to get guidance from this group, especially because like, the documentation we know works for the people who are involved, but we don't have kind of a good sense all the time, especially like trying to step out and looking at that from the outside. Like we know our documentation is not great, but we're not quite sure how to fix it on both like a process and like a technical level. I think, um, like it's kind of like the car before. Mike Mike was the culprit on that I was like looking at everybody that like, no just kidding. I feel like before like before we do the outreach that you need the people, like we should have at least some of the skeleton documentation so that like while we're, when we're doing these mega outreach efforts that say like oh container D is looking for new reviewers, they'll have something to like go towards and be guided to. So, from a documentation standpoint, I really think that like videos at this point are going to be your best friend because stuff that you're already doing and already in your flow, whereas like the writing of it is probably like the more difficult piece. And you can always link to your YouTube's and stuff from your technical documentation inside of your contributor guide and whatnot. So I think that's like, from my opinion I feel like that's where you should start is like what do I do like internalize it kind of like what do I do as a reviewer. Right, like what do I do is it as an approver that's any different than Sally down the street who's a contributor. Right. I would say depending on your technique like not everyone is a visual learner or visual teacher I guess. So even before doing the videos if you want to step back and say like, what does my day look like. Right, if I'm reviewing a PR for container D if I'm like doing maintenance work right like what does that look like do I do I stare at the do I stare at a project board. What do I do. First, right do I do some GitHub queries do like what's what's your process right. Even before you get to the point of like reviewing a PR, right and start to and then look at your documentation say is that documented. Right, because those could be gaps that people could potentially be filling a lot of the, the times, we find that a, that is an excellent, that is an excellent, excellent video. how to be a badass code reviewer to take a look at. So recently in SIG release in Kubernetes, we brought on a program manager. And it's something that we have been sorely lacking to say it nicely. I think it's one of the first times that we've done a explicitly named role like that in the community. And so Lori Apple has been just jumping everywhere in identifying things that we make assumptions on. We make huge assumptions on. And it's just because they're part of our day-to-day workflow, like as an approver or as a SIG chair, I'm going to do certain things, right? That may be happening in the background, like if it's sorting project boards, if it's adding new milestones, if it's pinging this person via DM to make sure that they're doing X, right? We have to come back and say like, is that stuff documented, right? And it may feel like it's a lot of the work that could be done by other people is assumed to work, right? It's work that you're already doing and isn't written down anywhere. So I would step back and maybe have a maintainer's meeting and just think about like what you do day-to-day and see if it's documented. Yeah, it makes sense. Yeah, discussing this within or kind of within the maintainer group. Yeah, it's definitely hard like getting everybody together, especially with like recently with like time stuff, like but yeah, understand there's no like quick recipe for some of these, but we just want to figure out like a good place we can start in some early progress. Anyone else have questions for, I do. So that's why I just don't want to take the floor. So other questions for Container D folks? Well, one of the things that sounds like is a major need is that you need to attract some volunteer, contributor, management, advocacy, whatever contributors. That is these are things that used to be done by paid staff from some company or another. They're no longer done by paid staff. And now you need to figure out how to get somebody to volunteer to do it. Yeah, yeah, kind of we don't necessarily need people coming in just contributing a bunch of code. I mean, or at least like code contributions and code reviews should scale, but like, yeah, right now I think one of the biggest laxes, yeah, not necessarily those code contributions but those other forms of like the technical contributions and helping with the process and stuff. I think that's right. So, okay, have you put out any kind of a call for that on like your user forum, mailing list, Slack channel, whatever it is? What is it anyway? No, not explicitly. I mean, we have Slack and Twitter, we don't even have mailing list. Yeah, well, I mean people of all kinds of different channels. So, I feel like the community, whoever is helping out with community could also help out with that as well. Like the channel development and communication development and stuff like that. This is Phil, sorry. I stayed quiet while I was on the phone because I didn't know how good or bad my connection was gonna be, but. Sorry, no, I thought that was April who was also on the phone. Oh, no problem at all, no problem at all. But just kind of, I think this may fit here, but, you know, container D is an interesting project because I feel like there aren't as many people all that interested in contributing but who love to play around with it as an API driven container runtime. And so, you know, even our user base is like kind of fragmented as a negative word, but I don't mean it that way. But, you know, there are a ton of people who just use container D because it's a CRI pluggable runtime and they really don't care. It works, it does what it's supposed to do. But then there's a bunch of people who end up in the container D Slack channel who are trying to build some crazy tool and doing really cool things. Those seem like the people if we have the time or energy, you know, they're kind of playing in the code, so to speak. But yeah, that's what I've been trying to think about. And again, you know, most of us are not, well, I can't speak for all the maintainers, but most of us have, you know, day jobs that aren't 100% driven to let's make container D a better community. So I don't know, that's an area I'd love to investigate is, you know, all these people that like container D is kind of the Swiss Army Knife API. You know, is there a chance to get them more involved? I think building some kind of outreach group for you all, it should probably be like a priority, whether it's outreach, whether it's like contributor experience and it doesn't need to be, you know, 20 people, you know, it could be a handful, it even could be, you know, some of your maintainers who also already do this stuff to like bootstrap it. But like Josh is saying, I feel like putting a call out and explicitly saying this stuff. Like I watched your intro and stuff for KubeCon and it was awesome and I loved how you were talking about more contributors. Like the next intro that you do for November because it's right around the corner, you should explicitly say this stuff. Say we're looking to grow the community in this way, like we need help with the following things and just be very explicit about your intentions, right? And see what happens. I think building that out though, like whether it's like I said, a community manager, would be super helpful. And I can give you some like pros and cons. I can like do a doc for you with some pros and cons of kind of like each group versus like person and kind of go from there. All right, yeah, that sounds good. I mean, we've been, we have a Zoom channel. We've been looking to utilize it to start something regularly. But I think what you said by having something that's explicit around saying, hey, we're trying to grow the community in this way and we're having a meeting that's specifically about this. Might invite the right people to come. I mean, maybe nobody shows up, maybe people do. And the thing is like, if you have to create the space for the work to happen, right, just like a work work, like you have to say like here's this time and space that we're going to talk about this specific thing. And that's kind of what we have to do with community as well. Like it's just one of those subjects where it's like, you know, you're going to do the code and you're going to do everything else first and like that's the priority. But you need to create the intentional space for people to want to like come and talk about it and feel like comfortable talking about that thing there. Good point first. I would say, you said you don't have a mailing list. I would create one ASAP just for the sake of like, if you can't schedule a meeting yet because your schedules don't allow it, at least you can start having that asynchronous conversation with people and start generating ideas for what might be in those meetings. Like community extensions and maintenance with CNCF type project or type requirements, that sort of stuff. Yep. And I was taking some notes too, by the way. So container D folks, I have some notes from and I think Stephen has some notes as well. So see y'all later on the flip side. Container D folks, thanks so much for coming. I owe you stuff and we'll I'm sure catch on the slack waves. So. For sure. Thanks Paris. Thank you. All right. I'm also going, sorry about that y'all. I'm actually going to not the container D meeting. Whatever meetings you're going to, I'm not going to that one. So I'm going to jump, but I still see Derek's on. So you might want to continue the combo. So see you soon. Later. Yeah, we've been having a discussion about setting up a mailing list. We're in the midst of a few different things on that realm, but yeah, what we're trying to figure out kind of at the higher level is yeah, how we schedule these meetings and how we get the word out. The problem with like mailing lists is they're kind of hard to bootstrap. So like I said. Yeah, I wouldn't start a new channel for this, honestly. I would say start this discussion on whatever channel your users, whatever channel currently has users on it. And if it's not, you know, if nobody's getting annoyed by it, honestly, keep it there because users tend to drop in and out of subscribing to things and having your users see an ongoing discussion on that channel about doing advocacy this or event that or, you know, contribute your documentation this other thing, kind of gives them the idea that this is a place for them to participate, even if they're no good at hacking go code. Yeah, yeah, I really like that idea. I think we're definitely going to follow up on try to get something scheduled that basically where we can continue talking about this and about the community. We definitely have our Slack channels and Twitter for getting, I think we have pretty good reach from there. But yeah, we use it kind of sparingly because we, well, that's just our style. We're not really loud vocal in our style, I guess. So how do you announce releases today? I'm curious, or pre-announcements? Oh, I mostly use Twitter for that. Gotcha, gotcha. I make a suggestion about getting people even know your mailing list exists because I've had to go through this a couple of times because you've already got people like following you on Twitter or following you on Slack. You may want to take advantage of a couple of different places where existing users are and be shameless about mentioning the mailing list and do two things. One, repeat yourself. So like, don't just mention the mailing list once because people mute Slack. You know what I mean? They don't check Twitter for three months because Twitter sucks right now. So like, repeat yourself. Every time you do a release, go, hey, here's a mailing list. Or every time, you know, every so often in Slack, just go, hey, are you tired of Slack being super noisy? Do you want something in low traffic? We're just gonna announce releases, interesting features or blog posts or whatever. And then the other piece of it is, say what's going to be talked about on the mailing list, like what you're gonna type of topics or things you're gonna be pushing. So people have a reason to sign up for it so they understand why they'd like to and try to give them a little push to go over there. Cause like a lot of people, they sign up for your Slack channel but then like 80% of them mute it, things like that. So like right there, that may be like, that's why I think we got everyone to sign up for the mailing list just for that. Cause the signal to work noise ratio was like so much better. And just giving people things like this and then repeating it often cause people don't check these various places. Like throw it on your read me, throw it in your release notes and I could help put it in a whole bunch of places and you're more likely to get these users that you've had for years, realize you would have the mailing list. Otherwise it's really depressing cause you make it and you're like, ta-da! And then you have like five people. And they're all your maintainers. Yeah. Yeah. The other aspect is there's, I noticed a lot of the meetings are going into like a kind of mega CNCF calendar. Is that what other projects and stuff are doing to try to get the word out when they do have events other than just like spamming people but like actually getting these things into people's calendars. Like what's the best way for doing that? I love the mega calendar cause I can just look at it and know everything that's going on in the CNCF world. And then I don't have to like subscribe to five calendars. I don't know about anybody else. So I think part of it is also that as a graduated, you're graduated, right? As a graduated project, the CNCF provides things to you, provides resources to you and try your best to take advantage of them. Cause they're resources that are meant to solve exactly these kinds of maintainer issues, right? So being able to present yourself to the community, being able to, there are some program management tasks. They do help with websites. I don't know if you're utilizing the CNCF service desk right now. Yeah, we do that quite a bit actually. Yeah. But yeah, I would totally subscribe to the mega calendar. I don't always look at it, but if it's there, right? You can't say that it wasn't there, I guess. Yeah, I mean, I'm definitely not against the mega calendar. It's really good for like discovering like new events and stuff, but I wasn't sure if there was any, or if other projects were doing a different method or if they're had issues like just getting people to either subscribe to the mega calendar just for one event or an approach like that. So yeah, calendar wise, it depends on what it is. If it's something that I'm actively contributing to, I'm probably gonna be on like the mini calendar of the individual group, right? But like knowing that, oh, container D is having a discussion about this thing today. Maybe I wanna drop in, right? And having that information kind of at hand. Another thing I would say about the project phases, right? Is that for Kubernetes at least, right? A lot of the documentation that gets generated across many of the CNCF projects, they use Kubernetes as a template. I would say that as a graduated project, people are also going to be looking at you as a potential template for their processes. So I would say to one of the, I guess one of the gentle asks would be like, think deeply about your processes, right? Because you didn't just get to a graduated state for nothing, right? You worked at it over several years. So there are lots of good things in your process that maybe they just aren't documented, right? Maybe like it just works so well between the maintainers that you have that it's taken to be assumed, right? And that's something that could help a sandbox project and incubating project. So take some time to think about that stuff deeply because you will be the template for several other people. Yeah, I definitely realized that. Like we've definitely looked at some of like the Kubernetes approaches, but in many ways, like Kubernetes is just a project with a much larger scope. Too big. We don't. Container is kind of in a weird spot because like we almost have like the same number of users in terms of like if you're running Kubernetes, you're probably running container D underneath it. But the scope of the project is so much smaller that while number of users will be high, like the number of people who actually like come down and like really care and get involved at this level, we expect it to be smaller. But as the users grow and become more sophisticated, we just see there's more and more interest. So that's why we're trying to scale a process, but we realized that like in some ways, the process is unique, but in some ways, like yeah, a lot of other projects are in the same kind of level. I'll say from experience working on a lot of sort of backend infrastructure projects, libraries basically, because essentially it's what you are, right? In terms of your place in the ecosystem container D is a library for the cloud native ecosystem. What you're really looking for in terms of like a volunteer, community manager, whatever you're honestly looking for one or two people, right? You're not gonna get a whole bureau because you never do for that kind of a project. But if you have one or two people who really cares about that and has some time they can put in and put in their 20% time then that will also probably be good enough. Yeah, I agree. I think we consider kind of CNCF as kind of that bureau or like that larger body associated, but yeah, the number of like people involved like is smaller. And I think that's why yeah, we're going to CNCF to say or to ask for help in like generating these roles or in some cases like just advice for like documentation and stuff or almost stuff that could be funded as well if we need that. Yeah, documentation, I think you might be able to get some direct help with because they have staff and a contractor network. But one of the things that I honestly think you need to do is that you are going to need is somebody who can be your interface for CNCF. As in CNCF as a bunch of people and from staff, they're good about fulfilling specific requests, you know, I need an X, but somebody needs to write up that I need an X, which is not, you know, it becomes time consuming if you're a list of things that you need, which it is, is extensive. For a bunch of the projects that are primarily sponsored by Red Hat, I do that and it's a big time consumption, right? Even if the staff is executing the actual item, communicating what needs to be done, you know, because you're communicating with somebody who has no prior involvement with your project, right? So if you say, you know, hey, our documentation UI needs an overhaul, they need a lot of information on how and what you're actually trying to accomplish. Yeah, we had a little bit of an exercise for that earlier in the year and unfortunately it fell through, but yeah, we had somebody who was interested in doing some documentation, but as contract work, but submitted something through the service desk and basically like the task was work with the, work with the individual to come up with a very specific contract, which, you know, it's kind of out of my expertise in terms of like, I don't know what like this sort of like work contract looks like and like going through all of these like specifics. So yeah, hope with that is definitely, I think, especially like experience with that. Yeah, I mean, like we can in contributor strategy, we can help a little getting it started, but ultimately you're looking for somebody who cares about container D. Well, yeah, I think from the same point of having people come contribute that type of work, not necessarily having to do the documentation, but being able to actually like work with CNCF to like define what the documentation needs to be. Sorry, I need to drop pretty soon, a couple of minutes. So I'm going to drop in and actually give a future attraction in here. One of the things, sorry, I joined late and you know, hello, surprise. One of the things that I'll be working on with the tech writer team is starting a meeting that's available for projects to be able to come in and join and talk with the tech writers and kind of get a sense about like, if we were to be able to have a structure, what would that structure look like? And I think Derek, that might actually be something that would be helpful for you. So watch this space for more, probably like striking out in like September for that. Yeah, it sounds great. Yeah, I figured people will actually care about this, but I'm like, oh, hey, this thing that I've been working on this week, you'll care about. So, yeah, I will now continue to lurk again. Steven is laughing at me for rising up out of the deep. Like, hey, I got a thing. Oh! Yeah. I mean, it is perfect though. No, I mean, it is perfect because like this came to me like Monday and I've been working with the team like through, like, I mean, it's only Thursday here, but being able to like track towards, man, if we were to be able to have a touch point with some of our tech writers, we would have a better sense of what the projects need and what the tech writers are actually here for. Man, wouldn't that be cool? Yeah, I think the frustrating thing about that, that interconnect is that a lot of the times, having to write the documentation is one thing and potentially farming it out is another, but like a lot of the times you are the person in the best position to write the documentation or like dump things out of your head. And yeah, someone without context on the project is not going to be able to do the same level of depth as you will. So yeah, that can be a frustrating time when you have to sit down and do documentation, especially if you hand the task off, because this has happened several times to me recently, if you hand the task off and it's not clearly defined and someone who is not familiar with the area starts doing the documentation, gets to the point where you're like, it's taking me more time to do this review than it would have to actually do the documentation myself. That's one of the things I'm kind of thinking about is what would happen if we put the tech writers in a position to be a better documentation coach? Right, like how do you pair with like the, there's somebody else to be able to help keep you accountable but you don't have to be able to make up the structure from scratch. You can just put in, hey, I know this thing. Well, I think the thing we'd want most from like tech writers, not to go too much into what this meeting is gonna cover, but like when people come in and contribute and then tell us exactly like what their frustrations were, so like we've had people go through this experience and say like, oh, like I got Continuity to work but it was way harder than I wanted it to be and I wrote this documentation for like, here were all my frustrations and stuff and when a tech writer does that exercise, tends to produce really good results as well as show us where we need kind of that deeper technical, like the design and architecture stuff, like that kind of stuff. Yeah, I would definitely expect the maintainers to do but in terms of like those documentations like getting started and stuff like that, like the maintainers aren't the best people to do that because we're not getting started and we don't have a good perspective. So like, yeah, having technical writers go through a getting started and be like, this is what sucks about your documentation. This is what like I couldn't find anywhere. Like, yeah, I think as maintainers we're definitely realized that's on us to like, go and fix that. You mean Kelsey's old Kubernetes the hard way? Yeah, that one? Yeah, a lot. Yeah, go ahead, Josh. Well, no, and honestly the whole reason why he wrote that was to show everybody in the Kubernetes project exactly how hard it was to set it up from scratch. And that that was something we needed to fix. As well as teaching people about the internals of Kubernetes and how the various pieces actually interacted which is an important thing to know if you are going to be an expert. But a big portion of that was just to show what was wrong. Yeah, I think part of that is information architecture, making sure that the stuff that you need is actually in the right place. So like what's cool about that repo is, like one, it gives you a very clear disclaimer. I think a lot of people use it as law and they're like, why couldn't I do X? And then it gives you a very clear disclaimer that it's not something that's supposed to be done for production usage, right? It's meant to display some of the building blocks of the project. But what's really great about it is it does aggregate all those building blocks in the same place. So like you're starting to think about that stuff and it starts to push you out into different areas to explore that, as maybe a newer contributor, like I had mentioned this on a meeting and someone was like, I think it was actually, Celeste is one of the technical writers for CNTF. So I'm gonna mention like, well, that's not where I would look, right? So like as a contributor, as a contributor to Kubernetes, like if I'm looking for something, my first step is not to the website. My first step is to like the community repo, right? Which is a totally different ingress point, right? And you may not know about that until you hit the website, but from the website, is there a clear way to get to the community repo? And like, so you start thinking about like how people move through your process and, you know, for like SIG release, SIG release has its own repo for documentation, right? That like we lead you from the community repo into our repo, right? Because we know that everyone who's focused and our maintainers, reviewers, approvers on that content are gonna be living in that repo anyway, right? So like, yeah, I would say think about the experience, think about the maintainers experience too. There are some things that probably frustrate you about your process day to day. Those are things to start writing down to. I would say that I do agree that container, container D is kind of like cloud native API, right? It's the, you know, it's like the indirect module import, right? For a Go project that you're thinking about. So the, I would look to people who are, like if you take dims as a great example, right? Who kind of, you know, primarily works on the Kubernetes project, but also dips into container D because it's a dependency. And see who of those maintainers or who of those like, who of those transitive contributors would be interested in maybe becoming reviewers, approvers, eventually, in your repos. Yeah, we do have dims on board. He's been really, really helpful. I have to drop off, but I appreciate everyone's time. And yeah, I actually got a lot of really good suggestions out of this, so appreciate it. For sure, for sure. All right, thank you. Later. I was gonna go over some of, could we have a bunch of pending documentation PRs that people need to review in LGTM, but we have also lost most of the people who would review in LGTM those. The, so. I would say maybe we just shoot a note out to the list. There are four open right now. Looks like the what is governance one has quite a few comments on it. And just a request to do reviews, right? Yeah, I know that's one that I need to look at and I haven't, because life, but. Same, like I'm like wagging a finger at myself. So like now that the, so I mean, most of my time was like Kubernetes 119 release and that just got out of the door. That little thing, come on, Steven. You can do that in your sleep, right? 18 weeks are, I think our longest release cycle in recent time, so. Yeah, have, you know, you might. Congrats on that, by the way. Yes, congratulations. Thanks for getting that out. You might consider for your own sanity taking a cycle completely uninvolved. Just a suggestion, speaking from experience. It's, yeah, no, I mean, it's, it's masochism, right? Like there's something that I really, really love about the, I don't know, it's beyond the technical, I think that we're, you know, we're starting to really get deep into some real process problems that have existed for a few years that are related to tooling as well and starting to like fix them. So it's steady as she goes for a little bit on that end. I'm like, I'm hoping to kill Anago by 120, by the end of 120. But I think what I love most about it is that they're, it's just like where you see a lot of contributors start, like they get tossed into the fire of the release team and then you're like, oh, now go free and go do this thing over here that relates to it and seeing that happen every cycle is just, I don't know, it's kind of rejuvenating. So, but yeah, you're right. You're probably right. Given that, like you're running for, you're in committee now too. So there are plans depending on, you know, depending on what happens, I have contingency plans, so. You can always come help us with the GONAs. We're trying to, you know, get everything working with Kubernetes 1.16. So if you wanna go back in time, you know. Gotcha, gotcha. So I will say that if you're on, so what's the project called? GONAs, it's the game servers on top of Kubernetes. Gotcha, gotcha, gotcha. So if you're, I will note that we're planning, August 28th tomorrow is the cherry pick deadline and the final release for 1.16 will be September 2nd. Okay, cool. A heads up that. Good to know. It's starting to move out, it's moved to the end of life. Good to know. Okay, the, yeah, but if we can get those things. Review the things, there are. Yeah, get the merch. These are all advisory documents. Yeah. They, you know, they don't have to be perfect. As long as there's nothing egregiously broken about them, we should just go ahead and get them merged. The, oh, Carolyn and I also tagged you on another issue, which is in the DevStats repo. God. Me or Steven? Sorry, Carolyn's gone, nevermind. Oh. So. Would you mind linking that if it's for me or whoever it's for? No, I didn't, but I'll share it with everybody here, which is just that when Dawn was preparing the contributor health document, we realized that there was a rather ginormous hole in the data supplied by DevStats, which is nowhere is there a graph of your number of contributions or number of contributors. Which seems like a rather major omission and I spent a long time in the DevStats saying there must be something like this somewhere, but there actually is not. Oh yeah, yeah, that'd be really good. Cause she was referring people to the overall CNCF dashboard, but that just gives a current count. It doesn't give trends. There's no ability to break it down into different segments. So, the, and the reason why it's not there is it's not, it was not considered a useful graph for Kubernetes for various reasons. And the, because mostly because honestly we're not, in Kubernetes we're not worried about tracking our overall number of contributions because it's huge. Exactly, and it's usually pretty Kubernetes-centric. Right, and so most of the CNCF project dashboards were just copied as a subset of the Kubernetes dashboard. And I think here we're seeing one area where that is not the correct path. Gotcha. But I want everybody this touches including Dawn and Lori and Carolyn to actually sign off in the definition before Lucas doesn't even work on it. Since what I don't wanna do is create a chart and then have him delete it and create another chart. Just kidding. Yeah. Yeah. It's just always anytime, if you need to request something with DevStats for contributor growth or whatever, always make sure that Lucas knows when you're still discussing something because he will just go and do it. Do it. Yeah, yeah, yeah. Yeah. All right, so do we have, so one interesting thing it's, we don't have time for it or enough people for it, but the conversation about the STO Steering Committee that cropped up on the TOC list, I know that that's, yeah, I think that this is the place to have that discussion. Well, I mean, I'd like to, I was planning on actually inviting people to the governance work group meeting on Tuesday. Yeah. Because it's where we discuss those things. I am just really not clear at this point what Alexis wants because I was like, if this is your whole thing of let's have projects have a steering committee instead of meeting other governance requirements. I'm like, I'm like, I'm opposed to that. And he was like, no, that's not what I want. Yeah, I think. What are you recommending? Yeah, I think. I would just like to know what the TOC wants that I've been wanting to know that for a while. Yeah, I think it was a lot of people just talking over each other in that thread. I think what we want is to have the conversation, right? Is it a good idea? Like, is it a good idea? I think is one of the questions on the table. Right. But didn't the TOC already review the steering committee proposal and vote no? Not in a public meeting, as far as I know. Amy, do you know this? I think we've lost her. She's probably doing two different things. Because I just thought that it had already been resolved that they decided to not. I thought it was in one of the threads where someone had said like, they decided to not mandate it. It is not actually resolved. This is currently an open discussion item. Thank you, pardon. Sorry, I was in mute. So, yeah, I mean, I guess there's two different issues. Number one is, should the CNCF recommend that all projects have a steering committee? That's question number one. And the question number two is, if a project does not have sufficiently varied maintainers, is having a varied steering committee sufficient to meet graduation requirements? So there's actually two sort of separate questions. Yeah, so to me, I think, you know, part of it is I, why would we even look at a steering committee? Like why would we even look at a steering committee if like we were still thinking about what it means to be a maintainer, right? So even the earlier discussion with Container D, you're saying like this is a graduated project, right? And with a lot of potential that are concerned about overall project health, right? And it sounds like part of that path is building reviewers, building approvers. It's the same problem we have in Kubernetes, right? Building, continuing to build those people across the ladder, that's what would seed the discussion for a steering committee in one of those projects. I don't see, like, I think it's like, is it a good idea? Do we have places where we need to fill it with more structure? I think a lot of these projects do not have that requirement right now. So it should not, I don't think it should be a requirement personally. Well, I also like the Istio steering model was done for a specific reason. Yeah. I wrote it, it is, it was designed for, so this will always be my baby. It was designed for, you know, to reflect the fact that there were going to be these corporate, you know, companies that are contributing devs. And here's a spot to ensure that those folks will always have a say in, like, marketing and the administrative ops kind of stuff. So I don't see that being a solution to the diversity maintainer issue. Like, that's, to me, I don't think that a project that had that kind of a steering model would somehow pass graduation if it still was just one maintainer company. Because those folks that are on steering, for instance, I was on Istio steering when I worked on the project. Would I be able to keep the project going if every other maintainer decided to, like, move to an island? No. So, hang on, I know we want to say more stuff but we're past time. Yeah, we're past time. Yeah, so I'll reopen it, but one of the things you should know, Steven, because I know you're aware of this, so we had an entire meeting about this, governance working group meeting about this. And Alexis was invited and chose not to attend. And out of this meeting came our recommendation to the TOC, which is that we said we didn't think it was a good idea to recommend that all projects get a steering committee. It's appropriate for some projects and not for others. And that we recommended against using steering committees to fulfill the multi-organization requirement. Yeah. Yeah, that makes sense. Because our attitude was, if the maintainers all work for a single organization, it doesn't matter who the steering committee works for. Yeah. And it would make it harder for the CNCF TOC to understand what was going on with the project. So, and I'll admit that I have a significant amount of impatience with him specifically because we invited him to discuss it and he was not interested in discussing it. We asked him if we could use his write-up in contributor strategy documentation and he said no. So this is not a dude who is interested in collaborating. I think we should reserve some judgment especially on a recorded call. I think that discussions on the TSE lists have a tendency to get, depending on what it is, has a tendency to get pre-needed. And I was kind of getting ready to pop the popcorn when I saw the SDO steering committee subject lines. I was like, I need to read this later. But overall, I think it is a discussion that should happen here, right? If it's governance, that's cool. If it's us making a recommendation, it should eventually make its way to this meeting or to some recommendation on our repo because ultimately what we're here to do is kind of help the TSE divest some of the energy that they take in fielding those requests, right? Yeah. If you look at the leadership document that we have there, Dawn wrote in her own words, recommendations around steering committees. Mostly it's that it's appropriate for some projects to have a steering committee and a very short version of here's how you would go about getting one, yeah. And I think that if we haven't done it already, we need to make very clear that our discussions and recommendations that we make are exactly that recommendations. This is something that we're, we run into in, we want to help, but we don't want to be on the hook, I guess, for a failure of one of those recommendations necessarily. So it's something similar that's happening with, if you take the Kubernetes working group naming, right? Where it's like, we want to make a recommendation that gets approved by steering, right? And that becomes like, well, okay, now how do we execute that recommendation across the project, right? As opposed to, well, this body of four people decided that we were gonna change all the language in the project and what's going on with that, right? Cause we get a few questions like that and we have to make it very clear, like we are making recommendations that eventually will hopefully get approved by a higher body, right? So I want to make sure that we have a bit of like a lever to step back for my recommendation. Yeah, well, one of the things we haven't resolved is where the TOC approved material is going to live, right? So far we're just putting everything into our own repo with the idea that everything in our own repo works in progress. And one of the open questions that we have open as an issue in our repo is, where are the pieces of material that the TOC approved going to live? And nobody seems to have an answer for that. That's the same thing we have to do for naming too. We're like, okay, we're gonna keep it in this little sub-directory that we have, but like my personal feeling is that it lives alongside the style guide, right? Something contributor guide documentation. So it's very clear that it's like, okay, this is a recommendation that has turned into law or something or the general suggestion for the project. So yeah, it's tricky. It's tricky, but I also wanna make sure like it's not entirely on our heads. Once we make certain recommendations. Okay, anyhow, we are over. I know you'll probably have to run to other meetings and great discussion in general. Love talking with you all. Can you on the flip side? Bye. Later. Bye.