Nova Flow OS
KDE Developer Platform
KDE Developer Platform
  • KDE Developer Platform
    • Getting started
      • Building KDE software
        • KDE software
        • Where to find the development team
        • Learning more
        • Choose what to work on
        • Source code cross-referencing
        • Installing build dependencies
        • Set up a development environment
        • Building KDE software with kdesrc-build
        • Basic troubleshooting
        • Tips and tricks
        • IDE Configuration
          • Setting up an IDE for KDE development
          • Visual Studio Code
          • Qt Creator
          • Kate
          • KDevelop
          • CLion
          • Sublime Text
        • Building KDE software manually
        • Building KDE software with distrobox and podman
      • Kirigami
        • KDE is ours
        • Setting up and getting started
        • Explaining pages
        • Layouts, ListViews, and Cards
        • Adding actions
        • Adding a dialog
        • Using separate files
        • Next steps
        • Colors and themes in Kirigami
        • Typography
        • Actions based components
        • Page rows and page stacks
        • Scrollable pages and list views
        • Cards
        • Drawers
        • Chips
        • Dialog types
        • Controls and interactive elements
        • Form layouts
        • Inline messages
        • Action toolbars
        • Progress bars and indicators
        • List views
        • Understanding CMakeLists
        • Figuring out main.cpp
        • Connect logic to your QML user interface
        • Connect models to your QML user interface
        • About page
        • Introduction to Kirigami Addons
        • FormCard About pages
        • Form delegates in your settings pages
      • KXmlGui
        • Getting started with KXmlGui
        • Hello World!
        • Creating the main window
        • Using actions
        • Saving and loading
        • Command line interface
      • Python with Kirigami
        • Apps with QML and Python
        • Your first Python + Kirigami application
        • Creating a Python package
        • Creating a Flatpak
      • Common programming mistakes
      • Adding a new KDE project
    • Features
      • Icons
      • Configuration
        • The KConfig Framework
        • Introduction to KConfig
        • Using KConfig XT
        • KDE Frameworks 6 porting guide
        • Settings module (KCM) development
        • KConfigDialog
      • D-Bus
        • What is D-Bus practically useful for?
        • Introduction to D-Bus
        • Accessing D-Bus interfaces
        • Intermediate D-Bus
        • Creating D-Bus interfaces
        • Using custom types with D-Bus
        • D-Bus autostart services
      • Create your own mouse cursor theme
      • Session management
      • Archives
      • Desktop file
      • KAuth
        • Privilege Escalation
        • Using actions in your applications
      • KIdleTime
      • Akonadi: personal information management
        • Debugging Akonadi Resources
        • Using Akonadi in applications
      • Concurrent programming
      • Solid
      • Sonnet
    • Plasma themes and plugins
      • Getting started
      • Plasma Widget tutorial
        • How to create a plasmoid
        • Setup
        • Porting Plasmoids to KF6
        • Testing
        • QML
        • Plasma's QML API
        • Widget Properties
        • Configuration
        • Translations / i18n
        • Examples
        • C++ API
      • KWin Effects
      • Plasma Desktop scripting
        • Javascript Interaction With Plasma Shells
        • Templates
        • Examples
        • API documentation
        • Configuration keys
      • Plasma Style tutorial
        • Creating a Plasma Style quickstart
        • Understanding Plasma Styles
        • SVG elements and Inkscape
        • Background SVG format
        • System and accent colors
        • Theme elements reference
        • Porting themes to Plasma 5
        • Porting themes to Plasma 6
      • Aurorae window decorations
      • KWin scripting tutorial
        • Quick start
        • KWin scripting API
      • Wallpapers
      • Plasma comic
        • Tutorial
        • Testing and debugging
        • Examples
      • Create a custom Window Switcher
      • KRunner C++ Plugin
        • Basic Anatomy of a Runner
        • KRunner metadata format
    • Applications
      • Creating sensor faces
      • Dolphin
        • Creating Dolphin service menus
      • Kate
        • Kate plugin tutorial
      • KMines
        • Making a KMines theme
      • Writing tests
        • Appium automation testing
    • Packaging
      • Android
        • KDE on Android
        • Building applications for Android
        • Packaging and publishing applications for Android
        • Publishing on Google Play
          • Introduction
          • Packaging your app
          • Adding your app to Google Play
          • Publishing your app
          • Releasing new versions of old apps
        • Porting applications to Android
          • Basic porting
          • Making applications run well on Android
          • Metadata
      • Windows
        • Packaging and publishing applications for Windows
        • Publish your app in the Microsoft Store
          • Packaging your app for the Microsoft Store
          • Submitting your app to the Microsoft Store
      • Plasma Mobile
        • KDE on mobile devices
        • Porting a new device to Plasma Mobile
        • KDE Telephony stack
          • General Overview
          • Kernel layer
          • System daemons
            • General overview
            • Developing Telephony functionality
            • ModemManager Telephony functions
          • Session daemons
          • QML declarative plugin layer
          • KDE application layer
        • Execute applications
      • Distributing KDE software as Flatpak
        • Your first Flatpak
        • Extending your package
        • Nightly Flatpaks and Flathub
        • Testing your Flatpak
    • System administration
      • Shell scripting with KDE dialogs
      • Kiosk: Simple configuration management for large deployment
        • Abstract
        • Introduction to Kiosk
        • Kiosk keys
    • Contribute to the documentation
    • About
      • Readme
      • License
        • Creative Commons Attribution-ShareAlike 4.0 International
        • GNU General Public License 3.0 or later
Powered by GitBook
On this page
  • Incubator
  • KDE Review
  1. KDE Developer Platform
  2. Getting started

Adding a new KDE project

How to make your project be a part of the KDE community

PreviousCommon programming mistakesNextFeatures

Last updated 8 months ago

To add a new application or library to the KDE ecosystem, follow the Incubator and/or KDE Review processes as described below.

You will need a to use .

Incubator

For projects which started outside of KDE.

Requirements

**KDE Incubator checklist**
- [ ] Incubation Sponsor is..
- [ ] E-mailed kde-devel@ and other relevant lists on YYYY-MM-DD
- [ ] Compliance with the [https://manifesto.kde.org KDE Manifesto]
- [ ] Governance similar to the other KDE projects
- [ ] Clear product vision
- [ ] Healthy team (healthy proportion of volunteers, inclusive towards new contributors, ideally more than one developer)
- [ ] Uses English for code and communication
- [ ] Continuity agreement must be in place with KDE e.V. for domains and trademarks if the authors disappear
- [ ] Recommended to attend [Akademy](https://akademy.kde.org) or other local KDE events
- [ ] Code in [KDE Invent](https://invent.kde.org)
- [ ] Passing CI job for reuse linting

You can learn how to create CI jobs for REUSE compliance following the .

Process

"Candidate" Phase

Send an email to kde-devel@kde.org and other relevant lists requesting a sponsor pointing to the issue and including the same background description.

Agree with the sponsor which of the boxes in the checklist is already complete and put X in those.

"Incubating" Phase

During this phase, the sponsor actively works toward getting the project set up by doing the following:

  • Making sure the project developers have developer accounts

  • Contacting sysadmin to get Git repos (in the playground area) set up for the developers

  • Following the process to make sure it's going in the right direction and not getting stalled

At this point, the project cannot yet use the KDE brand or have a top level website on kde.org. If the project becomes stalled or does not conform to the manifesto, it gets archived (see below).

Either the owner or the sponsor can edit the checklist as the items get completed.

"Active" Phase

During the Active phase, the project enters Playground. When it is nearing a beta release it can be moved to KDE Review. The project team is assumed and expected to behave like other KDE teams and respect the KDE manifesto.

Stalled and Archived Projects

A project is considered stalled when for one year, there is no release, no commits, and no mailing-list activity. Current maintainers are contacted to check what's happening. If there is no activity or no reply from existing maintainers, after a month then a call to new maintainers is done. If a new maintainer shows up he or she gets a six month trial. If after a month no new maintainer showed up, the project gets archived.

When a project gets archived, the source repo gets closed, the mailing list disabled, and only the last download is available. If someone wants to pick it up, it goes back to the "Candidate" phase.

Notes

KDE Review

For any project to become an official part of KDE.

Requirements

**KDE Review checklist**
- [ ] If from outside KDE, has completed the [Incubator](https://community.kde.org/Incubator) process
- [ ] The [REUSE Specification - Version 3.0](https://reuse.software/spec/) is applied when stating licenses and when adding license files to a project. Each source file either must contain SPDX identifiers or license headers to state under which terms the software may be used, modified and redistributed. See [Licensing Policy](https://community.kde.org/Policies/Licensing_Policy#License_Statements)
- [ ] Passing CI job for Reuse linting
- [ ] A [Messages.sh file](https://techbase.kde.org/Development/Tutorials/Localization/i18n_Build_Systems#Writing_a_Messages.sh_script) which extracts all the i18n() translations
- [ ] A metainfo.xml file (previously appdata.xml) with AppStream data [AppStream Guidelines](https://community.kde.org/Guidelines_and_HOWTOs/AppStream )
- [ ] A screenshot in [product-screenshots](https://invent.kde.org/websites/product-screenshots)
- [ ] Check the code with some sanity tools like [clazy](https://kde.org/applications/development/org.kde.clazy) or [clang-tidy](https://clang.llvm.org/extra/clang-tidy), if not already done as part of CI runs.
- [ ] Documentation appropriate to the project: if a library, API documentation (such as [Doxygen](https://www.doxygen.nl/) for C++), if an application, user documentation (such as a README detailing what the application does or is for, how to install/build, and other such useful information)
- [ ] A [bugs.kde.org](https://bugs.kde.org) product (file a [sysadmin ticket](https://community.kde.org/Sysadmin))
- [ ] Passing [Gitlab CI build jobs](https://mail.kde.org/pipermail/kde-devel/2021-September/000717.html)
- [ ] Passing [KDE neon](https://build.neon.kde.org) build
- [ ] App packages in [Flatpak](https://develop.kde.org/docs/packaging/flatpak/), [Snap](https://community.kde.org/Guidelines_and_HOWTOs/Snap), [AppImages and Windows](https://community.kde.org/Craft) etc. as appropriate

Process

  • Make fixes to issues people bring up or provide explanation why they are not (yet) fixed

  • Wait at least two weeks in KDE Review

  • After two months in KDE Review the repo should be moved back to playground or moved to unmaintained

Create a project on and import the existing code. This can be in a personal space on KDE Invent. You might need to ask sysadmin to import the code.

Create an issue on the KDE Invent project with a label of "Incubation Request". Copy the checklist above and paste it into the issue without checking anything first, then include background on the project: a description of the project to be incubated, a list of the people committing to the project, and a plan to be in compliance with the . The project must be hosted or moved to KDE infrastructure (or have an action plan that ensures continuity). In other words, code should be in KDE Invent instead of Github, the issue tracker should be in the instead of Github Issues, etc.

Here are which led to the current process.

Projects move into KDE Review when they are ready to start making beta or stable releases. It allows for the KDE community to check over for minimum standards. If you have any translations notify the to move the translations.

File an issue in your project and Label it "KDE Review Request" and paste the requirements list above into it without checking anything on it

You can change the projectpath in by editing metadata.yaml for the project. See or file a

E-mail and other relevant mailing lists with details of your project and what the expected destination is for the repo

KDE Identity
KDE Invent
Continuous Integration wiki page
KDE Invent
KDE manifesto
KDE Bugzilla
notes
kde-i18n-doc mailing list
KDE Invent
repo-metadata
repo-metadata README
Sysadmin ticket asking for the move
kde-core-devel