|
|
Subscribe / Log in / New account

KDE's onboarding initiative, one year later

August 24, 2018

This article was contributed by Marta RybczyƄska


Akademy

In 2017, the KDE community decided on three goals to concentrate on for the next few years. One of them was streamlining the onboarding of new contributors (the others were improving usability and privacy). During Akademy, the yearly KDE conference that was held in Vienna in August, Neofytos Kolokotronis shared the status of the onboarding goal, the work done during the last year, and further plans. While it is a complicated process in a project as big and diverse as KDE, numerous improvements have been already made.

Two of the three KDE community goals were proposed by relative newcomers. Kolokotronis was one of those, having joined the KDE Promo team not long before proposing the focus on onboarding. He had previously been involved with Chakra Linux, a distribution based on KDE software. The fact that new members of the community proposed strategic goals was also noted in the Sunday keynote by Claudia Garad.

Proper onboarding adds excitement to the contribution process and increases retention, he explained. When we look at the definition of onboarding, it is a process in which the new contributors acquire knowledge, skills, and behaviors so that they can contribute effectively. Kolokotronis proposed to see it also as socialization: integration into the project's relationships, culture, structure, and procedures.

The gains from proper onboarding are many. The project can grow by attracting new blood with new perspectives and solutions. The community maintains its health and stays vibrant. Another important advantage of efficient onboarding is that replacing current contributors becomes easier when they change interests, jobs, or leave the project for whatever reason. Finally, successful onboarding adds new advocates to the project.

Achievements so far and future plans

The team started with ideas for a centralized onboarding process for the whole of KDE. They found out quickly that this would not work because KDE is "very decentralized", so it is hard to provide tools and procedures that are going to work for the whole project. According to Kolokotronis, other characteristics of KDE that impact onboarding are high diversity, remote and online teams, and hundreds of contributors in dozens of projects and teams. In addition, new contributors already know in which area they want to take part and they prefer specific information that will be directly useful for them.

So the team changed its approach; several changes have since been proposed and implemented. The Get Involved page, which is expected to be one of the resources new contributors read first, has been rewritten. For the Junior Jobs page, the team is [Neofytos
Kolokotronis] discussing what the generic content for KDE as a whole should be. The team simplified Phabricator registration, which resulted in documenting the process better. Another part of the work includes the KDE Bugzilla; it includes, for example initiatives to limit the number of states of a ticket or remove obsolete products.

The Plasma Mobile team is heavily involved in the onboarding goal. The Plasma Mobile developers have simplified their development environment setup and created an interactive "Get Involved" page. In addition, the Plasma team changed the way task descriptions are written; they now contain more detail, so that it is easier to get involved. The basic description should be short and clear, and it should include details of the problem and possible solutions. The developers try to share the list of skills necessary to fulfill the tasks and include clear links to the technical resources needed.

Kolokotronis and team also identified a new potential source of contributors for KDE: distributions using KDE. They have the advantage of already knowing and using the software. The next idea the team is working on is to make sure that setting up a development environment is easy. The team plans to work on this during a dedicated sprint this autumn.

Searching for new contributors

Kolokotronis plans to search for new contributors at the periphery of the project, among the "skilled enthusiasts": loyal users who actually care about the project. They "can make wonders", he said. Those individuals may be also less confident or shy, have troubles making the first step, and need guidance. The project leaders should take that into account.

In addition, newcomers are all different. Kolokotronis provided a long list of how contributors differ, including skills and knowledge, motives and interests, and time and dedication. His advice is to "try to find their superpower", the skills they have that are missing in the team. Those "superpowers" can then be used for the benefit of the project.

If a project does nothing else, he said, it can start with its documentation. However, this does not only mean code documentation. Writing down the procedures or information about the internal work of the project, like who is working on what, is an important part of a project's documentation and helps newcomers. There should be also guidelines on how to start, especially setting up the development environment.

The first thing the project leaders should do, according to Kolokotronis, is to spend time on introducing newcomers to the project. Ideally every new contributor should be assigned mentors — more experienced members who can help them when needed. The mentors and project leaders should find tasks that are interesting for each person. Answering an audience question on suggestions for shy new contributors, he recommended even more mentoring. It is also very helpful to make sure that newcomers have enough to read, but "avoid RTFM", he highlighted. It is also easy for a new contributor "to fly away", he said. The solution is to keep requesting things and be proactive.

What the project can do?

Kolokotronis suggested a number of actions for a project when it wants to improve its onboarding. The first step is preparation: the project leaders should know the team's and the project's needs. Long-term planning is important, too. It is not enough to wait for contributors to come — the project should be proactive, which means reaching out to candidates, suggesting appropriate tasks and, finally, making people available for the newcomers if they need help.

This leads to next step: to be a mentor. Kolokotronis suggests being a "great host", but also trying to phase out the dependency on the mentor rapidly. "We have been all newcomers", he said. It can be intimidating to join an existing group. Onboarding creates a sense of belonging which, in turn, increases retention.

The last step proposed was to be strategic. This includes thinking about the emotions you want newcomers to feel. Kolokotronis explained the strategic part with an example. The overall goal is (surprise!) improve onboarding of new contributors. An intermediate objective might be to keep the newcomers after they have made their first commit. If your strategy is to keep them confident and proud, you can use different tactics like praise and acknowledgment of the work in public. Another useful tactic may be assigning simple tasks, according to the skill of the contributor.

To summarize, the most important thing, according to Kolokotronis, is to respond quickly and spend time with new contributors. This time should be used to explain procedures, and to introduce the people and culture. It is also essential to guide first contributions and praise contributor's skill and effort. Increase the difficulty of tasks over time to keep contributors motivated and challenged. And finally, he said, "turn them into mentors".

Kolokotronis acknowledges that onboarding "takes time" and "everyone complains" about it. However, he is convinced that it is beneficial in the long term and that it decreases developer turnover.

Advice to newcomers

Kolokotronis concluded with some suggestions for newcomers to a project. They should try to be persistent and to not get discouraged when something goes wrong. Building connections from the very beginning is helpful. He suggests asking questions as if you were already a member "and things will be fine". However, accept criticism if it happens.

One of the next actions of the onboarding team will be to collect feedback from newcomers and experienced contributors to see if they agree on the ideas and processes introduced so far.


Index entries for this article
GuestArticlesRybczynska, Marta
ConferenceAkademy/2018


to post comments


Copyright © 2018, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds