 Yes, I'm going to be talking about the streamline and boarding of New Contributors' goal. It was the third goal that got voted by our community, so we can work for how much it over the following years. I'm the one that actually proposed this goal as a newcomer, so I use that as an example, actually, of how I was already a newcomer and I was able to influence the community as someone starting new. So things can happen if you are like after them and have ways to contribute to the goal in the communities. Starting from the definition of onboarding. In simple words, it's about welcoming new people into your community and getting them to know and acquire the necessary skills, knowledge, and behaviors so they can become effective and productive members of your team, of your community, as soon as possible. In other words, we're talking about socialization in the context of an organization, a community, a smaller team, depending on your context. We're talking about integration with people, to other people. We're talking about building a relationship, getting to know the culture of the organization or the team, getting to know the team structure and of course how it gets them back down. What are the procedures involved into this team? Onboarding is essential for usually our organization to the largest ones until the smallest team everywhere. It maintains a healthy and vibrant community. In our, in the open source community context, it increases the buzz factor as it helps you attract new contributors. So probably higher the chances of someone being also maintained as your project and contributed to it. It helps us grow the project for similarly the same reasons and of course always attracting new blood, new people, bring with it different ideas, various perspectives and perhaps suggestions for different solutions that the ones we have been doing so far. So when we are great at onboarding, what we're actually doing is that we are making it exciting for newcomers. We create advocates out of people joining our community that then go on and share things about community and how great it is and how well they are, they are finding it. It increases the contributor retention as more people speak around and help and overload the long term. And for all these reasons, that's long-term value to our project. There are some obstacles here because as we all know, it is a very decentralized community which is very diverse, works mostly online and remotely. There are hundreds of contributors with dozens of different projects each doing their own thing in their little corner. So it's not easy to push like a goal throughout the community. So we need to do this together. There's nothing that I or some other person can do just by working on it. It can't happen like that. We all need to do it collaboratively and each one in each project that we are involved. Where do you find new contributors? Well, the reality is that they are usually the periphery of your team. We are talking here about any skillful or enthusiastic users you might have around. People spending the time to report bugs, maybe test your releases, share their ideas in your community, respond to other users in your forums or other channels that you have for communicating. So keep an eye for those people as those are the potential new contributors, the active ones, the people that actually care about your project and are committed to it. However, I would like to stress a bit your attention to people that are a bit more in the shadows, that might be a little bit shyer and don't have a voice of their own, but they might still be around. So try to look out for those people in your team and your community. They might have doubts about making their first steps, they might find the whole thing intimidating for them, but if you just usually step up and guide them into your project, usually you can make wonders. Ever since the goal was voted, there have been some progress so far. We have worked on the updating of our Getting Evolved page in the main KDE website which had to avoid any duplication, making it simpler and more direct to get you where you want to contribute, depending on your skills. Many projects, I was happy to see, that have started already working on distinguishing junior jobs, like tasks that are specifically maybe adopted to people that are new to their community. I know the KDE Connect developers, how blocked about it, also the Elisa developers and the Plasma Mobile team is doing some good work from that front. There have been improvements to the registered fabricator, which was a bit complicated, seemed to newcomers. And there was also a front-up on improvements to Paxila, which actually this was a goal by its own and there still needs work needs to be done on that. Some other ideas that came up in this process was about making a visit, set up a development environment so people can start working easy and quickly on KDE applications, frameworks, libraries or whatever they are interested in. There was an idea, I think it was by the Debian leader of the Debian project, that we should do more about attracting contributors and onboarding them from downstream distributions. Since we know KDE's softwares through the distributions, there might be people interested in those distributions that will be willing to help upstream. There is the idea of having like a first line of response through a welcome team. So we've seen it, especially lately, some emails coming out to the community of KDE and here I want to help, what can I do? And we're probably too late to respond or we're not very active in guiding people inside the community. And of course, it will be great if we can connect new people to all, to all and more experienced people around our community. So trying to find a person to mentor a new comer every time, it would be amazing. I want to talk a bit more about the Plasma Mobile team which was actually active on doing some things. They have set up a comprehensive guide on setting up a development environment so people can get involved and make it easier to find their way into Plasma. They have set up an interactive getting involved page. I think this is a work of the Mozilla work that helps you and guides you depending on your interests and your responses in a simple way to find your way into Plasma and your first contribution. And they have also been trying to do descriptive tasks which is when I talk about descriptive tasks are short and clear descriptions of the problem. Try to find and maybe include any possible solutions for the new comer coming in that will help him or help start working on it. Of course, if there are any requirements for this task to be completed, it would be great if we could include them in the descriptive task. And then it links to technical resources. What are the skills that this person needs? It is to know so they can start contributing. However, it's important to keep in mind that there's much more to onboarding than just attracting new contributors. We need to be prepared when these new contributors come and knock on our door. What do we do with them? How can we get them involved? So, attracting new contributors is great, but you don't want 10 people outside asking how can I get involved and have no answers for them. On this, it's very important to have in mind that not everyone coming and asking to contribute has the same skills, has the same background, has the same knowledge of your project and your team. The same time to get involved or the dedication and probably different things motivate them into contributing. So, what I would say this and what I would urge it to do when you see these people, try to find their superpower. This magic would happen when the thing they are good at actually has corresponds to something that you need, something that you lack in your community, in your project, in your team. So, try to do that. Try to feed that superpower. Try to feed them and guide them into making the most out of it, into your team. So, we are talking here about setting a path, making the way for newcomers to follow so they can be more involved in your project. So, if you are not at the moment doing anything else, I would advise you to at least pick two, three, four, three things out of this small list to do so you can help and improve your reporting procedure. We start always from documentation and here, the majority here is probably coders, but there's more to documentation than just documentation on the code. You should probably document your procedures. You'd probably document your team and your structure, who is working on what and how. So, someone coming in and reading about your project can easily find the person to talk to or to reach out to and all that. Try to set up guidelines for getting started and this includes like, how do I get access to your project? How do you, how do I communicate with you? Who should I talk to and all that? Spend the time to introduce newcomers, especially to other people in your procedures. It's usually people coming into your project will not know where to do something. How can they ask for information? Where can they find information and all that? So, I had to do that in the beginning, it's very important. And of course, I've talked about mentorship and its importance to link newcomers to more experienced contributors. So, be prepared, get to know your team, get to know your needs, get to have an idea of what your team is liking and where it can be improved, sorry, where it can improve and try to plan for the long term when we are talking about a new contributor. Don't just assign a task to them and then forget about them. It's very easy for them to drift off and forget about your project or concentrating on some others. We all know our attention span on the internet is not so big, so you have to have a plan for them. You have to have set the path for them to follow in the long term. Where do you think they can get involved after they make their best contribution? So, keep requesting things for them. So, be proactive, reach out to these candidates, find any tasks that they would be good at, depending on their skills, find tasks that correspond to their interests and of course, try to make yourself available to guide them through completing these tasks. I'm talking about mentorship again because I find it very, very important. Try to find people in your team or project that can actually adopt a newcomer, take them under their wings, especially in the beginning. Try to be a great host to them, show them around your project, what they can do while they are here and how they can do it, who they can talk to. And of course, as time goes by and they gain confidence and are more dependent, try to fade out their dependence on you so they can do their own thing with the rest of the team. I wanna talk a bit more about relationships and the newcomers and connecting to more experienced people. We have all been newcomers at some point, so we all know that it can be intimidating to join an already established group that already has relationships built up and connections and a way to communicate that probably makes you feel an outsider. So, do care for new people, try to introduce them into all that and this will increase their sense of belonging into your community and the higher that sense of belonging is into your team, into your community, the higher are their attention rates and people not dropping off. Finally, I would say try to be more strategic. Try to set some longer term goals in terms of onboarding. Find the objectives that will guide you and will take you there and try to find out the tactics on how to get there. So you need to take in mind what behaviors do you want your newcomers to perform in your project, in your team. What do you want them to do? Think of what emotions you want to evolve into them. Do you want to make them curious about your project? Do you want to make them maybe challenged by your project? Maybe you want to make them feel proud about contributing to your project. You can evoke different emotions that could still work and think then about what actions you need to do and your team needs to do in order to get that reaction from them. I have here an example. Let's say the goal is here to improve the onboarding of newcomers. You could choose the objective of keeping newcomers around after their first comment and a way to do that is to make newcomers feel confident and proud. So when they feel proud and confident, higher the chances of staying around. And a couple of tactics that you could use in this example are to praise and acknowledge their contributions. You could do that in public, in social network accounts. You are mailing lists. Include them in your credits of your application or project and all that. And another one is, as we mentioned earlier, to assign simple tasks to them. So by completing them successfully, they feel that they are confident it's better. So they will move on to other tasks as well and they won't be frightened off. So we're talking here about making people feel part of our team. So they need to feel that their feedback is welcome, that their opinion within our team and within our community is valued. And of course, that we have tasks to assign to them so they can contribute themselves. To quickly sum all this up, try to respond quickly to people offering for help and to join your project in any way. Try to spend some time to learn a bit more about them and their skills, experience, and anything they bring with them that could be useful to your project. Guide them, take them by hand into their first contributions. Pay some knowledge when this happens. Spend the time to introduce the procedures and cultures of your team and anything special that they need to know. Connect them to other contributors. Keep them over the long term motivated and challenged by maybe raising the difficulty of the tasks we assign to them so they can feel that they're doing more. And of course, in the long term, as again, more independent, try to turn them into mentors themselves. So in the future, they will be the ones that will be guiding newcomers into your team. People are always complaining about time and yes, this is true. And especially in open source projects, that is even more of an issue. But onboarding is not something that you work on today or tomorrow and you're done with it. And probably everything that adds true value to your project over the long term takes time. We're talking about good code or good documentation and all that, building relationships. So you need to take the time to spend it on onboarding, but this will only add higher value to your project in the long term as people come together, the relationship is stronger and the higher the chances of contributor turnover. I was surprised to see that there are many newcomers here. I might have talked a bit more about that if I knew, but yeah, my advice to them, as a newcomer myself and for my personal experience, try to be more persistent. Don't be disappointed by the first thing that goes wrong. Maybe you get a bad reaction or maybe you make a bad comment or whatever that is. Try to be persistent. Try it yourself to ask them more about the project and the team you are getting into. There are many things to learn about the project so to make it easier for you. Don't be shy, share your opinion with the rest of the team, but be prepared to accept any criticism because you might not know of something on how I think that. And of course, as soon as possible, try to make connections within your team. This will only help you in the long term and the team itself to make the most out of your collaboration. The advice that I was given when I first joined KDE and I was very shy about everything was to try and act already like I'm a member. I'm here, I'm trying to help. I have the motivation and the willingness to help. So if you're here and you're already offering, try to act like you're already a member of KDE and things will be fine. From my end, going forward, I would like to gather even more feedback from newcomers because we have some ideas and some idea about the things we can improve in our community in KDE, but we want to make sure that all of these ideas correspond to the actual issues that newcomers have when they are training our community. So I said, many newcomers here, do reach out to me if you find that there's something that we didn't mention or you have some idea about how to improve the process or you found a big problem maybe. Also, there are lots of experienced contributors that could help us on this front. You're probably leading a team or a project for a lot of time and you're probably already doing things in gatsom boarding that are working for you and your team. So do share that with me or with other people so we can exchange ideas and see how other projects in other KDE communities can benefit from it. It would be amazing to see even more KDE projects being active on this goal. Please try to discuss about onboarding in your project in your community. Try to bring it up, try to see where is the area of improvement, what have you been doing so far, what have you not been doing and have been lacking and you can do better based on the things I suggested or maybe you can come up with ideas on your own. And of course, we are here to help each other and exchange our identity. We are in the process of already organizing the first print for this goal. We chose a topic of making it quick and easy to set up a development environment. As we know, the KDE is a project about coding so we want to make it as soon as possible, mostly about coding. We want to make it easy and very simple for newcomers to get to play with the code, learn it and start contributing to the areas they would like. The idea is to hold this print sometime in August 2018 in Athens, Greece and then you find that you have the skills or interest or willingness to contribute. Do join us in this task. So we can arrange that and see what we can do. And I would like to bring your attention to a couple of other books happening here at Academy with it relating to this goal. On Monday, there is a Conan book that we discuss about how we can integrate Conan and the packaging process that they offer into the KDE development process. There is on Monday also the general KDE goals discussion and on Tuesday a specific discussion about the streamline on boarding goal and the sprint and all of that all included into that. That's it for me. Thank you very much. I'm not sure what the janitor is. We'll talk. Okay, perfect. We'll look into it. So I can see that your process for which one of these projects, right? The morning process depends on each team and how many they contribute. Have you thought about doing some things and all of that? I'd like to talk about how to get in the open, how to get it. That's how the whole idea started to do something centralized. But the more I looked into it, the more I realized that it's probably not gonna work into KDE because I've seen many teams doing their own thing throughout the KDE community. And so that's why the idea of forming a welcome team came up. Like having some people to respond first, people joining randomly. But the more I worked on the ideas, I realized that KDE is too decentralized probably to do something centralized. There is a getting more page and all that like to get you started, but there are too many projects running at the same time. And people usually already know the project they want to get involved. They like, say, K-Mail or I don't know, some other application. So they already reach out to those people. But yeah, any ideas about doing something on the decentralized are welcome if you have. Yeah. Oh, here you go. It's very difficult because many of us, you each want people to get a creation for the world, but we have not ready for creating a creation for the world. So is there some suggestion or some recommendation for beauty, for Asian, charming beauties? For Asian specifically? I'm suddenly a question very well. Yeah, what kind of suggestion for some Chinese? Yeah. What to do with Chinese people, let's say? Mostly they are, they are really having no confidence. Well, the concept for everyone, you know it's more or less on the lines that I mentioned already. So everyone joining a new community, a new project, especially on coding, they need to be aware of the language, the coding language for starters that we are using. So have good documentation of that, have good resources on what they need to read actually, what's their homework, so they can get started into your project. That's the first step. So have something to show them, but avoid the go read the manual approach that will not work with newcomers, especially Chinese people. So you need to have that, but also in addition to that, make yourself available so they can feel that they can ask about anything. Like there are no stupid questions. That's very important. I think today, like a year after, keep asking people that have connections with India about the simplest things. And I'm very happy that they respond to me about that and don't just point me to something else. So, yeah, and of course, reach out to them. If you are kind of identifying and already know who is shy, try to reach out to them, offer a helping hand, try to talk to them, see how they can help and all that. More or less what I discussed already, nothing more specific. So I guess that was all your questions for, we'll have a final comment from, but not from the judges. This is getting out from you, I would like to say thank you like us for working on this. Thanks. Thank you. Thanks, Mija. I appreciate it.