 I will bore you the next 20 minutes. Originally I planned for 40 minutes, but Italo decided that mentoring is only worth 20 minutes. So I cut all the funny slides and came down to the bottom of it. Two weeks ago when I prepared the final things for these slides, when I rewrapped it actually, I was told we need to see numbers. Mentoring is not at all about numbers, it's about people, it's about connections, but numbers is important. So I've prepared a little slide. What have I done last year? What is it that I have sort of brought into the foundation? Well, I've done 50 reviews every week in average, done eight commits on behalf of the contributors, not my work, but I've looked at the patches. You can look at all the numbers there, not very interesting. There's one number that is very important for me. 20% of our commits at the moment comes from non-committals, basically new people on their way into the system. That is a very good figure. The figure for open source in general is less than 10%. So we shouldn't complain in that respect. Now let's have some more interesting numbers. I've prepared a slide, I've been with the foundation for a year. So I tried to make some numbers and see how was life before we had mentoring as an official task and what is my goal for the next year. First of all, yeah, we have a number of developers who leave us for many reasons. I'll come back to that. But before September last year, we basically said, well, that's fine, you left us. We don't really care. But look at it like this. A developer that leaves us is the double the cost of a new one coming in, because a developer that leaves us has experience, whereas a new one we have to build up. So we need to catch those people. And at the moment, I mail approximately four old developers every week. It's again, it's an average number, I mail them actually every quarter. I want to bring that down to three. Not ambitious, but I want to do it. Then we have new people coming in. We have at the moment about three people every week sending their license statement. There are people coming in from other channels as well. But I take them serious once they send their license statement. That is for me, yes, we want to do this and not only talk. And three every week is, in my opinion, not a bad number. We can do a little bit better. Now comes my big problem, merge delays. What happens? My contributor sends in his first patch. He's like his tuna exam. He is excited. He wants to see, am I successful or did I fall true? Last year, it took six to ten days, in average, for a response to appear. Now we have a response within 24 hours where we say we have assigned a reviewer. But reviews still take, in average, three days. Many contributors are gone three days. After three days, no response. As a little joke, I had one contributor who sent in a patch. Two hours later, sent me an email. What is happening? I haven't heard anything. Okay, we won't come down to two hours. But we might come down in the range of three to four days, in average. Contributor prosent was 18, gone up to 20. Not necessarily due to my work. It can be just fluctuations. And I'll keep it at 20 next year and I'm happy about it. And I'll explain in two seconds why. Hackfest is also one of those where we haven't been so successful in the last year, in my opinion. Response to emails. Yeah, I saw when I went back and looked at the dev list for last year, it's typically more than a week to get a response. We are being very good as a community. We are below a week, one to five days at the moment. We should lower it a little bit. University projects, one of the most elegant ways of getting new people in. This year we had 86 applicants who wanted to join our project. We only got 12 slots, so we had to select quite hard. But it tells that there are students out there who wants to do it. My game is to come up and not only do Google some of code, but also do the capstone project. And maybe also a Spanish project, which I'm not sure it's an academic project that might come this year, might come next year. Another thing is feedback on patches. Well, if we can't review the patches, we can at least tell the contributors about was their patch good, was their patch bad, could it be done differently? We do that with a delay of one to two, no, we do that for one to two patches. I want to set it up to three to four patches. How am I going to do this? I'm not, I'm asking the community to help me. I'm just a mediator who have some ideas and then I can have all of you help me make the community even bigger than it is. One of the things I want to do is to catch inactivity earlier. At the moment we monitor if a person have not committed for three months, then we send him an eysmail. We miss you, what's happening? And a lot of them react very positively to that. So I want to set that down to one month because now I've had the catch up. So now it's more regular, so doing it one month will not be a lot of work. Then people who contribute more than three to four patches should have a direct feedback, I'll come back to that in another slide. This is actually my key point. This is our biggest problem seen from mentoring. We are too slow in reviewing. And I know it's, I regularly ask all the core developers, please help me review, but I know it's a boring job. But this is a place where we really need to do something. So to all of you who are developers at least, please help review a buck from time to time. Even if you're not committed but still can try to build it, see if it makes sense, it helps a lot. My biggest problem is not, I told you before we are about five days in average, but the distribution is very, very large. Some box or some patches are dealt with within one day, super. Some of them take two months, and that is not good. I'm planning on in the C meeting to come with a top five reviewer list. So everybody who does reviews get measured and the ones who really do it, we will mention them as an idea. HackFests is the next little thing I've attended. I think four HackFests last year, three or four HackFests. And I wasn't impressed. The HackFest was good. The people who were there, the core developers or whoever came in, we're a fabulous organization, but we need to do more in pre-work. We need to, for instance, if we do it in a university, we need to heat the university before, use the billboards, get the students attention, not the day we do it, two weeks before, three weeks before. And this is a very good, big point of mind. Once the HackFest is there, we need more formally to make blocks, to make photos, and sort of say, hey, this is the group we were there. Why weren't you there? Get the word out is also, I search for HackFest. I invite you to do the same. Librov is not on the first page. It's not on the second page. It was on the third page. We should have it up on the first page. If you search on easy hacks, we're on the first page. And then this is a very important point in general for mentoring. We ask people to come and contribute to us, to give us their time, because we have a fabulous community, we have a very good product. What do we give them? In a moment, participating in Librov is the biggest public secret I know of. I want to be able to, whoever participates in a HackFest gets a certificate. I've just been administrating Google Summer of Code, it's actually was a job. I got a certificate from the vice director, wow. I don't need that certificate, but students do. A lot of the young people who are about to go out and get their first job, they need something and we can give it to them. Because we are one of the biggest projects. We are not the most known project, but we are very well known out there. So if they apply for, for instance, in the bigger companies, I happen to know Siemens quite well. Siemens check if their applicants have done open source work. And if they can say, yes, I have been working on Librov's complicated code. It's a big plus when they search for people. This is interesting. Yes, I think I found an in, but good thing is, I know what's on the last two slides. I'm not borrowing you that much. Slides will be uploaded afterwards. I don't know what happened there. Let me just be sure I have it here. Yes, I told you we have 20% of commits coming from contributors. And my intention next year is to keep it on 20%. I'm pretty sure the board was going to tell you, that's not ambitious. You need to do 25%. But my problem is, if I have contributors who really contribute, they become committers and that lowers the percentage. So I'm quite happy with 20% flow true. A lot of them only contribute one or two patches. I really don't waste too much time on them. We have a lot coming in. They solve what I call a certain replace hack and see, oh, it's complicated and walk away. When people come to their third or fourth patch, that's when they become interesting. They need a fast success, as I've said before. They need direct feedback on their patches, the quality of their code, a hint you could do this better, or have you looked at this patch? This is very similar to what you have already done. Then they need mentoring, mentoring saying, thanks for the patch. But not only thanks for the patch, take a look at this one. You have done this one, so this one is easy for you. People are lazy, they don't go searching for work. But if we tell them this is something you can do, they feel proud. Then I need to next year do some guides, and Mike has shown me how I can do videos, so my intention is to do a series of videos on how to use open grog, for instance. It's amazing how many people who doesn't know how to use that, and it's one of our best tools, actually. I asked a broad set of contributors, about 100, and the reply I got back was, it is a good community, very welcoming. But the code is far too difficult to understand. And I've heard this last sentence I've heard from nearly everybody, and I happen to agree with it. But that's where we can come in with guides. Last thing I'll tell you about is something for something, because I know it's not policy. I feel this is the best community of open source I've been in, and I have 59 years Sunday, so I've been in a couple of communities. This is far the best and far the most welcoming. But again, we don't give anything back. Busy students have many choices, why should they choose us? My idea is to send them a thank you after their first patch, as I told you, this was your first patch, could you have a look at, and then tell them about a reward scheme. What I'm about to tell you now is my idea, and it has not said yes or no to it. I want to, after 10 patches, give them an official PDF document signed by the foundation saying thank you for your valuable participation in LibreOffice, and by the way, a short note about how great LibreOffice is, so we get a little bit of marketing. They can use that for their CVs, but they can also use it to share it to their friends, so we can get the word spread by using mouth, the mouth-to-mouth or mouth-to-ear function. I already said it with a hack fest that for the hack fest, we should simply do it automatically. You participate in an event, here's a certificate that you participated. It doesn't cost us anything. The problem with these certificates is when I suggested it, I was told yes, why don't go ahead and do it, but you cannot sign it. What's a piece of paper if you get a certificate? I participated or your name participated in blah blah blah, but it's unsigned, it's worthless. So we need to make these papers signed, and that seems to be a challenge. That is the short version of mentoring. The long version will hopefully come in the year to come. My ideas at the moment is I use the first year to get things stabilized, to reduce the Garry backlogs, to reduce the Buxilla backlogs. That's more or less done now, so 2017 will be the year where I, seen from my dog perspective, do outreach with the help of the community. So you can expect quite a number of mails from me, more than usual, but with questions. I need to reach out to the local communities. We have too few developers from local communities. And that's something we need to do something about, because local communities know about local problems, and they are the best to solve it. I'm so happy that we have Cisco aboard now, also being Spanish. I'm Danish, but live in Spain. So we will do a lot to make Spanish hackfest and make Spanish meetings during the next year, again with the help of the community. So my last word before I ask for questions is, thank you for allowing me to help this community to be even better than it is.