 could turn on the recording so that we've got a record of it as well. All right. So topics, um, let's see. So we've got, uh, community bonding, uh, for the next, for about a month, right? Yeah. And then project for, I believe it's 11 or 12 weeks for basically three months. Uh, and so I assume that the first question is, how do we achieve community bonding? How do we make sure that that's successful? And then go from there. Um, what other topics should we put on the list? Well, yeah, I can just put comment topics. We address, um, in, uh, Google, uh, summer of code. Uh, so firstly it's communication, uh, channels. So it's, uh, meetings, uh, maiden, please, if needed, chats, uh, then, um, another important topic is actually stakeholders. Um, so getting as many, uh, contributors as possible. Uh, also, um, of course, knowledge transfers, uh, when needed. Getting, uh, permissions and required infrastructure. Planning of the project was not at least actually socializing the project. So yeah, these are main things we are doing here, um, during community bonding, uh, I might have missed something, but yeah, there is definitely a lot of work during community bonding. And this is actually brings up, uh, to the first question I would like to discuss is about availability. Yeah, um, during community bonding, everybody has, uh, different, uh, capacities and people have locations, of course, uh, in your case, uh, you also, uh, just to tell us once about Google's season of dogs. So, uh, of course we need to adjust our plan, uh, the main assumption and then Google, uh, summer of code and same for Jason. But, uh, you're not available full-time or anywhere close during the community bonding. At the same time, we want it to happen smoothly. So it's important, uh, to have, uh, communications and to ensure that we can find, uh, proper, uh, meetings and meeting times so that we know about each other's availability. So for example, I can go ahead. I can say that in the beginning of September, I disappeared for two weeks because I go on vacation. Yeah. Uh, yeah. So it's, yeah, just two weeks. So it's just an example and if somebody else has, uh, such major commitments or major unavailability plans, uh, you could share them. Yeah. And I should just alert that I'm, I'm. Mark is primary Jenkins info right for the, for a while here in for support. Therefore tends to be distracted by that. Uh, so I may not, particularly during community bonding, I may not be as responsive as I'd like to be, but I'm, I'm not on vacation. Just at risk of heavy load. All right. So that. And that, you know, any, you said you were moving that you're changing location that probably will affect your availability. Are there other things where you'd like to note during the period up until September 13? Um, no, aside the fact that next week, um, from Monday to Sunday, though, I'll be available, but not as much as I would like because I'm traveling around a bit, but if there is anything, I'll be available. Yeah. Yeah, it's, and it is perfectly fine, particularly during community bonding. Right. Oh, like, can you help me be sure I understand? I think community bonding is intended is it's okay that it's not the same level of time investment as during the project phase during the project phase, it's relatively heavier than community bonding. Community bonding is the getting started phase. It's expected at the same time, yeah, uh, to have the project, the efficient community bonding has to happen because yeah, I've been participating in GSOC for five years by now. And basically community bonding is, uh, the first one, the majority of projects fail, even if the failure effectively happens later. Uh, so they, we still need to organize it. At the same time, uh, many communications can actually happen unsynchronously. Uh, so yeah, commonly our recommendation, uh, for projects is to do as many discussions as possible in my link list, et cetera. Uh, historically, uh, still projects tend to use chats more, but for example, chats are also kind of a synchronous and you don't have to have a meeting to discuss everything. So it would be one of the ways to actually ensure that, uh, we can move forward. Yeah. As Mark said, uh, it's expected that we have every day. Great. Okay. So you mentioned communication channels. Uh, Zinab, is Gitter accessible to you? Is that a workable communication channel for you as a Gitter, Gitter for chat? Yes, it is. Okay. So I'm going to paste a URL to the, uh, Gitter chat for the docs. I think that maybe it's a low enough, uh, low enough volume, a low enough traffic channel that I think we could reasonably use it. Well, like, has that, has your experience hinted that that would work or should we do a dedicated channel for, um, for Google season of docs? It depends on how intense it is. So again, this is the first time we participate in a Google, uh, season of docs. Um, but yeah, I would start from a single channel, at least for community bonding and if we see that it doesn't work, we can about in JSOC, uh, the most of, uh, projects actually have separate channels, um, but yeah, again, yeah, uh, documentation, sick channel firstly, uh, is quite active, but, uh, at the same time, it's not something like we have them once out of them, two messages per day there. So I think it could be sustainable. And for me, at least for sure, it's not to use, uh, the docs one. I wouldn't mind either also having things in the Gitter chat because it could kind of pull in other people who might, you know, interested or have be able to review or have other comments. So just keeping it open for many people who'd be interested. Now, now, is there a, is there a Gitter chat that's focused on Kubernetes or is that a slack channel? I mean, is we could consider doing this, theming this instead around Kubernetes rather than around docs in that sense? Okay. So one thing that, uh, there is a dedicated channel for Jenkins in Kubernetes Slack. So this one of the options we could consider at the same time, uh, so Kubernetes Slack isn't managed by Jenkins community. And it means that if we need any changes and integrations, it might be difficult. Plus, uh, that channel is actually quite active. Uh, okay. So we would be easily, we could more easily get lost in that channel, be overwhelmed by volume. Yeah, but it's, uh, something worth exploring, at least it's definitely a good place, uh, to be, uh, for contributors. Because, yeah, yeah, most likely this channel could be used to facilitate feedback. For example, one of the things we could do, the only coming into bonding, uh, contact links, the colors, that's why we could launch a kind of survey to see what actually users expect from documentation, what are the key areas, and for such, uh, options, uh, yeah, uh, using, uh, existing community channels is a good thing to do. Ah, right. Okay. That's, I like that. So survey the community, the Kubernetes Slack channel, uh, we may not then use it for detailed communication with each other, but that's a great place to get. Excellent. Okay. It can be a great place, for example, for getting feedback or maybe asking some questions, because yeah, there is a lot of Kubernetes experts there. So again, it's a, it's definitely a channel, a way we should be, at the same time, whether it's a main channel. Personally, I wouldn't vote for that. Uh, but again, during community bonding, we can review options and, uh, make an indicator choice, because right now we don't have enough data to see. Any, no, you had noted stakeholders, any guidance there, Oleg, in terms of stakeholders and should we finish with communication channels first? Oh, yes. Yes. Please go ahead. Because we haven't discussed meetings. Ah. So for meetings, how we usually approach in JSOC, we recommend the teams to have two meetings per week. Uh, during the coding, the implementation phase, and we recommend to start setting up these meetings during community bonding. Uh, for JSOC, I'm not sure what would be the cadence. I think that, uh, it makes sense to just utilize existing, uh, documentation, seek meetings where possible. For example, yeah, I'm not sure about, uh, Mark's office house, that office house is something like 10 PM UTC on Monday's, right? So, yeah, obviously I can't participate there, uh, I'm not sure about here, Zeynep, because we're in the similar time zone, but it's, I'd rather depend on personal availability. Uh, but yeah, we can definitely find, uh, slots and Americanization would be two target weekly meetings. Maybe not the next week, uh, if you're moving, but a week after, uh, it makes sense to start having meetings. Okay. But, um, sorry, I just wanted to confirm on the meeting times, there's, um, meetings that happen on Monday's, um, that's, um, very late. So, I might not, it might not be consistent for me, because sometimes, yeah, I'm awake, but sometimes I'm already at sleep, because I think it's around, like, 12 PM, they're about here, so. Yeah, it was, Oleg's, Oleg's suggestion was that we consider either a Thursday, Thursday, midday your time, or a some other day, or we could, we can do absolutely, that Monday session is not expected that you would attend because it is so late. It's, that's very much a North America, North, an America's centered thing, and it's after the working day in most of the Americas. So it's intentionally very, very late. And we know it's impossible for Europe and for Africa. So, so absolutely, you're right. You are not expected to attend Monday. Yeah, what we need to do is to actually, uh, maybe create a doodle, uh, for the weekly slot. I like that. Let me do that. Okay. Yeah, no, the important meeting we need to discuss is Documentation Seek meeting. So I guess the next meeting is this Friday, right? I do plan to do it, Mark. I plan to cancel it for this week, or just to call up that we're, our weekly office hours are sufficient, so, but we could hold it if it would help, past attendance has been lighter than the office hours. And so I'm, I'm more prone to cancel the, that Friday morning, one Friday a month and continue the weekly office hours. I see now, would you be available this Friday with that work for you? It would be Friday at, let's see, is, which, which times, what are you in? See not GMT plus one GMT plus one. Okay. So same time zone as you are Oleg, right? You're GMT plus one. Yeah, plus two like this. Okay. All right. So let me do a quick look at the calendar. I think. So it was unknown UTC protocol correctly. Yeah. So it is, it would start at this, at the same time as this meeting did today, on Friday. Okay, that's fine. Okay. Well, so then, so then, and are you, are you, you're available that at that times enough so we could just use that time as one of our meetings? Okay. All right. Great. Yeah. So one thing about that, that so if you do it this week, then, yeah, we can announce the project in the minute piece, et cetera, invite people, but I'm not sure that we will have a lot of contributed during concession, short notice, maybe, maybe one of the options is not doing it tomorrow, but doing it next week. And, and sorry, Oleg, I misspoke. It is actually scheduled for next week. All right. So my mistake. So Zina, I assume it's okay. Are you available next Friday at, at this time? Yes, I will be. Sorry about that, Oleg. It was next Friday at so, so that's the scheduled time. It's on the 28th of August, 2020. Actually, it will be me who is unavailable because I have DevOps world recording at this time. Ah, okay. But yeah, if I finish early, I will join. Great. And Zina, if you find that that time, well, we'll do the doodle poll to find a time. But that Friday, Friday time works great for me. And, and we'll, we'll do the poll to see if we can find a point where weekly meetings will work. Okay. So speaking of that, yeah, we really need to start the content in stakeholders earlier. One of the ways is to actually announce the project. So I still have an option, open action. I can turn on sit in Jenkins social media because well, I was waiting for Google to fix the JSO side. But yeah, more importantly, the strata announced it in the seek and in the Jenkins developer, my link list. And maybe in cloud native seek as well, because it's highly likely that you will get some contributors out of there. So, yeah, my question is, who would have something with to do the announcements? I could do that. So let me let me take the announcement piece. Oh, like, I was, I was going to proffer one more, which I would love to have a blog post introducing herself and the project and would think we would beg Xenob for that, but I can do the announcements. So the, when we say Jenkins social media, that's really Twitter, LinkedIn. Should we do something on the Facebook account as well? I don't remember if we've got access. Yeah, I have access to the, but yeah, Facebook is dormant right now. Okay. They did basically, we can do it later. But yeah, anyway, yeah. So then I also want to use intent to facilitate contributions. So it's not to brag about the project, but actually to invite people to join. Right. And yet this blog post would be rather about the same, but the blog post, it's a bit flexible, you can do multiple things. Well, and would it be acceptable if Xenob also use the blog post? Maybe it's a, maybe it will confuse things, but to introduce Sheco's Africa, I think that's such a, such a cool concept that hey, I'm Xenob and I'm, I'm here, but I'm also involved in other things. And yeah, that sounds great. Well, it was over the cover to some extent in the CD Foundation blog post. But yeah, I believe that the content could be duplicated, has published blog wasn't too much about Sheco's Africa. But yeah, I agree that it's perfectly fine to advertise to other communities. Oh, good. Okay. Okay. And also we need to announce it in the developer mailing list. Oh, right. Yep. Because yeah, developer mailing list is basically the main, the central mailing list for Jenkins contributors. I would rather say that the name is a bit obsolete because yeah, the name with basically have developers. We use it for all kinds of governance matters, et cetera. So it's basically Jenkins central. But yeah, you haven't never renamed it. Yeah. It's anything, anything that isn't specifically a user question tends to end up there, right? The all governance, all we talk about documentation there. Yeah, you're right. So it's basically a central contributor mining list and not all contributors are developers. Okay. So what else? So there was, was it Torsten Walter as a possible coach or an orientation session? Is that in this section or should we consider that part of knowledge transfer? Yeah, it's basically a contacting maintainers and key stakeholders. So yeah, in the community, we have a number of contributors who are active in a Kubernetes related components. There are also external components, for example, Helen charts are currently external and Torsten basically works on Helen charts. But yeah, we could contact these contributors directly and invite them to participate in particular areas, etc. So we're actually going to be over time a bit. Yeah, let's do a check. Yeah, you have a hard set. I do. I have a hard stop at 9.30. So I have 13 minutes more. Okay, unfortunately, I have 30 minutes more. Xenob, are you available for additional time or should we schedule? Do we need to schedule another time when we could meet? No, let's continue. Okay, great. So, Kristen, thank you for being here. Thank you. Well, the notes are available to you and the recording will be posted a little later. All right, great. Thanks and welcome Xenob. Thank you later. See you all later. Bye. See you. Bye. Okay, so what else about the stakeholders? Yeah, I think that it's being able to spend some time to do the full list. Do you want to do it now? No, no, we can gather it later. Okay. And that one, I fear, Oleg, it may be better that you do it rather than me. I'm not sure. I am confident I do not know which are the key contributors in that area and your experience with cloud native SIG will help a bunch. Okay, yeah, I will do that. But yeah, anyway, force can be gradual, so it's not like we need everyone to be contacted next week. Because at least my vision for the project is that you would actually need to start from setting up a skeleton on the structure for documentation. And you will proceed to specific topics after that. But again, it's my vision. It's subject for discussion. But I'm not sure whether you want to discuss it today or next week. Yeah, I think that we don't have to contact everyone overnight. Right. Anything else on stakeholders and onboarding contributors? I guess for now, it shouldn't be okay. Somewhat related, it would be great to have a project page on the Jenkins side. So we're pretty much similar to how we do for JSOC. And yeah, as in JSOC, JSOC has two pages. So one is final report, which is likely a kind of blog post. And another one is just project page, which could be a reference to this page. And yeah, I believe that we could update docs, seek documentation and other locations to reference this project because obviously it will make it more discoverable. Separately, yeah, the project naturally maps to Jenkins road map. We have a Jenkins and Kubernetes item there. I have Jenkins and Kubernetes and documentation seek projects list. So maybe we can just cross reference it. That seems so is that one that. Feels like Zenab should handle the blog. That's a good place. It may get her more familiar to work with the project to try to create the project page. But then again, it may also be a an uncomfortable or a daunting task. Do you have a sense that something I should do or Zenab should do? It shouldn't be a big deal to create. I think I think I can create the project page also. Okay, great. I'll just ask for the idea and see if we need any. Great. All right. So we have a root page for JSOD so you can just create something under this rule. And Zenab, you have already contributed to the Jenkins IO site multiple times. So that's great. Okay. So it's not that there's any any ode. How do we how do I operate with this? You're already comfortable with that. Great. Yeah. Anything else on stakeholders and onboarding contributors? That's fine for now. Yeah, we're likely need to talk about it a bit more once we see how many stakeholders we have. Because this project may go in different directions. So one way basically we don't call the documentation compiling on the documentation separate ways that facilitating the things and helping others. So for example, just ensuring that there is documentation stretch helping others to contribute particular bits of the materials. Yes, we're writing a lot of documentation, but at the same time, rather making it a group effort in the community. But yeah, we will be able to make this decision on the approach once we see how many contributors are actually interested. All right. Knowledge transfer then. So I like the idea of a skeleton of the document socialized. Zina, have you had experience in the past with Kubernetes? Yes. Yes. Now, in terms of one of the things I was assuming was a session with Torsten and others would be a good knowledge transfer. Yeah, it would be. Though again, I'm not sure what it has to happen during community bonding, because it's about health charts. So there are two options. Do it during community bonding or do it when we actually start working on this area. Right. Good point. It's perfectly OK that during the project phase from September onward, that lots of work happens there. OK. Yeah. Still, if you do it in during community bonding phase plus one. If you prefer this approach, we can actually do that. Or we can schedule it. Let's see. I'm not sure where would it be according to the project plan. But most likely it will be closer to the second part of the project. So what would be your preference there? I think I'd love to have the sessions, the sharing sessions. Sorry, do you ask questions on the sessions? Yes. So when do you prefer to have them during community bonding? During community bonding. OK. We could try it. Yeah. And the one challenge there is we're in August and many people are on vacation in August. So there's a risk it won't make it during community bonding. But knowing that it's preferred, we can try to try to get those scheduled to plan. Yeah, I can discuss it, Mr. Sturston. But I think that it would be rather a beginning of September. And it means that somebody else would need to host it. Because it's not like I cannot host it during the vacation. I actually would be happy to do so. But at the same time, I can commit on any internet quality. Well, and I like that's when I would love the excuse personally to host it, because then I could listen and learn while Torston and Zina are discussing. OK. So OK. So I guess I can take action item to actually kick off the discussion. But yeah, then I can transfer it to you so that you can continue and set the date. OK. And yeah, I guess we need. Similar on Kubernetes plugin. So Zina, in your plan, you step starts from Kubernetes plugin, right? Sir, I didn't get that. So does your does your plan start with or have a key component of using the Kubernetes plugin? And I assume it does. Yes, it does. Yeah, because an actual evolution is that we start from Kubernetes plugin. Then you're deploying Jenkins to Kubernetes. So for that to be had knowledge transferred by Marki Jackson in May. Well, it was online meetup. But it's quite straightforward. This foundation documentation. Then, yeah, we can press it to hand charts. And for example, Jenkins Kubernetes operator. And there are also a lot of other plugins like Kubernetes CD plugin. So again, just so basically it was done to two areas. One is. Sorry. Yeah. Sorry. Should I repeat it? I think I think it was just background noise on CNEP's microphone. So I think you can go ahead or like. Yeah. So again, we still need to plan how we approach to the documentation, how we structure that. But yeah, generally there are two main parts. One is running Jenkins and Kubernetes. Another one is more user site is actually running payloads and Jenkins pipelines in Kubernetes or, let's say, deploying applications for Kubernetes. So there are basically two components of that communication. And then we can do knowledge transfers separately. We can split it to phases. Yeah. So for example, we could meet next week and spend time specifically on actually reviewing the plan because CNEP already has a great plan in the application. So we should use it as a base together. But again, we could discuss what would be the main deliverables, et cetera. Because it would be important for coming into Bonnack. And it's important that when we start the implementation, we actually have some vision where we want to be. I like that. That would that would allow us to let if that's OK, you can see now with you, the doc SIG meeting next week would be almost entirely focused on discussing and reviewing, refining the plan that you've already assembled as part of the the application to Google Season of Docs. Would that be OK with you? Yeah, that's fine. Now, permissions and infra. Oleg, that was one that I was concerned about. Can you give some insights or suggestions there? OK, so for permissions, most likely we do need special permissions right now because yeah, there is Jenkins IO website. And unless we decide to create a mini site for Kubernetes documentation, so if we just target putting the documentation on Jenkins IO, there is no need in special permissions. For infrastructure, she is a it's a bit more different because for infrastructure, one of the ways is to actually run everything in mini cube on a similar service locally. But it's most likely that you will have to at least run some components during your project. So that's why I wonder whether we should consider having access for cluster or whether you find these deployments in mini cube. I would assume that she'll need cluster access for just the nature of the surprises that I expect to come or the things that are more complicated than will work with just mini cube. Well, for me, it's firstly a part of the plan because let's say you want to write a section about how to run Jenkins in AKS. OK, then you have we need to have an AKS account. But if you want to just prove free guidelines for Kubernetes plugin, most likely you can get away with mini cube. So that's why I'm not sure whether we have answer now, but this is definitely a question you need to answer during the community bonding phase, because if you want to provision infrastructure somewhere for testing, then it implies some course and it means that we need to secure budgeting for that, etc. So we have budgets in the Jenkins project, but it really depends on what we need to deploy and how what we have other options. So that's why it's rather preferable to do it in community bonding because it may take a few weeks. If you do it when we need it, then there is a high risk of the project being delayed. OK. CNAP, does that make sense to you? You're comfortable with that that next Friday? Well, we would love to have a discussion and include that topic in the discussion. Yes. Yeah. So I guess we went through key items. Except socializing the project, but a bit of the basically country stickhold without reach, which we discussed before is more less color sit for now. Right. So any other topics you see missing for the community bonding? None that I see. CNAP, any from you? None from my end. None from my end. Great. Yeah. Thank you. Super. Yeah. So if you see something just let's discuss it synchronously. So again, the main objective is to basically ensure that you have everything you need to start the project and that we prepare the environment that we are comfortable with what we are doing and we empower to do what we need. So again, if you see anything, just bring it up. We'll need to wait until the next meeting. OK. Yeah. Hopefully we will be able to resolve many things synchronously. Great. Excellent. That covers all the topics that that I had hoped and far beyond. Well done. Thank you. Zinab, any other topics you'd like to add before we close, before we conclude? No, I think I'm good. All right. Thank you. Then I will. I will go ahead. Let's we'll end the meeting and I'll upload the recording and the notes. You should have a link to them. If you do not, I will certainly post a link to these notes in the in the chat. Yeah. So the recording, actually, there are two options. Firstly, we upload it and make it public like we do by default for project meetings. So all we can actually just keep it unlisted so basically both ways work and for me, whatever works. Any preferences? I've I've liked public, but I'm OK with unlisted. Unlisted will still allow Zinab to review at any time and anyone who has the link to review it. So yeah, either is great. Either is great for me to public on this stage. Both are comfortable with me. Yeah. OK, so if if you're not if you're not uncomfortable with public, I'm biased towards public myself. So I would tend to upload it public. So let's just assume I'll go ahead public. OK. OK, that's fine. All right. Thanks, everybody. Thank you very much. And we will meet next Friday at this same time. So eight days from now and discuss further and we'll have interactive chats and conversations either in chat or the mailing list between now and then. Thanks, Zinab. Thank you for joining. Thank you. Thanks, Mark. Thanks, Alec. Looking forward to work with you in the next seven months. See you here. All right. Bye.