 I'll just use this, if you feel sort of like waiting. OK, so, well, who wants to talk about summer of code stuff? I think maybe everybody does, to some degree, because I think we'd get two people who were a little disappointed that they didn't get to have a student that was in, that was pretty sad. But in past years, we just kind of combined them. So I'll sort of start with what happened with summer of code this year, which is, basically, you know, I think Thomas started us off in maybe February or January saying, hey, do we want to do it? You know, we need to come up with ideas. And the ideas page kind of filled up mostly with projects that were ones that never got picked in previous years and a couple new projects. And then I kind of came about a week before our application was due and said, hey, you know, these projects suck. And I don't mean they're bad projects. I actually think they're things that would be cool to get done, but I think they're projects that, A, they didn't get picked in previous years, and there are some new projects, too. But so I think there's a good chance that they're not going to get picked again this year. But B, I think the scoping is wrong, that we have problems of saying, this is something that I'm someone who works on Git and I know a lot about Git, and this is something I would find really cool if we could figure out this is a longstanding problem with Git, you know, something like dealing with large blobs, you know, I get log-l work that Thomas worked on, these sorts of things, these are awesome projects, and we get excited about them, and they're the things we want to put on the ideas page because they're awesome. But it also means they're horrible projects for somebody who's just jumping into the code base to start on. I mean, yeah, it's one thing to say, oh, well, these people can, you know, they have three months of summer of code to work on this, that's a long time, that's, you know, I just can treat it in my spare time, you know, that's a lot more time than I have. But you have to bear in mind, too, that there are a lot less experience both with Git and there are also a lot less experienced in general because they're usually a lot younger and college students and things like that. So I think one of the problems we've had, and I think we have had a lot of successful GSOC projects, and I do think we want to be a part of the project, part of the program again, because I do think it's good. But one of the problems we've had is that we have these really cool, big ideas, like a great example is the rev caching work done by Nick Adolin in 2009 or 2010, I can't remember now. And it was a really great, ambitious project to say let's cache incremental traversals of the revision graph in a way that we can, that we can reuse work for things like upload pack or pack objects and things like that. But it was such a big project that at the end, he basically, the GSOC length of time was enough for him to come forward and say, okay, well, I've got a thing that kind of works, but nobody really understood it very well. It wasn't integrated into the code base very well. We weren't even sure if it was the right approach or not. And then, of course, at the end of the summer, he went back to school and was very busy. And I don't think, I don't blame him for not working on it more, like it was a huge project and he had lots of other things going on. But in the end, it didn't actually help the Git project at all because it never got merged, right? So I think I'd much rather have smaller projects that are less about doing something amazing for Git, something that we're like, oh man, how come we haven't done this in the last five years? Well, it's because it's hard. And doing a project that is more about getting the student to integrate it into the community, having them work on a smaller project that is less glamorous, but will actually get done, will actually follows the approach that we take with our own patch series where you actually, you know, my average patch series, like if it's going on for more than a month, it usually means I need to be breaking it up into smaller pieces, you know, that nobody's gonna review your 100 patch series because it's just, it's awful. So my feeling was we shouldn't do summer of code if we're not going to, if we're not gonna come up with projects that are moving in that direction and then I think there was a lot of dawdling and a little bit of discussion on the list and then the deadline passed and we said, oh well, it's probably better to take a year off anyway. So that's what happened with summer of code. What's gonna happen next year? I think we should do it and I think we should obviously follow the direction that I just outlined, but I also, I don't wanna make a decision like that unilaterally, so what do other people think? You know, do we agree that's a good direction to go? So to me, the two issues are project selection or project proposals, having a better scope and also integrating students into our community a little bit more. And I think LibGit too has actually done a lot better job with that because you've had projects, I know Carlos, you were a student, Vicent was actually a LibGit too student originally and Shu, you were a student this past year. And I think that's worked a little bit better. I don't know, maybe you choose better scoping, maybe you just are better at getting the people integrated, but so anyway. So those are the directions I think we wanna go. So I'd like to hear discussion from people on is that a good direction for us to go? Would that solve some of the issues we've had? And I think Thomas is maybe gonna give us some numbers. But then also, if we're gonna do smaller projects, what kinds of smaller projects? That was the thing, I think that was the blocker this year was nobody said, okay, well here's, we need smaller projects, okay, well here's a list of five smaller projects that part didn't happen. And I think it would have happened, I think we just kind of didn't start talking about it until too close to the deadline to do those things. So I can just keep talking while I get ready. To be honest, no, although I mean, there are a few. So one of the things we have, and I think one of the things that makes me think that's the direction we need to go is Matthew Moy who is a professor of something at some place in France. I don't know, but he's a frequent contributor and he has his, it's Ensamag is the university and he has his students, I guess he runs a summer program where they take a class from him and he puts them in maybe groups of four and has the group of four work on a project that is honestly the scope of it is not very big at all. They end up being these things that you're like, I could probably do that myself in about a week. And he has a group of four students do it in about three weeks, which seems crazy but is about the right time for somebody because it's not the project, that's the hard part. It's figuring out how open source works and figuring out how the code works and getting integrated into the community and all those things. So I think we've had a lot of really good success with that because he's figured out how to do this scoping because he gets on his students to, he's like, I don't know how he does it. Maybe he promises to withhold a good grade from them if they don't participate in the Get Mailing List or something but presumably that's what he does and they end up actually becoming a better integrated with the community. And some of them, I think most of them don't stay but I think they've learned a lot more about how to do that interaction and their code gets merged so it's kind of, everyone's happy. So would he refuse to do that project? He does, I mean, he basically runs his own summer of code himself. Do you know if he does intensive mentoring of those students? I have seen him do mentoring of them on the list. Like he's kind of like CC me on all the patches and he helps with the review and makes sure that that is being pushed along. I don't know what kind of mentoring he's doing off-list. I assume there's some. That could be, yeah. Well, the groups are but I don't know if Matthew is working with them or not. Yeah, and they certainly have each other and that's something that GSOC actually discourages. You're not supposed to work with someone else. I shouldn't say discourage because it's not like they want you to become part of the community but what they don't want is four students sharing a slot kind of thing because it just creates too many headaches. Are you ready? No, the video isn't working. I just wanted to add that Matthew's projects are, I think in the hot phase only three weeks, right? Yeah, I think that's. I'm sure there's some preparation but three weeks is far smaller than the other GSOC over what, 10 or something? It is, it is. No, and I think they need to be, well, but you're also talking about several students working on one three week project versus one student working on it. I mean, because as we all know, manpower is shiftable between time and people. I actually think that the idea of a three week project is incredibly helpful for an intern to start out with something that is a one to two week project that they ship. Yeah. The thing is we'll pass it through and you then have to create a unit in the process. Right. I mean, to the extent that we could, I don't know if it's possible under the terms of Google Summer Code, but to the extent that we could say this is a two phase project. Oh yeah, we can totally do that, yeah. There are, you're gonna have this initial set of things that you're gonna do where we might judge it as literally like a weekend for the park, but to give them to make sure that there's a shiftable. Yeah, and I think that's the key part, yeah, is that there be a shiftable phase because I think that's what we run into is there's not, the first important milestone is like one week before the end of the program and then we don't, they never ship anything kind of thing. And so, right, no, it should be something we consider trivial because then it's easier to mentor them on the community issues and the integration issues, yeah. Yeah, some, some, right. Well, that's not always gonna work out. I mean, I don't think that, right. So yeah, I know that a lot of other summer of code organizations do that, basically. They won't even take a student till they've gone through that shipping thing. Yeah. Yes. The next thing is, and so I decided to break it into smaller parts. So, I think we have a task to move the dog get directly out of the sub-hub. It was one task. The other was to improve push that it became something to be aware. So, we had this little task less, which we were like one week or so, or a few weeks, and you could push one patch series to the list and start working on the other thing. So, there was no dead time, which you have when you're working on just one series. Yeah. So, one was waiting for commands. You put work on the other stuff. And it was surprising that I really think I could have done the same thing and much less time that I spent on mentoring him, but I think that's a point of force. Right, so yeah, I think that's a mistake that we certainly made early on, was to think, oh, it's kind of like pre-coding work. And it's not. It actually takes more time to mentor someone to do the project than for you to do it yourself. But hopefully you're... Frankly, for each possible mentor, this is going to be easier to do it yourself. Right. You have to do it for different reasons. Right, exactly. And I think that worked out really well, but, well, students are different. Sometimes you get a really bright one, which is just schools out of school. It's not really that close. Yeah. But then you can even extend the scope of the G-sub project. And sometimes you get students who are not that fast, and then you can use a lot of that. But you have to do this, otherwise you'll let it fail. Right. And that's what I think worked really well. So that's what I propose, not one topic, but I have the impression that we could use an IMI merge driver. Maybe we could do some other merge drivers. So maybe one G-sub project could be white merge drivers. This and that, if you have a try. Right. Then it's one piece, or one area of itch. You just have to be used to and you can put in other merge drivers if you see the France, or you can say, OK, that's all right. So yeah, I would agree with all that. And I think a lot of it comes down to the simple idea of work, get them to work how we work, because there's a disconnect. Like, we don't go away from the list and come back three months later with a giant, with something. We have lots of little projects going on, and that's something that we haven't. So it may not even be change the scope of the projects. It may be break them down better. I'm cool. Yeah. I also think that's probably, yeah. This is a fucking sporker. Yeah, I made some statistics. I had this slide also, but I think lunch will do for that. I did this yesterday on the train. So about four hours in total, I think. So it might be very wrong, but I just wanted to dispel this impression. At least I got from the thread that everyone has the impression that we suck at the Google Summer of Code. As far as I can see, this is absolutely not true. So it's very hard to come by other projects or other organizations in GSOC terminology, statistics, especially if you're on a train and 3G internet, if at all. Ourselves, I mean, you can dispute these assessments. This is what I could figure out in the time given, and I should also say that Ramkumar, who's unfortunately not here, also contributed some corrections to this. We have slightly over half, you see it at the bottom. It's not the same 12, but slightly over half of the projects that I estimate were merged in some form. So for some of them, it might not be the whole thing, but they seem to be merged in a sense that I found some commits that sounded vaguely like the project proposal in the timeframe given, which was as far as I could dig. And we also seem to have 12 contributors who contributed significantly after the end of the GSOC. So you can see in some cases that I counted like, where was that guy? There was someone, for example, in September who had some commit, so that's outside of the strict GSOC timeframe, the very last commit that is in any of the repositories. So I don't know. I mean, in German we call this suffering on a very high level, seems to me anyway. I mean, I'm all up for fixing it, but now that I made this list, I don't see the problem. Well, so we're like 50-50, right? For merged, we're just looking at your 12 out of 23. Well, do we have any Googlers here who can say what the retention rate on Google internships is? Some projects do better, some do worse, I think we're actually not that much. Retaining contributors. Well, in terms of retaining interns, you wouldn't retain a future. Oh, you mean a normal Google internship? Yeah, it's that one. You have no idea. That's what I hoped for, right? So we can compare against that, because my mindset is basically they're paying internships, right? It's basically a summer of paid work, so it's an internship. I did also try to run some statistics. So this is the time scale is normalized to start on May 1st of the relevant year. The dots are color coded so that the green ones were merged and the black ones were so-so and the red ones were failed. And my conclusion is that there's no conclusion. Except that people, you can apparently draw the conclusion that only projects that were merged had some contribution beforehand. But this doesn't hold in reverse, so yeah. I did the same on mail, though I should say that it's even less precise, because for one thing I didn't have an EGIT list copy offline. For another, it's harder to match on the actual usernames because people have various others and stuff. But it's similarly no conclusion. So that's for statistics. Should I, I mean, most of it has been rehashed. I made a summary of the thread. So, okay, we saw this. So these were the theories in the first thread. I think some of them we could probably write down, right? So one I particularly agree with is that we should stay far away from political projects. So it's your coinage, but these are projects where the important part is convincing other people that this change is not breaking others' workflows and not actually the writing codes. To your point, Dimitri, in terms of my impression from your first line is that things are getting better in recent years than they were. I think this is my point. Yes. And what I meant was that as Git matures, there's less of this frontier, this border, and everything becomes a little more core and a little more ossified, but it's hard to change things. I don't know if that's true or not. I mean, I'm glad this is listed under the theory page because shit I write in an email, like in the middle of the night, is not necessarily well-known. This was really meant to be a summary slide, so I didn't really try to value the theories. I have more summaries. So these were the ideas in that thread. So I think some of them we've already heard. The last one might be interesting. So there's been this idea that we should start again of sorts and do this on a small scale. I think that depends on the dimensions we have. Sure. Probably also give it all to Lipkit. You always have a co-monitor. I did co-monitor with you together and I co-monited you, which is really good because staying responsive over three months of time is pretty hard when you have a life. So you want to take something off or stick it in your scoops. You have someone to pick in. Where's the time for that? So I really strongly advise you to get a mentor and a co-monitor. So that maybe sets up a limit on the projects that when we have like three co-monitors, which one is here and two mentors, that makes two projects. I think during the last years, we have had more mentors than we do with students. So this was not a limitation by the number of mentors. That is true. Yeah, we always have more mentors. I've volunteered to mentor every year and no one ever chooses any of the projects, which I think I'm... Oh, we'll look back on the series page on, I think, the top one is me, but... So yeah, no, I do think we have a lot of mentors, but often the area overlap is not as good. Like, I wouldn't really want to mentor somebody on sub-models because I try to ignore them as much as possible. But that's an area where we actually have two good mentors. But I would just worry with a co-mentor situation. It's nice to have a backup, but that backup's only useful if they're keeping... If they're almost as good as the first mentor, if that makes sense. Oh, that's not true. Because I was not that professional with the area that Bo Young attacked when I was co-mentoring Thomas. But when he left for holiday, we talked about what is to be done, what areas... I had some people like you who were the main of that question. So the basic thing is that I'm responding to the student and giving them the next push into the right direction while I'm looking after him, that he pushes the patches out. And you can do that even without being that proficient in the area and just what it's about. But they have to have the skills in knowing what the name is about and how the community works. But that's one of the part of the thing to teach. And probably one of us can do that. Okay. So you argue that we should basically always have a co-mentor even if the person is not in the area? I think he has to be willing to do that. And I'm not saying like, you say something about stuff and don't do it. Right. I think you can even co-mentor for stuff you're not very proficient in but know something about. I didn't know much and I still don't know much about the GIP law infrastructure. But I was seeing the patches flying by and I was reading all the discussions those guys had. So it was going on, what parts of the code were international. And I've always had people I could ask if I didn't know the answer myself. So when I was listening to him, okay, just let me check I asked someone else and come back with the answer needed. So that's something I think almost everyone of us can do. When I work with interns, actually it tends to work better if I don't know the area very well but I do know how the process works well because then I learn with the intern, the area. But you do have the perspective a lot better. Yeah, yeah, you don't just go, oh, it's this, you don't take all the shortcuts. We do, when you can guide them on the, this is where you go to find, this is where I go to learn. It's also a good way to get people to engage with the community if they're not getting the sort of technical expertise that they need from their mentor and the mentor says, don't bother me, go to the list, here's the person to CC that's actually a much better way to mentor I think. So I promise our mentors don't suck it up. You can be our new professor. Yeah, I'll take care of that. I would also suggest that we actually go for several co-mentors and for trying to split the image of the mentor a bit because, I mean, what you're discussing now, right, is this guidance mentor. But what we also need is a review mentor. And I think this will have to be a group and this group will have to be big enough so that we can basically guarantee to get the review, even if it's a fairly large patch in some useful timeframe, maybe 48 hours, because we don't have the luxury of being peff and having 15 open series and saying, okay, I will go and work on something else instead. But this is the student's job, right? The student wants to get this review and work on it again. And this is probably one of the areas where I qualify as an example for mentor suck, Michael Field in last year, right? To some large extent. Maybe this will also be easier or harder, I don't know, to motivate people to sign up for one job, but not the other. I have a question about the project scope, because on the one hand, a small project, certainly it's much more global. And if they get it done and they have extra time, I'm sure if they're interested, they'll just work on something and then nearby. There's never a shortage of work to do, especially once you've dug into some topic. On the other hand, I'm curious, is it hard to get students on projects that don't sound sexy, that sound like they're just so... Yes, I think there is actually, because we have sometimes less clamorous projects on the list and then the ones that don't get picked year after year. And like this extended cluster, so I've... So like I said, I've never actually mentored because no one picks my projects, but I have participated in the proposal review every year since 2008, I guess. And students cluster a lot on, we'll get like a hundred applications and there'll be most of those, 90 of those are on two or sometimes three projects and then the other ones are usually, there's usually 10 that are just awful that you don't even wanna like... Do they cluster on the undoable huge scope projects? Yeah, I would say so. Because they're the most interesting sounds at once, right? So maybe we should put laser and all the uninteresting things in there. Thanks. Show them something you can do for us. Comment for Maddy and lasers. Yeah, I mean, there's always a question, right? You wanna find someone who will be a match for the project and the community, right, particularly? So, I mean, actually I'm curious, like for the folks here who were Google Summer of Coast students, I mean, obviously, you have a very particular personality such that you were a good match long-term for kind of becoming an active long-term participant. Were there particular things that you were looking for when you were trying to figure out what project was a good fit for you? Like, obviously you were willing to do things that were not just, you weren't just looking for lasers. So, I don't know, I mean, frankly, I'm interested in finding other people like the students that we've had who are not just drawn to something flashy, but also are drawn to through every aspect of things because becoming a long-term participant means that you don't spend all your time doing the glamorous things. Right, so the most extreme form of that would be to say we should stop having project proposals and we should just have people proposals and then we should tell them what to do. Is that even viable? I mean, as far as Google's concerned, we run it how we want, you know, we take in proposals, but I think, yeah, I mean, it's almost more important to choose a person who's gonna be a good fit for the community than it is to choose a project that we want to get done or that we think that person might be a good fit for because a person who's a good fit for a project but doesn't integrate well into the community is gonna fail in one way or another, you know? But I think one thing we've tried to do that's maybe a sort of nailed experiment is the project proposals on the ID's page usually have some gaps in them. And this is a way of taking students that have that kind of planning ability and have that kind of big picture understanding that they can fill it in in a realistic way and, you know, we, like, they could do this really ambitious thing and that they don't choose this really ambitious thing that's unfeasible, it's like a really good sign. Of course, that has side effects that are not great. Yeah, no, I've been either guilty or can be credited with that experiment many times because I try and do things like, I'll put a project proposal that's like, we should make large block support better and the solutions could look like A, B, or C or some combination of them. And I keep waiting for the students like, man, I totally understand this problem and like, we should, like, this is what we should do. And I'm like, yes, I didn't think of that. That's never gonna happen. That's so stupid. And so, yeah, I do think we have been very, we have followed that kind of procedure and I think it's not the right direction to go. Yeah, so I think the problem is that we should have criterias saying what we are going to do and how we are going to judge each project and each people, each students. And also, criterias for how, for if we are going to do a GSOC and how many students we are going to have, for example, and who is going to decide how many students is using which criterias and so on. I'm sure you know that that's pretty much a given, right? Google gives us an upper bound that we can still decide to not take some slots. But the, yeah, but we can't really pick the number. We can always say we're overworked, but we can't really pick the upper bound. How many do we want? Yeah. I think we're making this the year before we got the extra stock of two more. Yeah, it's, yeah, I mean, so Google comes, after we got the proposals for a while, and we started ranking them, we're supposed to come up with numbers and see what kind of thing we'd like to have in our wildest dreams we would have. And then there are M that we totally have to have, like if we were to take those, if we don't get them, that's sort of the lower bound. So it's basically a way of giving Google an upper and lower bound for what we want and they come up with some number usually between there and unless our lower bound is really not realistic. But usually our lower bound is like two and they always give us at least two, so. And so I guess we didn't get five of them, I think you just had numbers up, but. I think. Yeah, they were five in one year. What was that? Yeah. 2011. Yeah. 2018 and more, six. I think 2008 actually was easier against lots because the program was still starting a little bit and we had participated in 2017. In 2017. In 2017? Yeah, in 2017. So I don't know, I would also like to discuss on the topic of mental stocking this scope creep issue. So okay, I won't switch again. I snuck it up on the theory summary because it wasn't actually in the thread. There's this tendency of any Git topic to devolve into a discussion of how to properly solve this if Git were actually a maintainable code base. For example, I mean this wasn't GSOC but it was the spin-off from GSOC, log-L got held up the last time it was held up on the grounds that in theory it should be possible to somehow wire it into the GIF and log pipeline if you could call those pipelines. And I think this is a danger where we actually, as the org, have to first figure out if we think the project is feasible in any way, right? And this, I think, it doesn't only happen to the GSOC projects. It happens a lot. You're one of the few people who can anticipate what the refactoring thing will be and integrate it into the front of the series. I'm clear, I'll say exit strategy. Imagine you give a certain topic to a student and the worst thing that could happen is that he starts working at it and okay, it doesn't make a finish in time, but then this topic is blocked. This is because we have no good idea, I mean how to deal with, okay, we are thinking he's not working on it, but okay, maybe he's not responding or so. And this is for me also a problem giving those projects to, for example, areas which are important to me because I have the fear if this fails, if the student stops working on it, then I have a lot of work getting this topic back to normal because it's somehow occupied. I mean, we need this problem because of some legal reasons things couldn't get integrated, we needed some okay from the company, so that he could call you, but this was not done in time, and so we get really stuck on this topic for months. It just took a lot of time for the members of... I don't think that's been a problem for GSOC just because at the end of summer if things aren't merged, we're kind of happy to write off the student games. We're not like, don't work on that because there's a GSOC student who's on merged work is still sitting out there. I mean, we encourage people to like, when you look at their work and see if it's good, and that's what Thomas did. I mean, that was two years after Bo's work that you basically cleaned it up and submitted it, which, I mean, ideally it doesn't take that long, but I think that was great. It was valuable work, and somebody could have come and worked on it in the meantime, but it turned out the best way to do it was to pick out his work where I've left, you know? And then... It's a lot of time. Oh, yeah, yeah, yeah. It's after we have worked on it. I'm not sure it's such a big problem. And also you said that the problem of unresponsive students, I mean, I mentored two of the projects in the last three years that we didn't really get somewhere, like Bo Young and Thomas Goumar, and I can assure you that unresponsiveness wasn't a problem. So Bo went to real life and got a job at, I think, McKinsey or something, immediately after the GSOC basically, so he disappeared. Thomas is still sticking around, but in any case, during the GSOC, they definitely weren't unresponsive. We have had unresponsive students. The guy in 2009 who failed, I was sort of, I don't think I was co-mentor officially, but I was sort of pseudo-co-mentor for him, and he became unresponsive, and actually he was pretty upfront about it. He was like, oh, yeah, sorry, and then we just fell in the middle of school with that and whatever. So yeah, I mean, those things do happen, and I think it's just part of the process. It sounded like the situation you were in, it was good work, but there were legal things, which we don't usually run into as part of GSOC. I mean, that sucked. No, I mean, maybe this guy was working for a company, and he was allowed company rules to participate, unless the lawyers in this company said, yeah, yeah, yeah. I think GSOC is easier than that for that, because there's a lot of signs, forms to sign up for us. So if they're okay, okay. Yeah, I mean, they can't have another. You have to be enrolled in university, and it's always labeled as a full-time job across summer, so you wouldn't have another job. We're pretty good at being sort of impolite and disregarding the value of the sweat and tears that went into some work by either abandoning it or just re-implementing and sort of ignoring it, even during the summer project. I mean, well, so I only have one example of this. Is that when Robert was doing the Subversion Room of Helper, this worked out really well, in that someone else did, David Hart did some work completely independently, like right before the summer of COVID, like very much overlapped with what he was doing, and made that work, like he helped out with that, he did some patch review and upstreaming of that and did other things during the summer, and it worked very well. So I think that can be made into a non-problem. For this thing of students being non-responsive, I've also run into that in like, even with students, they sort of test the boundaries, and I think as a mentor, I would have liked to have a little more support from the organization in terms of, these are the guidelines that all of our students have to follow in order to be allowed to continue with that kind of thing. And I know new formal things isn't fun, but it might be something that we should do. I think, I'm not opposed to having more guidelines or even rules, I think, and I think that's a lot of what happened this year was just we came to the realization of a lot of these things, too close to the deadline to actually come up with those rules in time, and that's why we're not in it this year. So I'd like to, I'd love to have this conversation over this summer on the mailing list and hammer out those rules. Maybe before the summer. Or maybe before summer. It's almost summer now. Oh, yeah, this summer before the summer. Yeah, I mean, yeah, yeah. There's four next year, so we're not scrambling in January or February to try and have a discussion again. So some of these guidelines are like, if the summer code projects are set up, you have to like every week or every couple of weeks you should send an email saying I'm not working up to. Yeah, I think that's like way too infrequent, actually. I want to, I think if you're doing Git development as your full-time job over the summer, which you put over a code student should be, then you should be on the mailing list almost every day. Yeah. And you should, and I actually think this, we should be getting people to review patches, even though I don't trust the review from a GSOC student, but like many eyes can spot lots of problems. And I think as long as they're being mentored in their reviews, they're not the only reviewer to them, I think that's a good thing to be doing. They should be talking about all these other side issues and stuff like that. You mean GSOC eyes to see sometimes not clear, or like if they don't, I don't understand this, or like this means a little bit of work, maybe. But that variables just has a stupid name or something. Sending these through the emails, like what we did with the commentering was that he first sent the patches to us and we were going to take off the upper stuff, which is like white space and whatever. I feel like that should happen on the list though. And other people can share that. I'm more than happy to tell people that white space is damaged. Yeah. Volunteer card. But yeah, I understand the point in saying yeah, sometimes these patches need a lot of work to even hit it to like list quality. But you know, people who are GSOC students also show up and have those problems. And we did it for two reasons. One was that maybe the students get anxious to put stuff on the list. At least I was the first time we did it. So we had the opportunity to send it to us. We were over it. So we don't get full of this stuff in public. And I think that this helps. And with the time you see the amount of what you do before you send this stuff out, degrades, and I think at the end of the summer, you send the patches first. I think yeah, I think that's fine. I think it helps. And it helps to get the noise of the list. Because sometimes you just begin with mistakes. And it doesn't matter though. So I think it's part of your responsibility that you don't flood the list with things. I think the list is good. I think it sort of helps people who are not the mentor to feel that there was a project happening and to sort of help out when they come. And you think it's like the first couple of series to get pretend your series to the list was in it to me. And then you can point out the obvious things. Maybe we can end it sooner. So I think the first series should go to the list. Yeah, I understand those students are really like that. I said the first series to you. I told them I like it. Then the next kind of series goes out to the list. So I can maybe use that as a rule of thumb next time. Of course, none of this applies to Libya, too. What do you guys do for your GSOC students? I mean, you guys are doing everything through pull requests on GitHub. And we have them in chat as well. Yeah, that's true, yeah. We do have a lot more real time. The group is small and mostly in chat all the time. We have people in chat pull requests. I'm not supposed to learn how to improve, too. Right, and we have tons of small things to get started with. Another thing to be successful with that, well, there is this standard to problem against. Like, oh, we should behave like it does in these situations. A lot of the kinds of work we've worked out by getting existing. Right, and so much of our work is just catch up that it's not. We're far less likely to propose a research problem than far more likely to propose A. The goal you're shooting for is extremely well defined if I get already, so I wouldn't say extremely well defined. Well, at least there's a reference in the window. The only thing to work straight, either it does what it does with all the words and principles, or it doesn't. Okay. Is it either it's compatible with Gain or? Although that's actually an interesting thing that we haven't talked about. I mean, the Google Summer of Code students on Libya 2 so far have worked primarily on Libya 2 itself. But we actually have a bunch of binding folks here. And it's one way, if we wanted to expand the projects out of C-expert into other languages, plenty of the bindings could use lots of help and might be an opportunity for someone who was not a C expert, but who wanted to participate in it to make some really significant contributions in binding land. I know certainly Ruby bindings could use a lot of help. Do you mean in terms of things like iterators or? Yeah, anything. Ways of bridging the Libya 2 functionality is something that will feel natural in the language. Idiomatic. And you can't get somebody who knows C knowledge, but somebody whose passions maybe are in a language. I'm sure that the binding folks wouldn't mind something. Oh, a lot of bindings that we didn't see. Yeah. Yeah, it can't be not C, but yeah. But it is sort of a bridge in between. If it's someone who doesn't feel as comfortable, there's sort of plenty of ways where the language can live. Yeah. The creative work is on the side of the scripting. That's what you would hope, right? So the creative work is understanding what feels natural in that language and what is gonna be something that that community is comfortable with, which like, I can't tell you what Rubyists want in their binding, but someone can. Dude, I'm gonna put a native crawl binding on those. Oh, that is just a priority. I've got three of those coming. Uh, we've got the pirate, the unbinding one. The unbinding one. And we need someone to look after the amine people. Oh, yeah. I don't think she ever could. I think you sort of specifically pointed out an important point in this whole discussion. If we make up a formal requirement and then Lipki, too, has some other workflow where this formal requirement doesn't make sense, it will get very hard to enforce the formal requirement. For example, I would be all in favor of saying something like, if you fail to report an update in two weeks across the entire summer, the org admin as the chief household will fail your project, despite what the mentor might say about it. And... I think there'll be five more projects. Yeah. Yeah. It's not, it doesn't work for me. It's a different project. Although, I need to send, like, every month or so. I send, like, an update email. Yeah. It's reties. So the other thing is, yeah, let's see. Yeah, I mean, more often it doesn't make sense. So, out of all those projects, most of those are four-hit projects, but we've got, like, four Lipki's two projects, and it was the one E-hit project in 2008. I thought this was another J-hit project, but maybe it didn't show on mentor something last year. I don't know. I think there are more E-hit customers. Okay. Yeah, that's right. I think that all happens at the same time. Go back to the disclaimer also. Yeah. I mean, apart from the very first Lipki two thingy, which was hard to find information on, it seems that they were all stellar, right? So, statistically speaking, we should give the slots to Lipki two. Yeah. Well, so, I'm happy to keep Lipki two under the umbrella of GitCore. I've been happy with that. I mean, we usually give one slot, and it's been usually a good project. Obviously, Lipki two does, you know, I catch up and I like that the communities are talking, but it would also be fine for Lipki two to apply separately to Summer of Code. And I think there's even a form on the application that's like, is there some project that can vouch for you kind of thing? And if you just, if Lipki two wants to apply next year and say, yeah, I get can vouch for us, then they probably ask me, like, you know, why is Lipki two being separate? And we can explain to them. And I think they probably would give you a slot. Have you considered this year, but I didn't work out? Yeah, so, well, that may be a purchase because it would simplify, right? The parameters of what acceptable contribution. Right, exactly. Let's see if we have an organ man who handles everything. I mean, it's, I've been the organ man and you don't actually do very much, or maybe that's part of this problem that we got. But, mostly about reviewing proposals and then making sure everybody's good, the mentors know what they need to do, the students know what they need to do, if anybody has problems, they can come to you with administrative type things. And, but I, when there's just get to stuff, I just don't pay attention to it and I just assume that Lipki's two mentors are doing fine or whatever. So it would really be the same thing. It would just be more formalized under Google's way of looking at it. I mean, just out of curiosity, what do we get from December's code? Oh, it's like a drain on the, I mean, other than money, like what? Oh, I mean, would we be, so the question is, would we be better off like running our own? Right, I see. You know, internship program, that is your round type thing. Oh yeah, I mean, we could do that. And we can have more people over it. It's basically, we get the money, it's a well-known program, so it's advertised very well and people know it, haven't find it yet. And, but I guess, I mean, in the mentor summit, like that almost seems like that's almost the downside where it's like, you know, students are like, I want to make some money this summer or something or my, you know, professors told me that I should probably go do this and they just like go through all of the things rather than being specifically interested and get something. Yeah, we get a lot of applications that are clearly like that. So, I mean, that's another thing that might be, or even like a useful figure if we did like something through the, the SOFC, or the SOFC conservancy. Yeah. Well, also this, I'm going to review these here in the summer code, there was students who applied to a maximum of 20 organizations and this year it was five, which I think really helped. Okay, yeah, I haven't seen, because we didn't, because we're not at it this year, so I don't know if that's a good change. I would be slightly careful about the lawyer stuff. I mean, I'm not a lawyer and I'm not an American, but from all the regulations and all the FAQs in GSOC that relates to legal issues, check those out first before you just say, I'll run a program like this. I mean, it might be feasible but it's going to be exciting. Well, you're recruiting worldwide, right? Yeah. You're recruiting only in the U.S. and we're already knowable. That's what I'm going to say. If you stick to the U.S. people, maybe that works. Yeah, but I mean, we definitely would, with what's written here at least, because actually I was thinking that the opposite was not the opposite, but I was thinking it would be interesting to be able to have the program open to people in the Southern hemisphere because it's not in their office. Oh, it's true, yeah. And so there's basically half the world that you can't participate in people. Some are focused, it's not during the time that they're not at school. But, I mean, but for what has my ability? I've got a feeling is that it's a huge amount of paperwork. That's, but it's really only a little bit. Yeah, it's interesting, if you look at the paperwork at first you saw, you have a lot of compensation involved. So technically you're employing paperwork from across the world. So it's... I think it's going to be one more winter. It'll be awesome down there. Winter's coming. Is there a list of being kind of being gay or easy to have? Yeah, there are several. There was also the Colonel LaWard Wiki for a long time and then the kernel.org wiki was not available for a very long period of time, including the application period of last year. So I moved that stuff over to a wiki on GitHub, but now the kernel.org wiki is back and Thomas has a wiki that's like... Oh, you're just a little confused, right? Yeah. For practical reasons, there's no other thing. So yeah, I think, so yes, and I can point you at it, but it needs probably a more official spot, and I think that related to that is we probably need a more official wiki, or it doesn't have to be a wiki per se, but the kernel.org ones, I don't know, I don't go to it, maybe it's really well maintained, but it seems like it's not super well maintained, but maybe that might not be correct. At least there was an email on the list of spam on the... I don't know. Since we're talking topic. Yeah, I think he's going to spin that and then stop doing that, so I don't know what he's going to come. I don't know, I think the wiki thing could be a topic to discuss just for itself. Yeah, well, I'll put it on work for a time. Yeah, it's 20 plus. Okay. I don't know, I mean, where do people want to go since we have these amazing four ideas, yeah? No, no, I mean, not the talking, but continuing this GSOC topic. So should... I think we do want to participate next year, I think a lot of this, somebody needs to take the lead on writing out likes of guidelines and recommendations, and we need to work collaboratively on the project page. I don't know, so if you care enough to raise the idea? Okay, that's me, good. I'm just the orchid man, I don't know anything. No, I'm fine. I don't know if anyone else wants to be the orchid man that was here. The position is open, but no one's yet taking the upper. No, I'm fine, I mean, I can summarize and hush out something, and then you can flame me. That's good.