 Okay, hi all, welcome to the Google Summer of Code office hours, we reconvene after one month break and today is May 6th, we have some good news for you, all Google Summer of Code projects have been recently announced, so we have seven projects this year, six projects will be targeting Jenkins organization, one will be targeting Jenkins sites and we have participants from both organizations on this call today, and I would like to thank all participants who, including students who applied to JSOC, potential mentors who were reviewing applications, asked certain questions and all other contributors who helped this initial feedback to students, it's much appreciated and regardless of the acceptance decision, we appreciate all the effort which has been spent. Yeah, we have seven projects accepted, but I think we could share some statistics, so we had several dozens of applications, we had around 20 projects in our short list, so these are the projects which we considered as feasible, as long as we could potentially accept and finally we were able to accept only seven projects, so, but it doesn't really say that other applications will be it, we really appreciate all the efforts and we invite all contributors to keep participating in the Jenkins community, maybe trying again in Google Summer of Code next year, or you can also consider other outreach programs we are organizing, so if you go to our box and outreach page, here you can see that there is outreach programs and if you want to have JSOC-alike experience, we participate in outreach, we run our first community bridge project this year and if you are looking for mentor, you can just reach out to us and you will see what we could do, so it's something we would be happy to do, and if you want any feedback, just reach out to Orkut means, we have already had several students switching out to us and it's perfect to find, because we are happy to share feedback, we have a lot of internal data, but once you reach out to us, we will process that and send it back. Okay, let's go back to the subject projects, so yeah, welcome Sladin, Sumit, Rishabh, Kejir, Sihon, Logi and Boudicca, yeah, if I mess up names, please feel free to correct me, but yeah, we will do our best to get it fixed and yeah, welcome to the Jenkins community, also welcome to many newcomer mentors, we have around six or seven mentors who have not participated in activities like JSOC before, so yeah, it's a good number of newcomer contributors and that's why we plan to have these office house meetings during the entire JSOC time, so you are welcome to join them, you are welcome to ask any questions, if you want to ask a question, then you just go to this Google doc, we have a link, I will share that in the Gitter chat and just put something on the agenda for the next meeting or for the current meeting and if you want to ask any questions in the runtime, there are multiple channels, so for example, we have a Gitter Google Summary of course channel, so I guess for the most of students have already seen that because it's linked from our pages, but you can still go there and basically ask whatever, if you have private questions, you can reach out to JSOC or Cadmins, we have email for that, so if you can go, Jenkins JSOC 2020 or Cadmins and Google groups, so all private escalations, you can use these emails if you have any concerns and for public discussions, yes, chat also public mailing list, we invite everybody to join it, we will be sharing some announcements about the next phases in this mailing list and again, you can ask questions asynchronously if it's your preference, so I guess that's it. For the next phase, the current phase is called community bonding and the objective of this phase is to actually get introduced to the community, hopefully everybody has already received emails, these congratulations from mentors with next steps, I hope that all teams will schedule the first meeting soon and at this meeting we invite you to discuss how you would collaborate in your project, communication channels, meetings, cadence of these meetings and also continue the few steps, so the main idea for community bonding is to be ready to start coding, it's community bonding, meeting stakeholders, also polishing and fine-tuning the design of your projects, so there are applications which have been submitted by you during the Google code application phase, they got some feedback, but during the next month you have an opportunity to improve these applications, get them socialized with wider community, get more feedback because instead of around a hundred students, now we have seven applications, so we can have more focus, each project also has mentor teams, so for example let me just take a look at this one, so here you can see that there are communication channels, we ask all the projects to update them gradually, so now it points to platform C, for example in the terms of chat, mainly at least it's JSOC one, you can change these channels, again community bonding is something where project teams decide what they do, so whatever is comfortable for you, please sit up in this way, then we can discuss together what would be your deliverables, what would be your plans for phases, because projects can change, so what you submitted in your application is a general guidelines and you together with mentors can make adjustments basically as much as you need, although we prefer that the projects stay more with some track in terms of original application, but deliverables are plans that they may change during this phase and even during the coding, because it's life and everything may change, so you are first expected to contribute to get experience and to deliver something together with your mentors, this something is widely a subject for the decision, so we are not committed to the original plan, what else do you need to set up during this phase, you need to talk with your mentors about knowledge transfers, because many projects require deep dive into Jenkins architecture or Jenkins X architecture and again community bonding is a good opportunity to discuss these changes to get enough training and there are mentors who can help you, there are also org admins, there is wider community and if you see that you need additional information to be effective during the coding phase, it's a community bonding when you can do that, so just discuss it at project meetings and you've needed a raised question in the main list, we can organize common meetings, for example how to develop a Jenkins plugin, we didn't schedule a special training for that this year because there is a lot of recorded trainings which you can find on our YouTube channel and you can find the links later together, but if you want to have something specific just let us know, we can do it, so communication channels, regular meetings, trainings, project plan and yeah basically this is what community bonding is, we also welcome you to share your stories, for example some of you already created prototypes during the application phase, if you feel that these prototypes is a good story to share with the community, you can already create a blog post, you can write a message to the developer mailing list to share this proof of concept and again to start getting feedback, Jenkins project has hundreds of contributors, actually thousands, if you take last year's statistics, so by sharing information in the developer mailing list and other channels you can get a lot of feedback and it will help you to tune your proposals and to basically deliver your projects, so that's all about community bonding, you also had some additional communications with mentors and if there are any questions, if you need any clarification, it's a good opportunity to ask it now, because yeah that's why we have this office also, so does anybody have any questions? So Oleg is there a place where we're expected to report that we've completed as mentors the items or it's just hey do it and that's okay? Well it's not just do that, so we actually had a discussion about that 30 minutes ago with the ORCA meeting, we will be communicating just another spreadsheet for that, but yeah the list of items we expect mentors to do is firstly documented in emails we sent and this list is actually not something secret, you can go to the projects page and we have a mentoring guidelines right here, so information from mentors, and here you can find expectations per phases and let's take a look, so yeah we have community bonding, it looks to be in the bottom of the list but it's just at the beginning so here you can see what we expect to happen and you as mentors can use this documentation as a guidance for what we expect, there are also awesome guidance created by Google, so in addition to these guidelines you can find GSoc Mentor guide here and you can find a lot of information about mentoring, about best practices and Google actually sends a lot of emails, they created a greater knowledge base because it's 60 years of GSoc, so many questions will be answered in emails sent by Google, but you can also find them here, so same for students, there is a student guide on GSoc page, there is also a student guide on the Jenkins page so you may have seen this guideline because it was referenced from the application base and here you can find community bonding, so basically this is what I presented today, so communication channels, weekly meetings, interviews, contributors, we'll discuss your projects, etc, etc, so you can use these documents as a basically a list of what you expected to do, this may be incomplete, if you see any issues there, if you want to share your feedback, you're welcome to do that, just in the Gitter channel, if you just see a type, I won't try to make a suggestion, it's open source, so you click improve this page button and actually you can suggest a page in this document, so that's it and once you suggest the page, GSoc Orca means we'll be requested to review it automatically, so yeah, it's quite easy to do that, so please feel free to do it in this way or just discuss it to the office house, okay. In terms of actually reporting the status, where my task is to create a spreadsheet where I'm going to track the different items that we're expecting every GSoc team to be completing, so we don't have it yet, it's something I've prepared last year and I'm going to do it this year as well. If you have ideas on the format this should take, by all means share it with me, I'm happy to take suggestions. Okay, so any other questions from students, from mentors about the expectations? Yeah, with respect to the projects, will there be a separate Gitter channel for every project created, is that supposed to be? This is a good news, it's totally up to the mentoring teams and to project teams, so last year we had a majority of projects choose to have their own channels, the main reason for that is obviously traffic, because what we see our general recommendation is to use mailing lists as much as possible, but the reality is that many communications actually happen in charts and you can define a chart for yourself, so you can create a Gitter chart, if you want you can have a Slack chart, for example it might be much more reasonable for Jenkins X projects, you can even have IRC chart if you prefer, so and if you need something specific, we as often as we'll be happy to help this today, but communication channels is up to project teams, we don't enforce anything specific as often as we just ask you to have these communication channels to have them public, so that any contributor can join and to have regular sync ups and meetings starting from community Okay, so I would like to add Oleg that on the pages that you are showing for the different projects, there's a section where there's a connect, it's actually on this page as well, but specific project pages have that, so make sure that your links there for your specific projects are the real ones for your project, so the mailing list, the chat on Gitter, if you use another chat system, please provide the link, send a poll request with your link there Yep, so if you need information how to do that, yeah I can just use this project as an example, all projects again they implemented in documentation as code and we ask students and mentors to gradually improve these pages to put information, thanks to students who have already submitted poll requests, and here you can actually see some metadata, so for example student, mentors etc, well there is no rocket sense here, it's just a YAML file, same for channels, for example here we have Gitter, we don't have a mailing list link because it defaults to the platform seed, we have some inheritance magic, same for meetings, so once you have meetings set up and a mailing list, if you decide to have one, you can just update this metadata and it will point to the right location. What if someone wants to add an IRC channel in the links, how does that work? I don't have an example for IRC, I can show an example for Slack, because this is what we have for Jenkins X, so for example Ups, Canceledation project, yeah I'm navigating in configuration as code, but here you can see that basically chat is just hyperlink, so if we go to this page then you will see that it just shows a hyperlink to whatever location, well it's not a whatever location, it's a website of Jenkins X which has a listing of Slack channels, right, yeah so chat. Slack is our main form of communication, we're also setting up a mailing list, a public mailing list for Google somewhere carried and I'll update that on the page. Yeah, I guess there will be a separate channel for JSOC, because yeah the problem is generic channels so that they have a lot of traffic, but yeah, so let's see how it's implemented. Same for IRC, you can just add a hyperlink, though for IRC one thing you need to keep in mind that you may have difficulties with storing conversation histories, right now we don't have service on the Jenkins side which will store conversation histories, we are using external service for that, but this external service might be a bit complicated to set up for JSOC project, so if you choose to use IRC make sure to think about how your server conversation archives, it might be important for you as the project team in some edge and hopefully in some edge cases which we will hopefully avoid, it might be needed for Oracle means and for Google, for example if a project gets failed due to whatever reason, if there is an escalation, if there is dispute, then Oracle means and Google will get involved and for us it will be really important to have access to conversations just to make decisions, because things happen, it's not that often in Google summer of code, but I think still keeping in mind that the conversations should be as public as possible and they should be accessible. Okay, anything else about charts? Looks like not. Any other questions before we proceed with these ones? Okay, let's do questions from Mark and if you have anything else just put it in the list, so timeline deviations. In Google summer of code we have basically a public timeline which has fixed dates, so for example here you can see dates for community bonding and then for coding phases, so these dates are fixed, what it means that community bonding happens during this interval, same for coding phases, so for example yeah there will be evaluation period and by July 3rd every project team is expected to submit evaluations, well basically it's pass or fail and same for the next phases, so these days I must have, these days cannot be moved, evaluation process is something we will discuss in follow-ups, there are also guidelines for that, but there is some flexibility and that's why you have community bonding because mentor teams, students discuss the availability, we ask all students to submit information in their application for a reason, we also ask all mentors to submit that in the mentor confirmation form and now we ask project teams to actually work together and we see how the schedule will be adjusted, for example it's common to have exams or for example job placement and other things in July, if you talk about in Russia it's common to have exams in June and so on and so on, it's normal, it's something we want to take into account, moreover we expect you to take vacations during the JSOC, it's not something like you work 8 hours every day the rest of the weekends, you can take breaks if needed, but evaluation stays the same, so what deviations mean that you as a project team can discuss your project plan, for example if you see that if you do whatever reason you won't be available to do work in the middle of coding, let's say in July, if it's a long period, 2 weeks, 3 weeks or maybe the entire coding phase, you can discuss with students how you adjust, so for example you could start coding early in mid-May so that the scope still could be delivered, yes the evaluations will be happening somehow, basically based on your agreement with mentors and it's totally fine, what cannot be adjusted is the end date, so it means that all projects expected to complete by this day, again definition of done for the projects is totally up to the team and the approach of JSOC means that as long as mentors fine we are fine, so basically you are not committed to deliver all the things in your plan, but the evaluation that will happen on this day, so it's not okay to postpone things after this date, doing things before, doing the things in advance is perfectly fine, there are other cases in Google Summer of course when all our projects scope was completed in June, it's also normal, you can still discuss what you do during the next phases or you just decide to be a bit more relaxed, so let's see how it goes, but you can discuss it with a mentor team and you just need to keep in mind that this day is fixed, okay, questions? Thank you, that the crucial thing then was end date is not variable, but we could start early if we needed to, I like that, thanks. And we're going to phase this, you can also just, okay. Oleg, would you like to talk about the scope of projects or the definition of projects, which is also flexible as long as it's agreed to between mentors and students? Okay, let's discuss that, I briefly talked about that, so Sladin, would you be fine if I use your project page as an example? Yes, absolutely. Okay, so Sladin already submitted the pull request, which contains the information, so we can just take an example. Okay, so custom jeng is distribution build service, so here you can see that there is a number of key deliverables, actually this is what was submitted in the application, and there is a plan for phases, so as we discussed before this plan is up for discussion, so it's just an initial thing, moreover this plan can change even after the community born. For example, let's take a look, we have phase three, so one of the feedback I submitted in this pull request is about the integration of a database into the service so that users could store private configurations on the custom build service. So for example, I as a patent, well, I'm not a mentor in this project, I'm a stakeholder, but I can go join channels and say that hey, I don't think that it's something you should do, instead of that I suggest to use configuration as code, so to store everything in GitHub instead of database, and if you want to have a private service, let's add support of self-hosted packaging services instead, so that it's not hosted on Jenkins.io or hosted by elsewhere, but we provide all the documentation, like help chat or whatever to deploy it. Is it a reasonable feedback? It's definitely a subject for discussion, and we, during community born, we can discuss that, we can adjust the plan, and then we could decide together in mentors, since they called us what we actually do with it, and the same for all other things. So this plan is basically a subject for discussion, not on the plan for phases, but deliverables we would do. As long as the project is delivered in principle, so there is a goal. The goal is actually provide users a way to package custom Jenkins distributions. This is the goal, and in practice at your job in open-source community, way to this goal may significantly change. So you are perfectly fine to change your plan, change deliverables, and we encourage you to do that. If you see that the deliverables do not really make sense, or they could be deprioritized instead of other things you would consider as a feedback, so you're welcome to adjust as you wish. Does it make sense? Okay, so one thing about who leads this change? In Google Summer of Code, students lead this change. What it means that students are basically champions in their projects, and they make final decision what would be done, and how they would be done. So mentors act as advisors, obviously mentors have an opportunity to fail the project if something goes really wrong. But in principle, it's students who drive the decisions. If students have strong opinions, it's something you should share. It's something you feel free to protect your opinions, feel free to protect your approach. And we had cases when the projects have been changed significantly because students have seen another direction. So for example, when we were working on a configuration, sorry, on code average plugin, the student working there basically implemented the most of the scope in June, and then the rest was basically driven by the student, and it was an awesome project. And the same for other things. So just make sure that the project is interesting to you and that you drive the change there. Okay. Does that make sense? Yes, thank you. Okay. So, yes, JSOC student is a boss, and still if you have some difficulties, if you need help from mentors, if you need assistance with decision making, that's why we have mentors around. So don't hesitate to reach out to get questions, don't hesitate to request feedback. If you don't get one, if there are issues, if there are installation channels, for example, do JSOC or CADMINS, but hopefully we will be able to handle these mentoring teams because this year mentoring teams are really strong. Due to the COVID-19 situation, we set a requirement that each project has at least three mentors. In one case, we have six mentors, at least in the beginning of the project. All these mentors may change. As a part of community bonding, you can get more mentors who decide to join after the initial discussions. Some mentors may leave the project, life happens. Now, basically nothing can be predicted. Nobody knows what happens tomorrow. So please be kind and please be ready to search deviations, but our main goal is to actually work together and to get a lot of experiences and to have some video. That's it. Any comments, questions? Okay. So, time line deviations, hopefully done. We did some detours, but yeah, it's done. So the next is public meetings and expectations. Again, it's documented somewhere in guidelines. We expect all teams to have at least one weekly meeting. Our recommendation is to actually have two meetings. At these meetings, again, you're welcome to work as you prefer. What are the best practices is to have a public meeting most of them. So you see this Google Doc, and actually this is an approach we use in every special interest group or subproject in Jenkins. So this Google Doc is publicly visible. There's a new interface. I'm still getting used to that, but yeah, actually anyone can see that. We also link it from pages. When you work on your project pages, the advice to have a meetings section here where you provide a link to your doc, describe the cadence. So instead of this link, it should have something on the page directly. Then this information becomes accessible to everyone. So keep track of this document. Well, basically you can use it for weekly updates. So in the beginning, have a short summary of what you've done over the week, then have a discussion about obstacles, about where the help is needed so that you can submit it to every mentors. And yeah, this is the main idea for the meeting. Whether you want to record these meetings, it's up to you. We do not set a requirement to record these meetings. But if you want, you can totally do that. And for example, if you agree that at this meeting, you would do a demo. For example, it's a middle of evaluation phase. You have something to show. It's a really advice to record it so that you can divide the community. And if you need to record it, you have two ways to do that. So one way is to use Zoom. So right now, we are using Jenkins Zoom account. And we will be working to give access to this account to more contributors. So if you want just in corporate means, and you will make sure that you have this recording session. Other ways is to basically use any other Zoom account. Or you can use other services. For example, there is a great open source project, GC, there are other projects. So I can show it. Yeah, GC. Okay, GC meet, I guess. Hi, I guess. Okay. So Google helps. But yeah, cool thing that this is an open source project. Another cool thing that they use Jenkins for CI in CD. But yeah, this is a project which you, this tool you can install, you can have a recorded meeting, and then you can just upload this meeting anywhere. And if you want, we will get it hosted on our YouTube channel. Jenkins has its own YouTube channel where we post, we are posting these videos, for example. If you want, I can actually show it to you. So let's take, so here, for example, meetings are recorded and posted here. And here you can see this recording of our previous meetings. So we need to figure out what's wrong with ordering there, but you can find the historical meetings. And if you want to get your demo, etc. posted, we can get it here. Or we can use special interest group channels. We haven't talked about special interest groups yet, but every project has one. And you can use it as a wider community. So just feel free to also communicate with members and present your projects there. Okay, does it have to be once a week? Or is the project team decides? So we highly recommend to have such meeting once a week. Because it's really needed for sync up. It doesn't have to be a video call if you decide to do it in chat. Okay, you can do it in chat. But the meeting itself is important. If you want to have daily meetings, yeah, please feel free to do that. I'm not sure that mentors would be really happy about that, but it's totally up to the team to decide. So just organize them as you wish. And the time zones, etc. It's also up to you. So we usually use service called doodle.com in order to vote for meetings. For example, this meeting, of course, I will submit a doodle in order to find a better time, because now we have contributors who work in different time zones. So maybe we should reconsider this meeting time. Okay. Yeah, so yeah, team has decided. I would like to say something regarding that, Oleg, please. So if you, if as a student or a mentor, you are blocked by something, if as a student you expect some activity to happen and it's not happening, or same for mentors, then do not wait for the next weekly meeting to seek assistance from org admins. Please report anything that is, that you expect to happen and it's not happening. Don't wait one week. Let us know within a day or two. Same if you're blocked during coding and you cannot progress. Do not wait for your weekly meeting. Just ping your mentors. Let them know you're blocked. It's perfectly fine. We don't expect you to know everything. So it's perfectly fine to ping your mentors quickly when you're blocked, when you're stopped on something. I assume Martin also if someone feels there's been a code of conduct violation, those are again places where talking to the org admin sooner is better. Talking to your mentors sooner is better. Yes, Mark. Thank you. Yeah, definitely. So for code of conduct, again, hopefully we won't need that. But yeah, there is official code of conduct published on the Jenkins website. Yeah, it's a bit long, but it boils down to be nice. And if something doesn't work, you can escalate it through official channels like Jenkins Board. Obviously, if it's something not that serious, it's better to start from org admins or maybe just discussing between private messages. Because yeah, things happen. There are different cultures. And if you're feeling uncomfortable, just let people know. Usually it's just misunderstanding. And we hope that there is no better intentions. But yeah, if something goes really wrong, there is a channel for that. Okay. So any questions, comments? Yeah, I think in the future we should expect other people to have more questions and Mark. Okay. So yeah, one question we often receive is about office hours. So yeah, we expect students and mentors to participate in their project meetings. We do not expect you to participate in office hours unless you have questions or unless you want to hang out, etc. Just chat with people, maybe share some experiences. So this meeting is totally optional. The main purpose for this meeting will be to firstly have a Q and A regarding the process site. Again, technical site is better to discuss in the developer menu at least on your project channels. But for organization, you can use these meetings. We do not plan to have these meetings for one hour every week. So basically we will be closing these meetings earlier once there is no questions or no topics to discuss. We will be still recording this meeting and doing meeting notes. So if you just want to see what happened just go to this Google Doc or to the YouTube channel we shared and you will be able to see this information. So this meeting is totally optional. I understand that this time zone will be a challenging program to participate. Yes, Martin. Oleg. So in the past we've had knowledge transfer sessions and those were special meetings. I suggest that if the office hours are available for knowledge transfer and if the timeline works with the people that need them, we could use office hours for 25, 30, 40 minutes long knowledge transfer sessions for things that are common to multiple people. I agree. Why not? I already started speaking about special interest groups. So if you go to the website, you can see that there is a number of sub-projects, there is a number of special interest groups and many projects are somehow linked to them. For example, there is a platform special interest group or platform support where we have custom Jenkins distribution and build service and other projects. Also, there is a cloud interface where we have external storage and so on and so on. So feel free to use these channels as an additional communication channels. All of them have regular or less regular meetings. So for example, if you go to pipeline ordering, here you can see that meetings happen weekly. Commonly it's monthly or every two weeks, but you can join these meetings. You can meet other contributors. You can, for example, present a demo before going to the online meetup, etc. And it can be additional sort of feedback for you. So if you want to have knowledge transfers, etc., you can also use these existing channels. I mentioned online meetup a few times. Would you like to briefly discuss that? Okay, I'll just show it. So in Jenkins project, we also have Jenkins online meetup. So basically it's used for public meetings. We use meetup.com and today we announced various meetups for users, for developers, and we historically make final evaluation presentations on the online meetup. So it means that by the end of the third coding phase, we expect every student to present their online meetup to show their project. Usually it's kind of live demos with some overviews with some discussions. So it's going to be happening at least for final evaluations. We are not sure about the intermediate coding phases. We expect you to have a recorded demo, for example, as a part of your project meeting, as a part of SIG meeting. Maybe we'll do internal meetings. Let's see. But if you have something you would like to share, we basically encourage you to continuously integrate your changes into the master branches. So when you work on the project, you don't expect your project to stay in the branch for three months and then to get magically merged, we expect it to be quite opposite because Jenkins is used for continuous integration as well. So once your particular deliverable feature is ready, it's integrated, et cetera. If you still see it's a value in that, if you would like to present it, or even if you want to present something in work in progress, you can ask us. We could organize Jenkins online meetups so that you have this discussion. And you can also write a blog post. So, for example, if you take a blog, for example, there is a blog post by team about GitHub app authentication support. So this was a blog post about preview version. We'll submit an update later because it's over to PGE. But if you want to share some information, please do that. And our general expectation that during every coding phase, there is one blog post by the student. So it's just summary of the project, maybe with some screenshots, some highlights, it doesn't have to be something very long. But don't wait until the end of the phase. If you have something to share, if you already have something to share now, maybe for prototype, you can just do it now. So sharing information is the best way to get feedback. And all Jenkins channels are at your service for this purpose. So we are slightly going to cover time. So this meeting is 45 minutes. But if there are any other questions, let's discuss them. If not, we can take them offline. Anyone? Have we answered all the questions that people have in mind? Well, likely not. But if you have something to ask, you have many to use to get the channels, etc. Thanks again to everyone for participating in the Google Summer of Code. It's an honor to work with you. And hopefully, we will have a number of great projects this year. So thanks to everyone. Have great meetings and have great onboarding to the Jenkins organization or to Jenkins X organization. Welcome to everyone. Thank you.