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.
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 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, and if it is, confirm if you are still willing to work on it?

If it isn’t needed anymore, or if you aren’t willing to work on it, please kindly close this merge request, to help clean things up. Thanks! - [NAME], KDE Gardening "

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

None! Let's pick one!

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

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.