The Gardening Team is a group of people that cares about the global state of KDE software. In a commercial company, this would be the management team. Anyone is welcome to join the Gardening team! To do so, subscribe to the mailing list and introduce yourself. You can also join the Gardening Team Matrix room for live chat.

Overview

Members of the Gardening team do the following:

Maintain a "10,000 foot view" of the state of the whole KDE community
Understand KDE's market position and that of competitors
Articulate the strengths and weaknesses of KDE software
Help guide development in directions that leverage strengths and address weaknesses
Work with distributors and hardware vendors to make KDE software more widely available
Help advance the KDE community's goals, which are determined by the KDE community itself roughly every odd-numbered year through the goal setting process. Current goals are: KDE For All: Boosting Accessibility, Sustainable Software and Automate and systematize internal processes. See also https://kde.org/goals

Methods and Tasks

To support the goals mentioned above, focus on the following actions that need doing:

Bridge the gap between developers, users, and distributors/vendors

Identify issues causing pain to distributors and hardware vendors which are blocking their adoption of KDE software.
For high impact issues such as the above, or those discovered through bug triaging, ping existing KDE developers to fix them, find community members to fix them, or fix them yourself.
Participate in KDE-related social media to maintain your connection to users and understanding of their needs and complaints.

Bugzilla

Triage all new bugs every day by visiting this link daily. Mark any bug that's a recent regression bug with the "regression" keyword. This typically takes only 10 or 15 minutes.
Identify trends in user-submitted bug reports. Do the same topics come up over and over again? Do certain projects seem especially buggy? Are there any cases where maintainers or bug triagers are causing friction with bug reporters? Escalate to the Community Working Group if needed.
Identify projects in need of bug triage and development activity by looking at the Bugzilla Summary page.
Identify issues that seem especially urgent to fix, for example because because they have many duplicates, cause data loss, or are really obvious and embarrassing. For such issues, raise their priority to "VHI" ("very high"). Exercise judgment and care when doing this, and avoid marking wishlist bugs with the VHI priority.
Close Bugzilla products for unmaintained/abandoned software.
Consolidate Bugzilla products and components to be more logical. For example, all System Settings KCMs should have a dedicated component within the System Settings product, rather than being tracked elsewhere.

GitLab

Find stale merge requests and ping the relevant people to review them, or the authors to update their code in response to feedback.
Do not action any Krita Merge Requests as they have their own workflow.
Review high-importance merge requests.
Identify merge requests from new contributors and review them quickly with maximum politeness and accommodation to give them a good first impression of KDE.

A template response for stale merge requests (defined as a merge request with no activity for 30 days) is below:

Hey! Thanks for helping out with developing KDE software! This merge request has been stale for a while;
can you confirm that the merge request is still needed? If it is, are you still willing to work on it?

If this merge request isn’t needed anymore, or if you aren’t willing to work on it, you may close it.

Note that KDE Gardening will **NOT** close this MR, only the projects maintainers or the author of an MR can close it.

Thanks,
[NAME], KDE Gardening

Note that the tag "Gardening: Stale" should also be added to the MR. This can be done by typing `/label ~"Gardening: Stale"` into the comments field, or even just on a newline at the end of the template

Pay attention to feedback

Listen to feedback from users, community members, and distributor/vendor partners, and pay attention to what competitors are doing. We ask questions like, "What are we bad at that we urgently need to improve on?", or "What are we good at that we should be pushing on even harder?", and "How can we increase the reach of KDE software and broaden its adoption?"

Designate a "Bug of the Month"

See Gardening/BugOfTheMonth. Try to find monthly a bug to get people to fix it, by highlighting it as "The Bug of The Month" or something. Of course this bug can't be something impossible that could require re-engineering everything; it has to be doable within a month by a single person or a small team.

Current bug of the month

January 2023: https://bugs.kde.org/show_bug.cgi?id=391905

Designate "Love Projects"

The idea is to periodically pick a project that is in need of significant work, and for a short amount of time (let's say 2-3 months), fix the most important bugs, implement commonly requested new features, clear out merge request queues, and so on. The goal is *not* to become the maintainers of the project, but maybe by virtue of the "Love Project" we can attract new contributors who decide to stick around and continue the work so it becomes more self-sustaining.

Current Love project

None! Let's pick one!

Past Love Projects

Exclusions

Project	Initiatives to be excluded	Requester	Requester Email Address
Krita	All	Halla Rempt	[email protected]
Okteta	All	Friedrich W. H. Kossebau	[email protected]
Falkon	All	Juraj Oravec	[email protected]
KDiff3	Merge Requests	Michael Reeves	[email protected]
Gcompris	Merge Requests	Johnny Jazeix	[email protected]
Harald Sitter's Bug Reports	Bug reports	Harald Sitter	[email protected]

Origin

This originated at Akademy 2014 as result of a short talk (8 min) + BoF with a title called "Quality is in the eye of the beholder" by Albert Astals Cid.