 Good morning, the ten of you. Thank you for waking up earlier. We are going to talk here about the two Google Contests. Debian is participating. Maybe you will have known the Google Summary of Code. Silvestre, I'm going to talk about the Google Summary of Code. I am going to talk first about the Google Coding. That is a contest that Debian was participating this Christmas. It was a bit different to the Google Summary of Code, in the sense that we have a high school student or secondary student. Pretty much it was between 13 and 18 years old. And we had a bunch of contributors to Debian who were like 13 years old. We watched. I found that amazing. The contest was a whole version of something else that Google tried one or two years ago, in case you know it. Besides the name, the contest was about doing a lot of more things that use code. Most of the Debian tasks, as you will see later, were related to Quay, documentation, translation, and so on. It was very, very, very small. It was only 20 mentoring organizations. And it was also lasting a lot of less time than the Google Summary of Code. It was only seven weeks. So basically how it worked. It was very different to the Google Summary of Code. Basically all the mentoring organizations create a list with all the tasks that the students called do. The students were claiming the task, reading the instruction, not always. They were delivering the result of their job. Then the mentors of every project were looking at what the students did. In some cases, the work was perfect. That's done. In other cases, the students need a bit more of time for completing the task. And in other cases, the student was unable to do the task. So basically in most of the cases, I have to say that in Debian, the students were unable to do the task. They were very underestimating the job. But when the students managed to do the task, the quality of their job was very, very good. For example, you can see that the tasks in Debian were very, very simple, except in one case. That was the fix at the piggyback. Actually, a student did that. We end with a lot of man-page, a couple of query or law that's made into the archive. Serial translation. Most of the tasks, if you think about that, is what a contributor can do in one or two hours. But for most of the students, it usually took one afternoon or maybe two. If you are curious, when the project ended, I blocked and I put all the tasks that have been done. So what the students got? Basically, most of the students were doing that because the t-shirt, when a student does a t-shirt, they get one from Google. That for the students is to be very cool. And when they did three tasks, they got some kind of check of $100. Also, some students got to know how to start contributing to the difference Debian, no, free software projects. In our case, Debian. What Debian got? Well, we got about 30 students that managed to complete at least one task. And in the end, we got 39 tasks. The list is on the link I gave previously. Those of the 30 students, two students are still contributing to Debian. One of them is very, very active to the point that I started sponsoring him and he had to look for somebody else because I didn't have time for him. He was like every day one package. He's maintaining right now 13 packages. So basically, he has been adopting a package every two months. Sorry. Every month he has been adopting two packages. Also, there is something that we told in Debian from time to time that is having some kind of mentoring scheme. And some people mentioned having a small task so contributors can start helping. In this case, we tried that scheme. But the results were good. But I don't know if they are applicable to all Debian because we have very, very little number of mentors. So after telling all this, how you can help? Well, we really need mentors for the next edition. This year, we only were active like four or five people. And we have a lot of students. If you don't have tasks and mentors in the first week, students go to another project and they never come back. The involvement is very, very low. If you compare, for example, with the Google Summary of Code that you need to stay all the summer, basically, if you have one week and can have two or three tasks, it's quite fine. We also need people with administering the project side because sometimes a mentor disappear, or a student has a problem, and some of the other is not a mentor can help him or help her. Also, the most important thing is that students don't have a lot of patience. Sometimes they have a problem, and they have help now. Maybe making them to wait, I don't know, one day is fine. But when they have to wait two days, they can move to something else. What happened with small kids? OK, this was everything about the Google coding. If this year is held again, I am expecting that. It will be probably starting around November and it will end in the fifth week of January. So when you see the announcement in the end, I hope you will join. Thank you. Now, Silvester and Arthur are going to talk about the Google Summary of Code. Good morning, everyone. So this has been the sixth year we've been participating in the Google Summary of Code. And every year, bring something new. So if you've already been to this talk this year or this year before, some of it is going to be the same. Some of it is going to be different. So I'm going to remind you, still, some of the goals of the program. The idea is to get more open source code created and released. The goal of Google is to inspire young developers to begin participating in open source, mostly. Also, we also get students that are already involved in various open source programs. And from the point of view of the open source project, it's a way to identify and bring in new developers. And for the students, it's a way mostly for many students to be able to do something that is remotely related to what they're studying. The idea is to flip bits, not burgers. It's also something very interesting because it gives students the first exposure to real-world software development, with many things that are specific to the open source world. But that also exists in the general development world, such as distributed development, software late sensing, and how to properly write on a mailing list. So Sylvester is going to explain to you how the program actually works. So basically, Google, they've got a lot of money. So they don't know what to do with it. So they are going to share some of them with us. Through the Google, some have got projects. So basically, Google is funding some project like us. And so they are selecting the organization. Basically, you will see the schedule after that. But they are selecting the organization in doing math. And after that, the organization, they have to start to propose some project and select and ask some new mentor to come in the team. So Google is going to fund all the students and the mentors. So every student is getting $5,000 US. And each mentor 500. The mentor, it depends on the organization, is keeping the money or living into the organization. So here is some figure about this year, Google Summer of Code. So as you can see, more students than last year have been funded. Last year, it was something like 1,000 students. And they also increased the number of organizations. So now we have 1,115 students for 175 organizations, which is something like 30% more organizations than last year. A lot of students submitted a proposal. So as you can see, about only 20% of the projects are accepted. I'm not taking into account the duplicate proposal. But still, it's a lot of proposals. And as you can see, pretty much a few mentors are managing two projects. And the budget is quite important, $7.2 million. About us. So this year, we had nine students. They all passed midterm. We had 30 proposals submitted, which is normal for Debian, which is not something which is different from the last year. We have also 30, usually Debian developers who are registered on the interface. So that means that many people in Debian are interested by that, or at least looking at the project and so on. And we had only 20 subjects suggested on the Wiki. So I hope next year we'll be able to put more subjects and prepare things before, because it has been a bit hard to get all the subjects in the right time and in the right condition for the Google Summer of Code. So right now, I'm going to present to you the various projects which have been selected and managed during these few months. So the first one is managed by Wookie, who is a mentor of this one. And the student is Gustavo Prado Alquim. Oh, right on time. Gustavo is designing a modern automatic packages built system for the QAE, a multi-arch area. And we won't go into the detail. If you want more information as Wookie or the student, it will give you all the information. So the two next ones are mentored by Michael Vogt. It is about APT and DPKG. So the first one, the second one, the Delta APT native packaging is to improve the user experience of APT. And the second is changing the ordering of the Lib APT for unpackaging and configuration and so on. So the fourth is mentored by Steve Lagazek about DPKG declarative diversion. So this one is to replace the DPKG divert command with a new control and the declarative system. So I won't go into the detail of this one. If you want to have more information about the one mentor by Matt and Stefano of the Natan Handler Project, you will have a look to the video. Stefano made a presentation of 45 minutes on this. So you will find everything you need. But basically, it is to manage the patches coming from derivative and all the program related to derivative distribution. About the next one. It is tomorrow here at 3 o'clock in the afternoon. It is mentored by Tom who is in the room and myself and the student is the guy who is in charge of the camera over there. So it is basically just a few words. It's basically when you are downloading the Java virtual machine, it's a huge package with everything you don't need inside. So basically, you split it into various modules and you just take whatever you need. So it is a very interesting project, but obviously because I'm one of the mentors. The next project is a Python build for Python extension packaging. So it is mentored by Pyot who is in this room. I won't say his family name to spell it badly. The student, it's Metsukan Kurt. It's about creating a tool to build Python extension for all Python versions supported by Debian. And the last one, we are going also to have a presentation today at 2 o'clock in the wrong room managed by Andrea Steele and developed by Sukir Singh. Sorry about your name, he's also in the room. It's about how to measure the activity into a Debian team. And the last one is a mentor by Stefan Muller. And the student is Rudi Godoy. And the goal of this project is to enable developers to easily use computers cluster, such as a Calypso OpenStack. So now, Arthur is going to tell you more about how to participate to the Google Sumof Code. This year, we would like to highlight how to participate to the project, what we are expecting, and how we are expecting things to come and what we need from you if you want to become a Google Sumof Code mentor. It says, but we don't have to speak louder. So how to participate? Because we only admins, and we're not doing most of the work here, doing the most of the work. Where you can be a student or a developer. So when I did this talk at 4 o'clock, I usually talk a lot about what's on the floor. Do you hear me? Yes. So at 4 o'clock, I talk a lot about what students are expected to do, which is very cool, because usually, the room is completely packed with students for some reason. But we are at DevConf, and most of you are developers. And we need you to help us mentor students. And you have many questions, and we have many things that we'd like to tell you about it. So the question I get the most often is, what exactly is a good GSOC project anyway? Like, I have a bunch of ideas, and I don't know what really is relevant to the GSOC. We have several criterias to accept projects and to see what projects is really good for us. The one that the first test is, try to replace Debian by Fedora in the proposal. Does it still make sense? If it still makes sense, probably it's not a project that is relevant to Debian in particular. And this is a test where many projects proposed by students fail, because they send the exact same proposal to every single Linux distribution they hear about. We're here to do projects that benefit Debian, that exploit the particularities of Debian, that work on the very specific infrastructure of Debian. So we don't really want to do GSOC projects, whereas the real focus is not on Debian. The second most important thing is the time scope. Is a project going to fit in two months? It shouldn't be too short. It shouldn't be too long. A summer is supposedly three months, but you have to take into account that the student is going to take three weeks to figure out where everything is and be able to ramp up to a development speed where it can actually get things down. So that takes a few weeks off time. And then at the end, there's all kind of frapping up things and preparing a release, hopefully. And that also takes our time from the summer. So you have these two months in the middle of the summer where you need to get everything done and ready. And at the end, we want to see something released within Debian. So that's the time scope. The other focus is Debian focus. Whose work does a student's project replace? Many times, we have packaging projects that usually fail because it's replacing the work of one single DD, one is a DD. And some other time, it's subjects that really are not really relevant to Debian. It's more upstream work. When the work that is replaced by the student is supposed to be done by upstream, then it shouldn't be our job either. So that's also the question of broad interest. We have this subject. How many DDs are enthusiastic about this project? Is this some kind of thing that one person is interested in? Is it something that only one person actually understands within Debian? Then it might not be something that is very good for this project. First, because of the bus factor. And second, because we want all the DDs to be able to interact with the students, the work, the release product. And we want it to be used broadly. The one interaction, as I just said, the student in the course of his project has to be able and has to have the need to actually interact with as wide as possible spectrum of developers within Debian. If it's a project that is only concentrated within one single team, the student will never really get to see what the social aspect of Debian is. Having to interact with other developers that we don't necessarily work every day with, having to talk with people that we don't know, working with on different subjects, and having to get the help. This is something that we think is very specific to Debian and something that we want to be able to have in a project. On the other hand, these are all restriction projects. And something that you have to keep in mind is that there are 175 projects. When the list of projects get published, we get a giant, there are a group of students going to this giant list of projects. And they go to everyone and click on the ideas list. And so there are literally hundreds of different projects to choose from. And these are not students that are necessarily captive to Debian. So it's a competition. If we want to get students, we have to propose something that they have to be enthusiastic about. The kind of projects that students find exciting are projects that have wide interests within the project. It's something that, in the end, creates a product that many people will use within the project and outside the project. It's a project that creates skills that they can reuse somewhere else. If it's a project that is about fixing one particular aspect of one particular sub-module of one particular software within a project, and this is something really tedious that no one cares about and that uses an obscure language, it's probably something that is not going to be interesting to the student. Even though it might be very important for the project to get down, it's not something that you're going to attract students with. And finally, the work of the sum of code is it's an interaction between the student and the mentor. The mentor might come with the idea. The student might come with the idea. But most often, because the mentor is the person with the most experience within the project, he often has a huge set of requirements. He has a very firm idea of how it should be done. And we should always leave room for design for the student. It's his project, and we want him to be able to feel a sense of freedom within the project, being able to interact with multiple people, being able to propose ideas, propose ways to do things. And that is something, I think, that creates very exciting projects. And we really need to work hard to attract all of the students. So for next year, it starts now, really. We need to have detailed projects with some objective posted to the Wiki. We have to start now, because when the deadline comes and we have three days to come up with hundreds, well, at least a few dozens project ideas, it's very hard to come up with these ideas on the spot. And all around the year, you're doing things within Debian. And you come up with things that you want to do, but you don't have time to do it. Or it's kind of an excursion from what you're currently doing. And maybe it requires something that you don't really know. And maybe some student really knows about it. This really happens. So during the year, keep in mind that during the summer, there are stuff that can get done. And so not shut down what you think you'd like to do, but you don't have time to do. Or something that you're passionate about and that you'd like to have a student to interact with and do with you. You really need to start thinking about this now, writing them down. Something that we think about every year is that the Google Sumof Code doesn't really enforce that students, selected students, have to be complete newcomers to the projects. They can be existing developers. And many projects actually use Google Sumof Code as a way to find their current developers. We at Debian have the position that we accept both, but we would prefer to have newcomers, of course. We want new developers. And if we have both newcomers and existing developers for the same project, we, of course, have higher requirements for Debian developers because they have already an existing set of skills of contacts within Debian. So the schedule, as I said, organization applications start in March. That's still in quite a while. And the student application starts during the end of March. And within a few weeks, we have to decide these students are going to talk with every single organization. They're going to look at all our projects, ideas, lists, and choose some Mac applications, usually just a few. And at the end of April, we are going to have the list of students that we're going to select. Sanjay Jisok goes through the summer with an evaluation at the midterm, which is mid-July, which is just right before. And a final evaluation at the end of August. So really for next year, think about things to propose. The larger the list of ideas we have, the larger the list of exciting ideas we have, the statistically larger proportion of students we can attract to Debian and possibly keep as Debian developer for the future. Thank you. So we are going to accept questions, or if you actually have a project ideas right now, we'd love to hear it. So I think one question that comes up is, maybe can you explain a little bit about how many projects Google is likely to accept and a little bit about the process of how to be successful in proposing projects for Debian? Do you mean from the point of view of the organizations or from the point of view of the students? So there are two applying processes within the Google Summer of God. First, the organization has to be selected. And last year, 175 organizations have been selected. And we usually get in the range of few hundreds, I think, organizations applying. Most of the big organizations like us get selected every year as long as we don't do anything stupid, which has happened even for high-profile organizations. Google is a set of critters for acceptance. The first one is there has to be room, of course. They have a defined budget. So every year, they have different set of projects that they accept and that some smaller medium-profile projects get rotated. And they're all kind of different reasons why you might get selected or not. Maybe Sylvester can tell us something about us. Sorry. Tell us more about it, because we as Debian haven't really thought to get selected because we are kind of high-profile. But for smaller organizations? So you mean basically to explain why he's saying that. I'm also an admin for another software, which is Sylab. So you are meaning that Sylab is not a major software? Basically, it's pretty easy. In fact, the perception of Sylab outside of the scientific world might be low. But it's a bit software with a lot of references. It's three million lines of code, so it hasn't been very hard. Just have to make sure that Google knows that you are a major project in the field you are working. And after that, to answer one of your questions, the number of slots that we are getting is basically an algorithm with a number of mentor we've got and the number of application we've got. It's basically an algorithm. But there is a funny part in the Google Summary of Code where you request a number of slots. So basically, last year, we think we request something like eight, and we add eight, something more or less. And there is a funny part where you can exchange slots with other projects. So as Sylab, I gave some slots to other projects in the Debian community, which we are not Debian, but you can exchange them. And you can request for more, and you can start to send email crying that, oh, I want more slots, and so on. And usually, it is working. So they are very relaxed with that. So from the point of view of the students, and the thing is, it takes a lot of effort to make a good application. And most of the students can get one, two, maximum three applications that have quality that is good enough to get selected. I participated once the first time in the Google Summary of Code the year before I began admin. I made two applications, one for Debian and one for Tor. I got selected at both, and I chose to go to Debian. But it really took a lot of time to write the applications. The applications itself was in the range of, I think it was like 4,000 words. It was a real outline with schedules and everything. So most students will do about an average of two applications. We have some students that try to do spam applications. Like I said, if you can replace Debian with Federa, and it still makes sense, then we're not interested. So some students would write this one application and send it to 10 different organizations. That usually doesn't work. Pretty much for students interested in participating in Google Summary of Code in Debian next year, around January, beginning of March, they should start looking how Debian works. So in the beginning of March, when there is already the fifth projects, they can select, they can get in contact with the mentor, and they can start working. Because how many, two, three weeks they have for submitting the proposal is very little time. Any other question? Okay, thank you very much everybody for coming.