 Really? So yeah, today is the regular JSOC Special Interest Group meeting. We will sync up on the Google Summer of Code status and then just have some time to do corny with students whoever is interested in asking any questions. So I think I'll just share my screen. Okay, is it visible now? Yes, yes. Okay, so we have one of the things which we wanted to discuss is of course coding period because coding period starts next Monday. So this is our last office hours before we go to the coding and we ask all students to make sure that you actually went through the plan and that you perform all actions as a part of the community. So generally our expectation that if you get introduced to the community, you get enough knowledge transfers and that you know what to do as a part of the coding session. So yeah, just three expectations. Yeah, if something didn't happen so far, please think your mentors as soon as possible and please follow up on your action items as soon as possible. Actually my question is do students and mentors would be that do you have any help from orphanage? Okay, so I assume no questions right now. Okay, so yeah, one of the things which you also brought up the last meeting that there is a need to have a kind of dashboard or whatever mostly for this part so that you have a plan for the first coding phase. So currently we have a dashboard in Jinx Jira. So if you open Jira, there is a dashboard called the Google sun of port 2019. So yeah, I'll just show it. So yeah, here's our Jira. If you go there, you may see that there is a number of sprints. So what we started from that we have a sprint foolish phase. So community born according to phase one, according to phase two, according to phase three. And there is already a number of tickets. So in order to get an issue on the dashboard, you need to label it with a GSOC 2019 task prefix, I believe. Yeah, just a GSOC 2019. So GSOC 2019. And after that, the issue will be in the backlog. And after that, you can just drag and drop these issues. For example, I can take one from there and put it to calling phase one, just for an example. But yeah, it's pretty much a sample issue, which is already working in progress. So you need to fix it later. And you can do the same for your issues. And actually what is asked that before the coding phase starts, you play to piece the issues for the first coding phase and put them to the dashboard, you'll have all the filters. So you will be able to search issues in your projects. But yeah, it would be nice if you put these issues on the dashboard. Are there any questions about Jira dashboard and how it works? Because yeah, people may have a different experience with Jira. So if you have any questions, any feedback, let us know. When I'm on the dashboard, when I click on a particular issue, in the right side panel, it shows up the issue. So if you add a link to the particular issue, it doesn't show up in the right panel. When you just expand it, it shows up. You mean project links? Or what? No, issue link. There's a section for link in the issue when you create an issue. So yeah, unfortunately, this browser is not ideal. And unfortunately, we don't have all options to modify the layout. I'll check. And another thing about the pipeline authoring SAGC meeting. So you were saying that it would be happening today. No activity in the group. Yeah, so I believe that there is a coupon now. So I'm not sure whether Andrew is planning to have a meeting. Let's check. Okay, I just asked. Okay. And if you have such topics as a part of community bonding, don't hesitate to reach out to people directly. Because yeah, some projects are related to CX. So yeah, two projects for pipeline, two projects for cloud native C, one project for platform. And yeah, at least as a part of demos for the first coding phase, we will be using at least six platforms. But you can reach out to the special interest groups early in order to get some feedback. Okay. Or at least to get introduced. So yeah, should be something to consider. Okay. Okay. Any other questions? So yeah, we have some students who haven't yet created tickets in Jenkins Jira. Please do so. And if you haven't discussed what would be your plan for the first coding phase, also please do so with your mentors as soon as possible. Because yeah, the worst case scenario that coding phase starts and you don't know what exactly to code. In such case, yeah, firstly, it's just wasted time. And secondly, yeah, it's a planning issue. So we want to avoid that. If you need any help from open means in order to make things happen, please reach out to us through private channels. So we have a simple piece of open means and that if something is going wrong, we will help to facilitate the things. But yeah, by the time coding phase starts on Monday, we expect all projects to have at least implementation plan in Jenkins Jira, because it will be our main engine for communication during a few of the phases. So regarding the rest, yeah, get the keys to be able to work. We had key keys at least in several projects. Again, if you're missing something, if you're missing information, please think your mentors as soon as possible. So yeah, that's pretty much all I wanted to present today in terms of project organization. So we're gonna clarify some questions right now. So yeah, if you have any questions, or if you see that something is missing, please bring cover this topics. And yeah, we will be able to discuss that. So you think Natasha, you there? Is everything fine? Yeah, I was gonna say, I don't think I have any questions. We had a call yesterday and we haven't started doing like your tickets yet, but I will make sure to get those in the next couple of days. And yeah, I think at least in terms of my project, probably the first part is, I think going to be still kind of exploratory. So, but yeah, I will create tickets to reflect that. But other than that, I don't have any specific questions. Okay, yeah, that's fine. So if he says he is fine. Oleg, do we have any special interest group for our project? For all strategy, we don't have special interest group right now. So I was talking about having a security special interest group. So to have, so there is a security team in Jenkins, but the security team is highly focused on fixing security defects, etc. And they don't really have public meetings. So we have private meetings. I've wrote up a question about having something public, but yeah, I didn't get so much feedback about that. So yeah, one of the options that we press it without a special interest group for now, or we can just try to get it organized on the flight. So for example, sending a message to the security team. Well, yeah, probably it's not the best thing, but instead of that, we could reach out to potential users. So we can send a message to the user. The results are an opportunity to have a blog post earlier so that you reach out to the wider community and it can help to bring in some stakeholders. I sent the same email that I had sent to the developer mailing list to the user mailing list on the suggestion of, I think, Babweast. Yep. So yeah, there is Jenkins users mailing list. Yeah, actually it's something which, oh, I'm not changing my screen anymore, right? Okay. So I'm presenting again now. Yeah, here's Jenkins users mailing list. You may see that there is, the number of you is close to zero, but it's mostly because the fact that the most of people have subscriptions. So for example, I don't use a mailing list and many people do not really use a mailing list, but to interrupt here. But yeah, the fall projects, it might make sense to have some visibility here at some point. At least when you have something to share, it's perfectly fine to send it to the user's mailing list. And the same for the community channels. So like Jenkins and your blog, once you have something to share, then it makes sense to use these channels in order to promote your projects. And if you need more ideas, just talk to your mentors because there are ways to get things promoted. Okay. So yeah, whatever channel is something we could use. Okay, does it answer your question? Yes, it does. Yeah, regarding special interest group, yeah, let's try to see what we can do. But yeah, in the worst case, we just press it without special interest group and try to build coming into around the thing. Because the role strategy plugin has so many users that you probably do not really need any special interest group just to get some attention from users. Okay, let's see how to do that. Okay, thanks. What we could do, we could actually So, the role strategy plugin has a Mickey page. And we could post, for example, let's say we could have an announcement box right on the Mickey page if it ever opens. Okay, so we could probably just put a box here saying that, hey, there is an ongoing project for performance improvements. If you're interested to join our channels. It could also help. So for role strategy plugin, you can actually do it on your own because yeah, it's Viki. So you can edit this page. And maybe for other projects, it's something like that could be done. For example, for GitLab plugin, it definitely could be done. For external workspace manager, you can adjust maybe by GitHub to have links to your project. So yeah. So yeah, it's something you can use. Anything else? I have something I wanted to mention. And when we send pull requests, do we need to tag them with special keywords or special labels? Okay, yeah, it's something to discuss. So the problem with that in order to tag a pull request, you need to have the right permissions to the repository. So it means that it's not possible in all cases. What we usually recommend to do is, yeah, so we can just take a look at Jenkins CI Jenkins. Yeah, so what we did, for example, for a remote project, we created a team. So yeah, okay. What we did is that there is a teams. Yeah, so there is a GSOC remote team, which includes basically all mentors and the students right now and we can add more people if needed. And once this team is created, firstly, a student gets added to the organization. So he or she can use these teams for mentioned. And you also can request reviews from the team if needed. And you can see the team when you submit the pull request to request reviews. So my advice would be to actually when you create a pull request either to CC team or to CC your mentors directly because it's something helpful. Oh, like would it be good if when they send the pull request in that they actually add the mentor and the lead mentor as a reviewer in the pull request? Again, you need to write commissions to the project a little bit. Okay. Yeah, so for example, let's take example of this whole strategy pull request from our leader about microbenchmarks for Java. So for example, if you take a look at this pull request, now it doesn't mention the mentors, etc., because yeah, we have a chat for that. But what we could do, we could say that for example, we use from like, you know, so it's the most simple way to request the review. Once you do that, all mentors will get email notification. In order to do that, you don't need to have to be a mentor, sorry to be a member of the organization, you don't need to have to write permissions. In order to request reviews here, unfortunately, now you have to have write permissions to the repository. What it means that in order to be able to request reviews, you would have to be a contributor with merge permissions to the project. And for example, in this case, we could make a contributor. It's not a big deal. We could do that. But yeah, for some projects, for example, for Jenkins Core, if in some projects you need to update that, it wouldn't be possible. At least it would be really tricky to do that. So I would rather recommend to rely on mentions and then not to simplify mentions what we could do. We could actually just create new teams. So for example, we could create a team for GSOP to 7.19. So this team actually allows us to add you so this team will allow us to add you to the Jenkins organization so that you will be able to just comment everywhere, et cetera. And what you can do, you can just navigate to this URL. And then you can ask to become a member of this team. And later we can create specific teams for projects if you need it. Or it means create GSOP teams upon request. Hi, I'll say you're saying that instead of CCing people individually, like saying like CC at mentor, you're saying like if we join a team, we can just like add the whole team. Is that correct? So you can create a team for a project and then this team will be portable. So as long as a student or as a mentor or member of the Jenkins organization, and they will be able to join the team, they will be able to CC all the people without repeating this list every time. So in order to request such teams, you generally just go to Jenkins Jira. Here you create a new ticket. For example, yep, just a new ticket. So the project is in trust structure. Well, something like a task like this. And here in the company, you put GitHub and update a GitHub team. For example, for let's say, here, looking at all strategy projects. So something like that. Okay, once you do that, you just click create. Yeah, you can add some information, but these tickets, well, they get assigned to the new just assign them to me because you have permissions and they will be able to do it quickly. Yep, thanks Martin for doing that. Yeah, so if these teams help, you can just do something like that. You can also add them to GSOC to something like that. So they will appear in our dashboard also, or maybe not. If not, I will get it fixed. Okay, so yeah, basically, if you need that, just let us know. And if you need any other things from Jenkins infrastructure, it's also something we can help with. For example, if you need to host a new component, let us know we will help to deliver quickly. Or if you need any specific things, for example, Docker Hub, whatever you also can help it with. So speaking of that, does anybody need any infrastructure things to be done? Earlier, I needed access to enterprise version of GitLab. So GitLab has two versions like there is a community version and the ultimate or enterprise version. So as I don't have the link as of now, but Jenkins has the permission to access the enterprise version as a open source organization. So I'm not sure who has those credentials. Well, we don't have an enterprise account for GitLab. So if you need that, the best way is to start the thread in the information please. Maybe some time later, sorry, the audio breaks. GitLab lists some of the open source organization. Okay, can you hear me now? Yeah, you can. Hello? Yeah, now it's better. Okay, so maybe later I can share you the link. Okay, maybe later share the link like there, GitLab mentions a list of open source organizations who contribute towards GitLab. So maybe I am assuming during the development of GitLab plugin, it was the Jenkins org was a part of it and it lists Jenkins as one of the open source organization who has those access to the enterprise. Okay, so basically it's hard to say about that right now because I don't know what GitLab's conditions. I'm not sure whether they would be open to give access specifically to the Jenkins project because well, GitLab has GitLab CI. So it's not clear what would be the company's position about it. We can definitely discuss that but I don't have a definite answer right now. So what would be my advice is you discuss this topic with mentors and then once you have a decision whether you want to work on the enterprise version, reach out to the information piece so that you can get a sign-off and access for that because generally it's something to be approved in the governance meeting. Okay. Yeah, so there are ways to do that. I mean I believe that Rick knows how it's usually being done because yeah almost all such special requests go through the governance meeting. Okay, okay. Any other? Not from my side. Okay. What about others? I have a question. Sorry if this has been answered already. Is there one Scrum board per JSOC team or it's one Scrum board for all of them? One Scrum board for everyone but you can set up quick filters and I will set up quick filters for projects once EPICS are created because I need EPICS created by students so that they set up quick filters. If needed we could create separate boards and separate sprints for each project but yeah I'm not sure what would be the need in that. Okay, so students are expected to create the EPICS and put their the labels. The labels and it's one EPIC per sprint. Sorry, one EPIC per coding phase. Well EPICS up to you. You can have multiple EPICS if you want but right now we have one sprint per one coding phase. So it means that the sprints are approximately four weeks. If you want to have shorter sprints like two weeks, okay we could do that but yeah basically it's up to you. Well if it's common everybody has to follow the same sprint durations. If we use the sprint feature, if we just use it for filtering and ranking then then it doesn't matter. So that's why I didn't bother much to create it before community bonding started because last year we did sprint boards etc but effectively nobody used them. So here we created them after the discussion at the previous week but again if nobody uses them probably we don't need to spend time. If somebody wants to use them then yeah we can adjust upon the demand upon the request. So if you want to have two big sprints it's something we can help with. If you want to have specific filters separate boards separate sprints we can do that but yeah there should be such a request and yeah that's it. Does it make sense? So can you do you mind repeating like what the expectations for students are again? So students should create the epics and the tasks is that correct? Well we can even survive without epics. So epics are rather useful for you in order to define milestones and what needs to be done for them. So because for example you can set a milestone alpha release of a plugin management library and you can create an epics for that because a list of tasks you need to complete and then you have let's say 20 tasks and you discuss these tasks with mentors and you already did 15 tasks to be done during the first coding phase and then five tasks during the second coding phase. So you still have epic as a delivery but you put tasks to different spades. It's just one of the examples how you could use epics but yeah basically it's up to you how you operate with them. What we need you to do is to create tasks and to create and to set labels for them and yeah the rest is what we could do for you to know about the thing. Oleg do you mean tasks or do you mean JIRA stories? Well JIRA tasks, JIRA kikis, JIRA stories as you wish. Actually yeah it's easier okay so if yeah it's a terminology. Yeah it's a terminology but functionally JIRA stories are easier to manipulate inside sprint boards than tasks if we ever use the start sprint feature. So I would recommend stories it doesn't matter in the end but stories are easier to manipulate. Okay so let's talk a bit about the terminology because now I'm also confused. Okay so let's see what we have. In JIRA we have issues. So issues have multiple types task, bug, feature, improvement, whatever story. From a management standpoint it doesn't really there is no difference whether it's task, new story, new feature, bug, whatever. So whatever type you create you can easily manage it above. So maybe what you meant Martin is a sub task not task. Okay yeah so generally what is what I tried to say that yeah we expect you to create issues. These issues can have different types depending on your needs. So you can choose whatever approach you prefer and yeah that's it. Okay for the sake of simplicity personally I use epics and stories and the other ones I almost never use them because they don't behave well in the in the swim lanes when we start sprints. Maybe it's something specific to your JIRA. Yeah so in the case of Jenkins JIRA these all these steps have exactly the same workflow. So it doesn't really matter what you take except epics because epics are something for grouping but for the rest you can take whatever type. There is no practical difference between story and for example improvement or new feature in Jenkins JIRA. Okay so if they use the same workflow then it's going to get easier. To clarify epic, epic is is a grouping but it's a grouping or typically over a period of typically an epic is over a period of time which is longer than a sprint. Yeah it could be longer than sprint and it could be shorter than sprint so my personal approach for epics is that I use epics for deliverables. For example let's say I have a full bar plugin and I have epic full bar alpha release. So yeah alpha release of full bar I create this epic. Okay it's here and let's say it's yeah JSOC 2.7.19 and in this epic you can say that okay what do we need to create it. So we say that I want to have feature example and create a new let's say okay a new full bar page for Jenkins. Okay something like that. Okay I will definitely need to clean it up later. So yeah we put label and here you can create a few more of these tasks or you can just clone it. So here for example you say that post your plugin repository and here let's say write documentation. So clone write documentation. Okay so let's assume I'm a student. So as a student I have three epics or sorry I have an epic and I have three tickets in this epic. Then I go to the board and for example we have a meeting with these mentors and we agree that yeah we create a page which is a part of first coding phase. First coding phase then we create we host the plugin as a part of the first coding phase. What's going on with drop and drop. But regarding write documentation we can agree that we do it during the second coding phase and we can say that okay we have epic which sets the delivery but there are actually two tasks we want to perform during the first coding phase and the last task during the second coding phase. Or we can agree that it goes here so it's something like you may want and it's up to you and mentors to decide how you do that. But yeah epic is just a way to group the deliverables. So all of you have separate deliverables in your form but you can just decide how you do that. So for something like updating you know we have like our project pages and stuff like that. Would that go under an epic and then we'd have just like separate tasks for update after coding phase one, update after coding phase two and so on. Yeah okay. So we don't have a requirement to have dozens of Jira tickets or whatever. It's something you decide with mentors. But yeah what the history shows that if you have fun paying tickets then it's easier for you to manage the tasks. It's better for you to track the process. And yeah so our advice is generally to have a good regular rate of tickets. So write documentation, write tests is probably okay. Create new pages is probably okay. But if you have for example five features you want to deliver probably it's better to have separate tasks or separate stories inside the epic for that. Okay is it clear now? Or is it worse now? Okay well thanks Oleg for the explanation. I was disconnected from the network and I just rejoined so I'll watch the recording. Okay happens. Yeah so anything else to discuss today? Any questions? Any help needed? For example I was surprised that UFA didn't need a help with AWS accounts. So maybe it's something for mentors to clarify with the student. For other projects yeah not aware about any specific infrastructure requirements but if we are missing something just let us know. Any other questions, topic for the discussion etc. We have something like 10 minutes left. Okay so yeah this seems there is no other topics. So yeah if you need any help, if you need any clarification please use GitterChats. So we have the next meeting in a week or so when the coding starts. But if you need any time or clarification just use the GitterChats or all our commitments are present there, mentors are also present there. So yeah we will be able to help you without waiting for the next meeting. Then I think we can just stop the broadcast for now. Yeah by the way some organizational changes. So Marky will be joining the JSOC organizing team. Also Rick will be joining the organizing team. So we will have more capacity in terms of handling all things which was one of the feedback we got for community-born phase already. So we will try to have more bandwidth and yeah probably we'll be also doing some shifts in terms of lead mentors. So we have some background discussions about that. So please do not be surprised if such changes happen. Nothing really changes in terms of projects and goals. Please keep working with your mentors and we will provide you as much assistance as we can. Thank you. Thank you. I just forgot to tell about it in the beginning. For those that don't know me I've been in the Jenkins community for quite a while and I'm a maintainer on a few plugins and I've been a mentor. So I'm glad to be in the admin org and if you need anything please don't hesitate to reach out. Thank you. Okay I think we can close down the meeting. Have a good day. Good evening everybody. See you next. Bye everybody. The next project meeting. Thank you. Thank you.