Streamlined onboarding of new contributors
Open, Needs TriagePublic


Merged with T6832 authored by @ngraham


Getting people involved is vital for the long term sustainability of a project and its continuous development and growth. Of equal importance is for new contributors to find an environment in which they can thrive and a community and project which they can be part of for a long time.
KDE is a big organization of hundreds of contributors working on dozens of projects. Even though documentation exists on the basics of getting involved, this is sometimes incomplete, outdated, or impersonal. It can be difficult and overwhelming for a newcomer to feel comfortable and confident enough to step up and get more involved without knowing the related context, balances, relationships etc.
The KDE Community can do more to facilitate this, by motivating and nurturing involvement. We can be more proactive and effective, both in attracting new contributors, as well as in making them feel welcome and valued in the community and the projects they show interest in working on.

What it will take

We will need to form a team that will try and understand the current status of the requirements and expectations for getting involved and gain a good overview of the processes in play. This team will have to hold or acquire good knowledge of KDE’s community and projects, as well as of how current contributors are intra- and inter-connected among them.
Holding discussions/interviews with current contributors is key here, both with people that recently joined as well as with individuals that have been around for a while , to gain a better insight and overview of the situation. Surveys could also prove useful.

Questions that we should be aiming at answering may include:

  • What are the possibilities for involvement (teams and projects, tools used, skills required)?
  • What are the available resources in terms of people and time that can be invested in this effort?
  • Are we making the most out of available potential of people interested in contributing?
  • Can some onboarding procedures be identified as essential?
  • Can we direct contributors towards areas that KDE could use more contributors in?
  • Are all the possibilities and pathways for getting involved properly documented and visible/reachable on the website?
  • To what extend are valuable resources spent on helping/training people that end up not joining the project or not making long term contributions?
  • What are the feelings of both new and older contributors in regards to the procedures of getting involved? What did they enjoy, what did they not like, what kept them around, what could we improve?

The next step is to propose a plan for attracting and integrating newcomers into the community. This will largely depend on the outcome of the research.

I assume that the forming of a dedicated team of contributors might be needed, which would be responsible for:

  • Welcoming and introducing newcomers to the community and procedures, by taking in mind their skills, interests and experience.
  • Actively supporting newcomers’ involvement until they are fully engaged with their projects and integrated with the community in both a micro and macro level.
  • Monitoring new contributors’ progress and satisfaction.
  • Identifying contributors within each KDE team that are willing to act as the first port of call and mentor newcomers. Provide these mentors with guidelines on getting people involved based on KDEs principles, values and workflows.
  • Holding events (could very well be online) targeted at newcomers where they can be informed, ask questions, participate in discussions, or even get a chance to get their hands dirty with some tasks.

Specific ideas:


  • Collapse the UNCONFIRMED and CONFIRMED statuses into a new status "NEW" to avoid user confusion ("Why isn't this confirmed after 7 years and 5 duplicate reports!?").
  • Mine other projects' Bugzillas for ideas regarding additional or replacement statuses we can add, particularly for closed tickets. Examples from other projects include NOTABUG, NOTOURBUG, NOTGNOME, ASDESIGNED, CANTFIX.
  • New Bugzilla tickets should have a default template explaining how to file a good bug, what kind of information is required, and mentioning that patches should be submitted to Phabricator and not attached to the bug.
  • Each project can override the standard template with a project-specific one that can list additional information needed, and even offer information about common bugs that don't need to be re-reported and workarounds for common issues.
  • Change the attachments page to notify users that patches should be submitted to Phabricator instead, along with a link to a how-to page
  • Bug screeners who identify reporters of above-average technical competence should encourage them to dig into the code and submit patches on Phabricator.


  • Make sure that the "how to contribute" pages on the top-level of are fully up-to-date
  • Closely document a "minimum viable product" approach to producing a user's first patch. We should aim for this process to be as painless as possible.
  • Improve documentation regarding how to check out and compile sources, how to set up a good repeatable dev environment, etc.
  • Document the process of becoming a KDE bug screener, along with helpful information
  • Improve documentation for how to translate strings

How we know we succeeded

Quantitative statistics and qualitative feedback can act as indicators.

An increase should be observed over time in the number of:

  • People showing initial interest
  • People ending up getting involved
  • New contributors that stay around for the long-term
  • Actionable bugzilla tickets
  • Phabricator patches from first-time submitters

New contributors and mentors should report higher levels of satisfaction with the related procedures and acknowledge a positive effect as a result of our efforts.
The sense of community should increase between the first days someone gets involved and after some time has passed.

What are the risks?

The obvious risk here is spending valuable resources of current contributors without any tangible outcome for the KDE community and its projects.
Yet, even if we fail to deliver changes, KDE will have gathered a lot of useful feedback about the current status of the community and its procedures.

Related Links

For Application Developers

At Akademy 2017, @ervin and @dfaure talked about making it easy for newcomers to build and test Applications. They discussed removing the need for make install and implementing solutions around and Detailed summary, video and slides can be found here:

For financial contributors

Consider the use of Patreon/Liberapay

I am willing to put work into this

Neofytos Kolokotronis (@neofytosk)
Nate Graham (@ngraham) - writing and deploying documentation and the new Bugzilla template and statuses
Ivana Isadora Devcic (@skadinna)
Vijay Krishnavanshi (@vijaykrishnavanshi)
Łukasz Sawicki (@Lucas)
Elvis Angelaccio (@elvisangelaccio) - writing/updating docs (Wiki/Apidox)
John Samuel (@jsamuel) - writing/updating docs (Wiki) and updating external sites like Wikidata

I am interested

Adrián Chaves (@adrianchavesfernandez)
Jeff Huang (@s8321414)
Gregor Mi (@gregormi)

neofytosk added a comment.EditedOct 2 2017, 12:43 PM

This related proposal was also made, but it is more specific to bugzilla and coders:
I guess the two could merge in the process of discussion.

lydia renamed this task from Streamline the onboarding of new contributors to Streamlined onboarding of new contributors.Oct 2 2017, 6:17 PM
s8321414 updated the task description. (Show Details)Oct 2 2017, 10:26 PM
gregormi updated the task description. (Show Details)Oct 3 2017, 9:35 AM
gregormi added a subscriber: gregormi.
skadinna updated the task description. (Show Details)Oct 3 2017, 11:53 AM
skadinna added a subscriber: skadinna.

Here are some further thoughts I've made on this:

For recruiting, aim at lowering the barrier for people

  • to express interest and contact us in some way
  • that are shy, have doubts or are not self-assured enough to take the step and get involved
  • that do not have preexisting contacts within KDE to reach out to us

For onboarding, aim at making newcomers feel

  • appreciated
  • confident
  • motivated
  • part of the team


  • Can we come up with reliable initial assessments of people’s intentions and long-term commitment?
  • The path for someone offering to help in legal issues, marketing or hardware is probably different than the one for a software developer or a documentation writer. Can we document the steps to getting involved for each and associate them to the skills required?

@skadinna @vijaykrishnavanshi I was glad to see you are willing to put work into this, perhaps you got something to add to improve this proposal?

In addtion to @neofytosk , I would like to propose some ideas that may be achieveable in the near future:

IMO many types of "onboarding" should exist, e.g.

  • community in general
  • onboarding for (yet to be) devs
  • onboarding for testing et cetera

Additionally, it would be great if there were how-tos for these types of onboarding e.g.

This may also apply to people interested in testing and include answering questions such as

  • "which software versions are released for testing purposes"
  • "how to write mature test cases / bug reports" et cetera.

Furthermore, what about including patreon as a way community contribution in the form of money? For instance, SolusOS does this quite successful, despite the fact that they are really small (c.f.

Sorry, if any of these questions are already documented and I just could not find them :)


I can close my similar proposal ( if folks are okay with me editing the description of this one to include the elements that I mention in mine.

ervin added a subscriber: ervin.Fri, Oct 20, 6:18 AM

Yes, it'd be nice to see them finally merging, we're late in the discussion phase now. Also as a bonus, it would be awesome if the consolidated proposal could contain aspects coming from the talk we held with David Faure this year about the developer story. That'd make for a very strong one then, and would probably add at least David's name in the list of people willing to put work into it. ;-)

In T7116#114498, @ervin wrote:

Yes, it'd be nice to see them finally merging, we're late in the discussion phase now. Also as a bonus, it would be awesome if the consolidated proposal could contain aspects coming from the talk we held with David Faure this year about the developer story. That'd make for a very strong one then, and would probably add at least David's name in the list of people willing to put work into it. ;-)

For those who weren't there: Slides and recording of the talk can be found here:

@colomar Thank you for the link! This is sounds like a plan! Communicating this information - when ready - should be done using the methods mentioned in #114484

+1 for Patreon/Liberapay page.

KDE looses contributors because of large gap between joining the community and making any actual contribution. To overcome this situation we can do two things

  • Reduce this gap by improving the documentation and resources ( this will take more time and more contributors and discussed already in better way )
  • Break down this gap in levels like making challenges with increasing skill requirements that can help new contributors to evolve and develop. It will eventually lead them to make contributions to projects and explore them in a better way after they are familiar with the infrastructure. This will also give goals to new contributors to achieve thus making their learning non monotonous which it currently is in most cases. Yes we will need team to handle it and more research.

Another place where we can focus our efforts is on encouraging other fields other than development to make contributions like by design sprints or awareness sprint. This is the point by which we can preserve the diversity of KDE or eventually get more contributors.

neofytosk updated the task description. (Show Details)Mon, Oct 23, 4:11 PM
neofytosk updated the task description. (Show Details)Mon, Oct 23, 11:05 PM

Lots of great suggestions here, I will try to add the ideas from the comments and the video asap. Of course, feel free to edit the initial post directly and include them yourself. =)

januz added a subscriber: januz.Tue, Oct 24, 1:18 AM

Some ideas from a n00b contributor:

  • Why not use phabricator for bugs? You can make custom forms to make sure users add the right info (link). Phab can be complicated, but it's a lot more user-friendly than bugzilla (at least IMO!)
  • Promote Kdevelop as "the standard KDE IDE" (or something like that). I know you might want to keep things open and not push for K apps, but it's very useful to have a reference IDE or application to get started. Kdev supports all languages and build systems used in KDE, and it can fetch projects just by clicking them from a list. I recently worked on a patch for Syntax Highlighting in Frameworks and kdev made it really easy. The _fetch project_ option downloaded the repo and setup the project for me, all I had to do is make my changes and click _Build_ to start testing.
  • Put things together in one place. Eh, I know it sounds vague :), but what I mean is that documentation, resources, links, etc. for a certain project should be grouped in at least one single place. For instance: you can find a mockup kit in the VDG forums, links to the telegram groups in the wiki, some more (outdated) info in, the current projects somewhat scattered here in phab and the HIG also in the wiki. Keeping up with the current projects, what to contribute, how to communicate is all kind of involved when information is spread like this.
  • Step by step, complete and up-to-date information on the technical parts of contributing. This could be organized like a book, with different chapters: "How to add translations", "How to contribute code", etc.
  • Some documentation on community customs. This can be a loose page, or a pinned forum post. I'm talking about things like who to tag when contributing a patch, where to ask for feedback, or little bits like how adding "BUG: ###" in a diff summary closes a bug in bugzilla.
  • Liven up the forums. There are lots of great ideas there but they often get no replies or a few "+1"s. I think Improving the usability of the forums and having discussions (for development and design) there would bring in a lot of contributors.

Sorry if this is too specific for this task!

gregormi added a comment.EditedFri, Oct 27, 4:51 PM

For me as an occasional code contributor, I notice that I find it especially tedious to get a proven local runtime environment ready for local testing of non-trivial programs. For example, this tutorial describes which environment variables should be set for this purpose. Quite a few and I am not sure if all entries are still valid. I guess every developer ends up with his/her own script or scripts to handle this issue (including having some convenience message on the bash prompt showing if the correct variables are set). Maybe this could be extracted to a maintained and standardized script that can be used anywhere where Qt/KF5 based-programs are developed. The script and a guide how one would use it in combination with Kdevelop (or automatic integration with the Launch > Environments) could facilitate getting started.

Lucas updated the task description. (Show Details)Fri, Oct 27, 7:16 PM
Lucas added a subscriber: Lucas.
neofytosk updated the task description. (Show Details)Sun, Oct 29, 9:53 PM
neofytosk added a subscriber: dfaure.

Hope it's OK if I slide in with some last-minute suggestions.

All the points raised so far are great and worth discussing. I'll highlight a few that I find particularly important.

To improve onboarding of new contributors, we need to:

  • provide centralized, up-to-date information on how to contribute. We already have the wiki, so there's no need to look for another platform. We just need to dedicate some time to collecting, updating, and organizing the resources.
  • put together a list of people that new contributors can contact when they need help. Basically, a list that defines "who is who", or rather, who does what in the community. This list should also include mentors/"Onboarding Officers".
  • be very straightforward and clear with what we expect from new contributors. If there are some unwritten rules or implicit expectations in the community, they need to be made explicit and known to new contributors. For example, if there's a person who needs to be notified of new pull requests, or if things need to be done in a certain order. Long-term contributors know these things and might take them for granted, but newcomers have no way of knowing this. They can inadvertently "do things wrong", which can cause resentment and create a rift between the "elders" and the "newbies".

More things we could do:

+ if there is enough interest and support, maybe we can organize live workshops and sprints in different countries where mentors can work more closely with one another and with new contributors. Fedora does a great job with Flock, which is something we could take inspiration from.

+ revive Junior Jobs, or start something similar. There's a page for this on the wiki, but it mostly seems dead. Every project that needs new contributors should have an easily accessible list of simple tasks for first-timers.

+ highlight the benefits of contributing to KDE. This is important as it can help attract those potential contributors who are still hesitant about investing their time because of that eternal question "what's in it for me?". This is connected with the next point, which is...

+ promote opportunities for new contributors. This is something that KDE Promo can help with, whether it's by writing stories on how to start contributing, or sharing the benefits and experiences of new contributors on social media.

+ create different contributor personas based on research/interviews to predict and build diverse and inclusive contributor paths. For example, Kim is a second-year UX/UI student who wants to help improve KDE's websites. Sena is a full-time Python developer who wants to help build educational software for children with disabilities.

We can then come up with a flowchart for each persona - where they should start, who they need to contact first, how to introduce themselves, which tools to use and how to set them up, etc. - and put those flowcharts into a guidebook for mentors. That way, the mentors will always have a consistent, standardized resource to rely on when helping new contributors.

In the end, the way I see it is that every new contributor should be able to:
1) easily and quickly find all the resources,
2) understand who to contact when they need help,
and 3) feel welcomed and supported by the community members.

We achieve 1) by updating and creating high-quality, reliable documentation, 2) by maintaining a list of people and their responsibilities, and 3) by assigning mentors and clearly stating our expectations and "rules" for new contributors, as well as the benefits of contributing to KDE.

ervin added a comment.Mon, Oct 30, 6:53 AM

I'll sound like a broken record but: if we don't solve the "how difficult it is to build something and patch it" *first* all the nice things mentioned here with mentoring etc. (which require people we don't have BTW) won't get us far. People will try, fail immediately because it's too hard and leave again.
Seen that enough with my students the past few years.

In T7116#116225, @ervin wrote:

I'll sound like a broken record but: if we don't solve the "how difficult it is to build something and patch it" *first* all the nice things mentioned here with mentoring etc. (which require people we don't have BTW) won't get us far. People will try, fail immediately because it's too hard and leave again.
Seen that enough with my students the past few years.

I was writing from the perspective of a non-coding contributor (we want to attract those too, right? They also matter.), as I don't have a lot of insight into the actual coding and development processes.
But I agree that the problem you mentioned is a huge one, and I understand it should have priority.

ervin added a comment.Tue, Oct 31, 6:58 AM

Ah my apologies, I thought the goal here was to capture the whole spectrum of contributors. Of course if the goal was to focus on non-coding contributors then this is fine.

Perhaps it should just be made clearer where the focus is or perhaps I should learn to read better if I missed the info (very likely it's about the latter). :-)

neofytosk added a comment.EditedTue, Oct 31, 12:17 PM

The ambitious goal here is to improve the onboarding process for all types of contributors. If we succeed, everyone interested in contributing to KDE should have a clear and supportive path to follow. Of course coders are at the heart of KDE and what it does and lots of this work will inevitably go into that. The way I see it, "making it easy to build something and patch it" should be the case/aim for all types of contributions. =)

Problems like attracting/maintaining new contributors might have many aspects

  • Lack of awareness/popularity?
  • Complicated procedures involved?
  • Inefficient treatment/mentoring of people?
  • Failure to make the most of the available resources?

Depending on the problem identified for each path (developers, documentation, translation, marketing etc), we can then work towards a solution.

neofytosk updated the task description. (Show Details)Tue, Oct 31, 12:20 PM
neofytosk updated the task description. (Show Details)
ngraham updated the task description. (Show Details)Fri, Nov 3, 1:07 AM
elvisangelaccio added a subscriber: elvisangelaccio.
jsamuel updated the task description. (Show Details)Mon, Nov 6, 6:50 PM

Thanks everyone for helping draft this proposal. The voting has started. If you are an active KDE contributor and have not received an invitation to the vote please send me an email to