 Hello everyone, my name is Martin Coppets, and I'm gonna present here with my colleague Lukasz Piwarski The topic about onboarding not only new contributors and our focus of work Okay, our focus of work is mainly upstream we work with tempest and interoperability related projects and However in downstream internally at Red Hat we help other colleagues to contribute upstream And that's what is inspired us for this presentation so the presentation will have just three main topics the first one is gonna be about the decreasing trend we noticed in the open-stack community the second part will be about a Pool of tasks and we will explain how it relates to all of this and the last part will be basically about What should we do as a community? Yeah, so before we move to the main part of the presentation We would like to start with a couple of graphs which showcase the trend in active contributors in open-stack over the last eight release cycles All the data you'll see here are taken either from the Stake Analytics or the official open-stack website So for example here in this first graph you can see That the number of active contributors is steadily decreasing For example, if you take a look at the train release cycle You can see that the number of active contributors is almost double to the number in the Antelope release cycle The number of produced lines of code with each release cycle is slowly decreasing as well so as a community we Probably produce less and less code with each release cycle and and Logically with that the number of commits and feature requests is going down also the number of reviews needed for those changes is going down down both by the Regular users, but also by the core reviewers Here's an interesting graph which shows the number of filled and the result bugs per each release cycle You can see that both values are going down which is good news especially for the number of filled bugs, but Also the number of resolved bugs which alone might seem as a bad thing But definitely it is not the case because if you take a look at the Delta between those values It is decreasing as well, which means that we as a community Are able to handle the number the filled bugs in a better way Yeah, this light one possible interpretation is that The open stack is becoming more major and solid Okay, so now we saw a couple of key metrics going down, which probably might signal a bad thing is happening This is definitely not the case here, right as we saw the number of Resolved and filled bugs is going down, which means more stable code also the number of You know produced lines of code is going down which might signal that we are getting from open stack what we need and we do not need to write like new features and modified that much as we used to and For the maintenance of the code we probably need fewer contributors that makes sense, right so This is not that important what is important here for the following part of the presentation is that the pool of Contributors is smaller if you want to find a new contributor for your project You can either take it from other project Then the person will miss there or you can try to invest a tiny bit energy in finding new ones and Potentially if you invest this tiny bit of energy it might have a high returns. So now Martin Yeah, so the best thing is becoming more and more mature and As Luke I mentioned there is less and less active contributors around but what can we do about that? Let's on board not only new contributors like there are many people who work with Open stack and They are not primarily focused on upstream. So maybe we can focus on those Let's just use their time more efficiently and I will explain in a bit why Internally, we did a small research and we asked our colleagues on the engineering level Who work with open stack whether they would like to contribute upstream and like every one of those said yes, of course Although when we asked them whether they contribute upstream more or less regularly Almost 37 people said no What's interesting about this is that 71% of those people who said no Would find a pool of tasks easier In order to start contributing upstream and I will explain why But before that, can you think of any obstacles that might? Prevent people from contributing upstream. We asked those 36 people why they said no and we found three Common obstacles the first one was people don't have enough time. They are too busy with their Work, which isn't that much upstream focused They the other obstacle was that they don't know where to start and the third one They just can't find any task which would be relevant for them Therefore we did another experiment and we created a pool of easier tasks and under that imaging tasks, which are Suitable as them as good first-time issue for example something which isn't very complex something Anyone can work on regardless of their knowledge of that particular project We found that these four rules are very essential in in order to maintain The pool of tasks the first one is that every task in that pool has to be very well documented Otherwise people will just not be interested because they don't have enough time Steps to reproduce are a must another thing is definition of done every task has to have a set of Conditions which if I met the work on that task is done anything else is problem for another day another contributor or and another task The third thing is a mentor Every task should have a point of contact someone who gets notified when there is a question or when there is a page which should be reviewed and the very Important last thing or last rule is that the response time for both mentors and assignees It's to be really quick because if you remember on the previous slide one of the obstacles was that people don't have time so if a Mentor is asked the question. They should really try to address it ASAP on the other hand when an assignee is given a feedback or is given a Review on their page. They should address it as ASAP as well because we don't want to waste mentors time too Therefore we did another experiment. We built basically on this pool of tasks and we created a program called bootcamp Everyone who's interested in upstream contributions can participate we Hosted a few sessions where we explained the theory about how upstream works how to contribute there and and so on so forth And then we asked every participant to pick a task from the pool and finish it One important thing to mention is that the participants were originally from two groups one of the group was Where people who contribute upstream or less regularly? But they wanted to try a contribution to a different project the other group was people who Don't contribute regularly to upstream, but they wanted to try that After a while as we did this bootcamp thing a couple of months ago and after a while We asked them a simple question do feel like you participate more in upstream in any way like reviews or pages or so And what's interesting is that 27 people said yes, so those are the people we should be seeing in upstream sooner or later The yellow group they said I Contribute approximately the same as I contributed before the bootcamp. It's like 36% of people But what's important about this is that those people Were given a chance to contribute to a different project were given an opportunity to escape from their regular Stereotype and try something new learn something new and they finished a task. So the community Benefited from that as well as as they did the red group the last 36.4% of people they said no I don't contribute more Which means that okay? We didn't change their habit to contribute upstream regularly But what's important is that they were able to finish at least one task from the pool Which means that the community benefited At the end plus if you remember the obstacles Two of those three obstacles were about I don't know Where to start and I don't know how to find a task suitable for me And we basically Did solve this for them so in future if they feel like they want to contribute to upstream again They know how to do that. So I think it's a win as well Yeah, so here's a feedback from the participants of the bootcamp some few nice words So here you can see that if anything the participants Like get out of this experience the knowledge of how upstream operates They got to know some people so they have some contact point if they ever will need to contribute in upstream themselves They will need to implement their own change. They know someone they can contact and someone who will help them So yeah, they basically basically know where to begin and this might help them to decrease the friction in the future So now important slide what do we want to do as a community with this? What do we want to take away out of it? marking outline outlined here some framework which might be tailored a bit for upstream and you can try to also Something similar in downstream So we believe that in upstream it would be really helpful if we as a community Tried to use the low-hanging fruit tag more often I believe that you are all aware of the fact that launchpad Offers that option that you can have a low-hanging fruit tag for tasks And it would it would be really helpful if we started to use that together with the rules So it would be nice if each such a task would have clear definition of done so that Contributors are not frustrated when working on such a task and also a mentor or point of contact who will help the contributors when they are working on the low-hanging fruit task Now to the downstream part basically it would be helpful if you mimicked in some way The thing marketing mentioned here you can start your own version bootcamp which would involve for example some Presentation at the beginning of the bootcamp in which you would explain how upstream operates and then you can create some Pool of easier tasks for example if you work in Jira You can create a dashboard with tasks which are linked to the launchpad And yeah, and then you can help the participants to implement their first upstream patch and We can profit as a community as a whole We believe that for people in downstream this might also help them to prevent Burnout for example as some people might be stuck in the some repetitive work and This might be nice to escape and Yeah, pretty helpful Okay, so that's enough So this is all from us if you have any questions you can find us over there at the redhead booth We will be more than happy to chat about this presentation or about anything else So see you there Well, we have almost two minutes Yeah, so this is all from the presentation if you should leave with one thing from this presentation That's this QR code Please feel free to scan it. It will redirect you to a page where we summarized all the facts we covered here today Plus there is some additional content. We were unable to fit into this presentation Yeah, last thing I want to say is that Please decrease the friction it will definitely help to anyone And yeah, that's it. Thank you. Any questions? We have 60 seconds. So yeah, we're still open for one question Okay, so the question was whether it matters if the low-hanging fruit tasks are just bug fixes or feature requests I'm not sure if we had any feature requests there, but I don't think it matters if the task is Simple to follow if it's not too complex and if it doesn't require a huge deep dive into the project I think it would work It's just about the friction if it's easy to follow with anyone who reads the task understands what is what it is about That's a win. Thank you. We are out of time