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.
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.
- 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.
- 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
|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]|