Jump to content

MentorshipPrograms/2026

From KDE Community Wiki

Programs

  • Season of KDE
  • KUWoC is a one month program between mid-January and mid-February in collaboration with the KU Open Source Community (KUOSC) at Kathmandu University.

Note

For organizational reasons, GSoC projects must be written in this specific page.


Projects

All ideas for year 2026
Idea SoK KUWoC
#XMPP_support_in_Falkon_through_WebXDC Yes Yes
#Improve_docs-kde-org_maintenance Yes Yes
#Task_1:_Follow_human_interface_guidelines Yes Yes
#Task_2:_Fix_the_glossary Yes Yes
#Task_3:_Jump_to_next_translation_unit_when_sort_filters_are_applied Yes Yes
#Task_4:_Redesign_translation_memory_tab Yes Yes
#Task_5:_Improved_state_saving_across_all_tabs Yes Yes
#Task_6:_Standardise_menubar Yes Yes
#Task_7:_Modernise_PO_file_read_/_write Yes Yes
#mentorship.kde.org Yes Yes
#Plasma_Setup Yes Yes
#Task_1:_Standardise_translation_reference_paths_across_all_KDE_projects Yes Yes
#Automate Promo Data Collection Yes Yes
#Automate website updating Yes Yes

Template project

Your Own Idea: Something that you're totally excited about

Project Type: Coding / Web Development / Promo / Translation

Brief Explanation: Do you have an awesome idea you want to work on with KDE but it isn't among the ideas below? That's cool. We love that! But please do us a favor: Get in touch with a mentor early on and make sure your project is realistic and within the scope of KDE. That will spare you and us a lot of frustration.

Expected Results: Something you and KDE love

Knowledge Prerequisite: Probably C++ and Qt, but it depends on your project

Mentor: Try to see who in KDE is interested in what you want to work on and approach them. If you are unsure you can always ask in #kde-soc on Matrix.

When adding an idea to this section, please try to include the following data:

  • if the application is not widely known, a description of what it does and where its code lives
  • a brief explanation
  • the expected results
  • pre-requisites for working on your project
  • if applicable, links to more information or discussions
  • mailing list or Matrix/IRC channel for your application/library/module
  • your name and email address/Matrix handle for contact (if you're willing to be a mentor)
  • if you are not a developer but have a good idea for a proposal, get in contact with relevant developers first.


Do not add SoK ideas with no mentor and no contact info.

XMPP support in Falkon through WebXDC

Project Type: Coding

Brief Explanation: WebXDC enables running apps in a browser. XMPP (the extensible messaging and presence protocol) can be used to create lightweight and performant chat applications. The aim of the project is to create a basic prototype XMPP chat web client. An alternative but related project is a bookmark sync extension

Expected Results: A prototype Falkon extension implementation that allows one to connect to XMPP chats in the browser.

Knowledge Prerequisite: Python and javascript are the main pre-requisite, C++ and Qt would be nice, but not must haves.

Mentor: Schimon Zackary, Benson Muite

Warm up task: Fix a Falkon bug or build a small demo app with PyFalkoon

Contact: Please get in touch on the Falkon mailing list

docs.kde.org website

Improve docs-kde-org maintenance

Your Own Idea: Extract dblatex-cvs-install from docs-kde-org Project type: Coding

Brief explanation: we are currently reworking the documentation website in https://invent.kde.org/websites/docs-kde-org/-/issues/2. The first task was to generate the documentation of each repo in a specific job (https://invent.kde.org/sysadmin/ci-utilities/-/blob/master/gitlab-templates/documentation.yml?ref_type=heads). Then, a new job will fetch all the generated documents and generate again the website. For now, we are using an old fork of dblatex-cvs-install (https://dblatex.sourceforge.net/) which has been copied pasted in https://invent.kde.org/websites/docs-kde-org/-/tree/master/dblatex-cvs-install?ref_type=heads. There are multiple potential tasks to do in this project:

  • extract the dblatex from the code in its own repo (keeping the history)
  • find if we can directly clone the original repository instead of having a fork.
  • check if we can use a more recent version of the original project while keeping all the changes we did in KDE meanwhile
  • upstream generic info if it makes sense

Expected results: Easier maintenance, better knowledge on this repo

Knowledge Prerequisite: git (some latex, python, bash knowledge may help). Not a specific knowledge but there will be a lot of investigation, so proactivity and willing to dig is important.

Mentor: Johnny Jazeix. If you are unsure you can always ask in #kde-soc on Freenode IRC, I don't think there is a specific channel for this topic.

Lokalize (NO LONGER ACCEPTING APPLICATIONS)

Lokalize is KDE's translation system, enabling the translation of KDE programs as well as other external projects. All Lokalize tasks are mentored by Finley Watson (@fin-w:private.coffee , ask on https://matrix.to/#/#kde-mentorship:kde.org and I'll respond). If you want to do something different to the below, take a look at Lokalize bugs or speak to me and we can sort something out. All "prerequisites" describe knowledge that you will use to complete the task. They are not essential, if you lack the knowledge, you'll develop it as you work on the task.

If you want to work on a particular task you need to complete a proposal in this repository using this template and then wait for a decision towards the end of January.

You're welcome to contact me before writing a proposal, I want to help.

WARNING: I will reject all applications written by LLMs. If you can't be bothered to write it, I can't be bothered to read it. The purpose of contributing to KDE is for you to grow and learn.

Once you are accepted, I will open an issue to track your planning and progress in Lokalize's repository, and you will later open a merge request with your changes to merge your code into the main branch of Lokalize. During your time contributing, you will join a Matrix group with your peers (other mentees working on Lokalize) and will be expected to review each others' code. You will also get a status reports page similar to last year's.

Task 1: Follow human interface guidelines (NO LONGER ACCEPTING APPLICATIONS)

Predicted Task Character: Medium time, easy difficulty.

Proofread and update UI text to ensure it follows KDE's human interface guidelines for text. The HIG standardises how text in buttons / labels etc should look, but Lokalize was never updated to follow this. A start was made but the rest of the text needs reading through. The PO (translation) files should contain all the text, but to understand it in context you will have to cross-reference by running the Lokalize program itself to understand where the text appears.

Expected Result: Lokalize UI follows the HIG.

Knowledge Prerequisites: A good enough fluency in English to complete the task. Ability to navigate the codebase and familiarity with e.g. `grep` tools, and Git / Gitlab to commit the changes, or at least willingness to learn.

Related Merge Requests: https://invent.kde.org/sdk/lokalize/-/merge_requests/259

Task 2: Fix the glossary (NO LONGER ACCEPTING APPLICATIONS)

Predicted Task Character: Medium time, medium difficulty.

The glossary tab in Lokalize is unintuitive and hard to use, and current doesn't work at all without manually adding the file that saves the glossary data to disk. The glossary UI needs to be updated so that it is easier to use, and the glossary behaviour needs to be improved so that a file is added to the current project when the file doesn't exist. This requires working with active translators, to ensure the glossary is developed best for Lokalize's users.

Expected Result: Clear and easy-to-use glossary tab UI, fix all crashes / UI inconsistency when trying to use the glossary, save the correct "default" file contents when creating a glossary entry for the first time.

Knowledge Prerequisites: C++ knowledge or at least experience coding, Git / Gitlab, UI design experience might be helpful, willingness to work with users to tailor the redesign to their needs.

Related Bugs: https://bugs.kde.org/show_bug.cgi?id=478793 , https://bugs.kde.org/show_bug.cgi?id=513766

Task 3: Jump to next translation unit when sort filters are applied (NO LONGER ACCEPTING APPLICATIONS)

Predicted Task Character: Short time, medium difficulty.

The editor tab contains a dock widget called "Translation Units" which has the ability to filter entries in translation files with the search bar. You move between units with Page Up / Page Down, and moves between them while approving the translations using Control + Page Down. Using the latter shortcut jumps about in the list, rather than working down the list correctly, one after another. This needs to be fixed so the Control + Page Down shortcut ("Approve and go next") works as expected.

Expected Result: For any filtering / ordering of translation units, moving between them using all shortcuts steps up and down the visible filtered list.

Knowledge Prerequisites: C++ knowledge or at least experience coding, Git / Gitlab, some understanding of model / view architecture.

Related Bugs: https://bugs.kde.org/show_bug.cgi?id=483402

Task 4: Redesign translation memory tab (NO LONGER ACCEPTING APPLICATIONS)

Predicted Task Character: Long time, hard difficulty.

The translation memory tab allows you to pick a TM (saved translation pairs from previous translation jobs / files) to search through, and shows the results in the list below. The UI needs redesigning to enable searching multiple memories at once by selecting the TMs you want to search, rather than picking only one from a drop-down. The selected TMs to search should be saved per-project, so translators can customise their translations per-project (e.g. only use translation memories with formal language for one specific project). Additionally, the "Manage translation memories" button opens a TM manager which should be merged into the tab instead of existing separately e.g. by moving TM-specific entries into the right-click menu, and adding more general buttons into the TM tab page, or the toolbar that is specific to the TM tab.

Stretch Goal(s): Fix the results list so the selected entry is highlighted with the correct colour from the theme (it seems broken?), and make entry rows only one line tall instead of many lines, when entry text is long.

Expected Result: A list of all TMs to pick instead of a drop-down, each entry checkable with a checkbox. Save selected TMs to the project data. Filter searches per TM grouping, searching each TM and sorting results sensibly.

Knowledge Prerequisites: C++, Qt knowledge, Git / Gitlab, familiarity with model / view architecture, willingness to pick through more complicated code in a large established codebase.

Related Bugs: https://bugs.kde.org/show_bug.cgi?id=497653

Task 5: Improved state saving across all tabs (NO LONGER ACCEPTING APPLICATIONS)

Predicted Task Character: Medium time, medium difficulty.

Some tabs save their state for projects, or across projects. This includes the sizes and locations of editor tab dock widgets, and of list headers within those dockwidgets. Some don't save state data, like the glossary tab. The order of tabs is also not saved, although whether the glossary tab or translation memory tab is open IS saved. This means the order of tabs is not consistent across restarts.

Expected Results: All tabs retain their order across restarts. All dock widgets retain the same shape and size. All list headers retain their size and remember which columns are visible. Additionally, all header widths scale proportionally when their list is resized (e.g. a column taking up 50% list space when the list is 40px wide still occupies 50% when the list is 100px wide, instead of remaining at 20px).

Knowledge Prerequisites: C++, Qt knowledge, Git / Gitlab, familiarity with model / view architecture, willingness to pick through more complicated code in a large established codebase.

Task 6: Standardise menubar (NO LONGER ACCEPTING APPLICATIONS)

Predicted Task Character: Medium time, easy difficulty.

Lokalize uses a KDE framework, KXMLGUI, to manage its menubar and status bar. In Lokalize, KXMLGUI allows you to define the contents of the menubar for each tab. Right now the tabs have different options in the menubar menus (not a problem) and also have different ordering of menus (annoying and inconsistent) with some menus missing. I want all tabs to offer the same menubar. Where a tab does not use a menu (e.g. Translation Memory tab does not offer "Go" menu), the menu should be added, with menu options disabled. The goal is to offer a standard menubar for all tabs, even if the menus have only disabled options for some tabs.

Expected Results: All menus visible for all tabs, menu entries enabled / disabled depending on the tab.

Tab order: File, Edit, Go, Project, Sync, Tools, Settings, Help

Stretch Goal: Unify the menubar so it is a single instance belonging to the top-level window, rather than to individual tabs. This requires discussion and planning to ensure it's a sensible idea / it's implemented correctly because e.g. keyboard shortcuts are set up per-tab using KXMLGUI too. Also, the toolbar defaults could be reviewed with translator input to make sure it contains sensible options.

Knowledge Prerequisites: C++, Qt knowledge, Git / Gitlab

Task 7: Modernise PO file read / write (NO LONGER ACCEPTING APPLICATIONS)

Predicted Task Character: Long time, hard difficulty.

The PO file format is changing slightly. Lokalize's PO file parser also has multiple problems with it (see the bug reports below). There was a suggestion to improve the PO file support by integrating libgettextpo since gettext is an "industry standard".

The interested mentee should research how viable this is, decide if the library is suitable to integrate with existing PO read / write capability, and be prepared to work on a challenging task.

Expected Results: Bugs are fixed, Lokalize uses libgettextpo to read and write PO files, and the existing data structures in Lokalize are adapted to work with libgettextpo. Robust read / write ability, hopefully with some new tests that cover bug report examples.

Knowledge Prerequisites: C++, Qt, Git / Gitlab, PO files, confidence handling data structures and unpicking behaviour in a large mature codebase. Enough free time over the next two months!

Related Bug Reports: https://bugs.kde.org/show_bug.cgi?id=490802 , https://bugs.kde.org/show_bug.cgi?id=76495 , https://bugs.kde.org/show_bug.cgi?id=510320

mentorship.kde.org

Project Type: Coding

Repo Link: https://invent.kde.org/paulb/kde-mentor-programs-g-so-c-2025-project

Brief Explanation: mentorship.kde.org currently looks like a website, but does not behave like an onboarding system
This project aims to convert the site into a guided entry point for KDE mentorship.

  • Complete the homepage as a traffic router that guides users to other internal pages
  • Repurpose the /mentorship page into /programs page, listing all mentorship (SoK, GSoC, OSPP if applicable, academic and business mentorship programs)
  • Improve the /mentees page into a hall-of-fame style showcase of past contributors
  • Complete the /resources list of KDE learning materials

Expected Results:

  • Homepage: Fully functional with routing
  • Programs (Mentorship): Listing of all mentorship opportunities
  • Mentees: Improved showcase with consistent cards
  • Resources: Categorized KDE resources

Knowledge Prerequisite: HTML / CSS, Git / Gitlab, familiarity with static site generators, basic JavaScript and a sense of UX would be helpful

Mentor: Anish Tak (@drowsywings:matrix.org), Paul Brown (@bro666:kde.org), channel for discussion: #kde-www:kde.org

Plasma Setup

Project Type: Coding

Repo Link: https://invent.kde.org/plasma/plasma-setup

Plasma Setup is KDE's first run setup wizard, providing a friendly way to create the first user account and configure basic system settings.

Brief Explanation: Plasma Setup currently only supports desktop form factors, and would benefit from support for Plasma Mobile as well.

  • Split kcm_keyboard from plasma-desktop into a separate library in plasma-workspace, since we are currently using it and depending on plasma-desktop makes it impossible to work for plasma-mobile. https://invent.kde.org/plasma/plasma-setup/-/issues/25 By having it in plasma-workspace it can be reused by multiple projects that need its functionality.
  • Make the QML UI responsive so it works well on both desktop and mobile form factors (i.e. phone/tablet). Bonus if it also works well on very large screens, to support Plasma Bigscreen.
  • A stretch goal could be to add support for mobile-specific settings, such as cellular network configuration. (Very optional, only if time permits.)

https://invent.kde.org/plasma/plasma-setup/-/issues/16

Expected Results:

  • Plasma Setup works well on both desktop and mobile form factors.
  • No regressions on desktop from the current state.

Knowledge Prerequisite: C++, QML, Qt, git, UI/UX design experience would be helpful.

Mentor: Kristen McWilliam (@merritt:kde.org)

Channel for discussion: #plasma-setup:kde.org

Scripty

Scripty https://invent.kde.org/sysadmin/l10n-scripty/ is a set of scripts (e.g. Python, Bash) which build and manage the localisation of KDE projects.

Task 1: Standardise translation reference paths across all KDE projects (NO LONGER ACCEPTING APPLICATIONS)

Predicted Task Character: Medium time, medium difficulty.

Translators work on PO files that contain the translation data, including the file path to the file that the specific translation comes from. To understand the purpose of a particular string, sometimes the translators need to view the translatable strings in the code itself. To allow KDE to build tooling around the paths, the PO files must be standardised so that all contain file path references relative to the project root rather than from an arbitrary directory. This work has been started already but needs someone to finish it, which means working on any the edge cases, testing and cleaning up the merge request ready for merging. The current test script is hacky and also needs improving if you want to check your progress as you work.

Expected Results: All reference file paths in all PO files in KDE (e.g. `#: src/alttransview.cpp:163`) are relative to the project root.

Related Merge Requests: https://invent.kde.org/sysadmin/l10n-scripty/-/merge_requests/90

Knowledge Prerequisites: C++, Qt, Bash knowledge, Git / Gitlab, sysadmin

Mentors: Finley Watson (@fin-w:private.coffee , ask on https://matrix.to/#/#kde-mentorship:kde.org and I'll respond)

Automate Promo Data Collection

We need to automatise the collection of data we use to measure our impact on social media and the media in general.

Promo collects data from different sources that measure how our followship grows, how many outlets are talking about us, what is our level engagement, etc.. We want to automate this process.

Task 1: Research APIs, Platforms and Interfaces

Predicted Task Character: Medium time, medium difficulty.

Project Type: Fact-finding

Brief Explanation: Some platforms offer APIs that would allow us to programatically acces our data. Others require a more... er... imaginative approach. In this task you will be required to examine all the sources we grab data from and suggest ways we can do it and maybe even post-process said data.

Expected Results: A strategy that will allow us to move forward with the implementation of bots that can download and process the data we want to collect.

Knowledge Prerequisite: Web scraping, python, bash, etc.

Task 2: Write Bots

Predicted Task Character: Medium time, medium difficulty.

Project Type: Coding

Brief Explanation: Data collected from social media platforms and webs on daily, weekly, monthly and quarterly basis, depending on the what we are collecting. This is more often than not done by hand. It is a time-consuming, repetitive job that scales poorly and could be done by bots. This task seeks to get these bots implemented

Expected Results: A reliable collection of data we do not have to worry about, better productivity for the Promo team, and a system that will survive the absence of the current collectors.

Knowledge Prerequisite: Python, Bash, systemd service creation, web-scraping, machine-based text analysis, NextCloud scripting.

Mentor: Paul Brown, @bro666:kde.org on Matrix.

Automate website updating

We need to keep kde.org fresh. To do so we regularly rotate entries in our highlighted distros, hardware and apps sections.

We would also want to regularly update the photo gallery on KDE's front page

Predicted Task Character: Medium time, medium difficulty.

Project Type: Promo, web

Brief Explanation: Unless we update the content of our website on a regular basis, it becomes stale. We also have app developers and hardware vendors (often patrons) that would like to see their work and products features on our site.

To keep stuff fresh, we have lists of apps, distros and hardware vendors that we rotate on a monthly basis... By hand.

We would want to make this automatic and have system where we could easily add more items to the roster.

Expected Results: automatic updates, improved promo productivity, more flexible web design, mor engaging web presence.

Knowledge Prerequisite: HuGo web scripting, git scripting, Bash, systemd

Mentor: Paul Brown, @bro666:kde.org