Gardening: Difference between revisions

From KDE Community Wiki
(Created page with "The Gardening Team is a group of people that cares about the global state of KDE software. Mailing List: https://mail.kde.org/mailman/listinfo/kde-gardening Kanboard: https:...")
 
(21 intermediate revisions by 5 users not shown)
Line 1: Line 1:
The Gardening Team is a group of people that cares about the global state of KDE software.
[[File:Mascot konqi-app-office.png|thumbnail|right|Help [[Konqi]] keep everything running smoothly!]]


Mailing List: https://mail.kde.org/mailman/listinfo/kde-gardening
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, [https://mail.kde.org/mailman/listinfo/kde-gardening subscribe to the mailing list] and introduce yourself.


Kanboard: https://todo.kde.org/?controller=board&action=show&project_id=26


The mandate of the team is to:
== Overview ==
# Find *really* important bugs and ping people to fix them
Members of the Gardening team do the following:
# Find stale reviewboards and ping people to review them
# Maintain a "10,000 foot view" of the state of the whole KDE community
# Bugzilla gardening, close old products etc
# Understand KDE's market position and that of competitors
# Find projects that need love and give them some
# 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


For that we have various ideas:
Another major task of the Gardening team is to help advance the KDE community's [[Goals|goals]], which are determined by the KDE community itself roughly every odd-numbered year through the [https://phabricator.kde.org/project/profile/243/ goal setting process]. Current goals are:
# [[Goals/All about the Apps|"All about the Apps"]] (Advance and improve KDE's applications and autonomy in making them available to users)
# [[Goals/Consistency|Consistency]] (Improve consistency and code re-use through KDE software)
# [[Goals/Wayland|Wayland]] (Make the Plasma and KDE apps usable on Wayland)


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 stuff like "Make Okular support javascript", it has to be something that is really a pain point of the whole user base and we think we can find people to fix it, it makes no sense setting impossible goals ;)
Finally, we 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?"


Do routine passes over reviewboard trying to identify stale requests and finding people to help moving those.


Run something called "Love Project". The idea is to pick up a project that is somewhat stale, and for a short amount of time (let's say 2/3 months) try to get a new release out, fix the most important crashers/bugs, get the review boards released, etc. This goal of the team is *not* becoming the maintainers of the project, but maybe by virtue of the "Love Project" we can attract new contributors that decide to.
== Methods and Tasks ==
To support the goals mentioned above, focus on the following actions that need doing:


Since we're only a few maybe we can't do this all, so we're focusing on a particular "Love Project" by now, but you should join and help us do more!
=== 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.


== Current Love Project ==
=== Bugzilla ===
K3b
* [[Guidelines and HOWTOs/Bug triaging|Triage all new bugs]] every day by visiting [https://bugs.kde.org/buglist.cgi?bug_status=UNCONFIRMED&bug_status=REOPENED&f1=creation_ts&f2=bug_status&list_id=1445277&o1=changedafter&o2=anyexact&order=changeddate%20DESC%2Cbug_status%2Cpriority%2Cassigned_to%2Cbug_id&query_format=advanced&v1=24h 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 [[CWG|Community Working Group]] if needed.
* Identify projects in need of bug triage and development activity by looking at the [https://bugs.kde.org/weekly-bug-summary.cgi 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.


== Origin ==
=== GitLab ===
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.
* Find [https://invent.kde.org/dashboard/merge_requests?scope=all&sort=created_asc&state=opened&utf8=%E2%9C%93&wip=no stale merge requests] and ping the relevant people to review them, or the authors to update their code in response to feedback.
* Perform review of 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.
 
=== 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 ====
* [[Gardening/docwebsites|Documentation Sites]]
* [[Gardening/KRecipes|KRecipes]]
* [[Gardening/K3b|K3b]]
* [[Gardening/systemsettings|System Settings]]
 
 
= Origin =
This originated at Akademy 2014 as result of a [http://files.kde.org/akademy/2014/videos/Quality_is_in_the_eye_of_the_beholder_-_Albert_Astals_Cid.webm short talk (8 min)] + [http://lists.kde.org/?l=kde-core-devel&m=141134036017845&w=2 BoF] with a title called "Quality is in the eye of the beholder" by Albert Astals Cid.

Revision as of 07:27, 5 August 2020

Help Konqi keep everything running smoothly!

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.


Overview

Members of the Gardening team do the following:

  1. Maintain a "10,000 foot view" of the state of the whole KDE community
  2. Understand KDE's market position and that of competitors
  3. Articulate the strengths and weaknesses of KDE software
  4. Help guide development in directions that leverage strengths and address weaknesses
  5. Work with distributors and hardware vendors to make KDE software more widely available

Another major task of the Gardening team is to 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:

  1. "All about the Apps" (Advance and improve KDE's applications and autonomy in making them available to users)
  2. Consistency (Improve consistency and code re-use through KDE software)
  3. Wayland (Make the Plasma and KDE apps usable on Wayland)

Finally, we 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?"


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.
  • Perform review of 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.

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.