Jump to content

Gardening: Difference between revisions

From KDE Community Wiki
Tysontan (talk | contribs)
No edit summary
Ngraham (talk | contribs)
Overhaul this page
Line 1: Line 1:
[[File:Mascot konqi-app-system.png|thumbnail|right|Help [[Konqi]] keep all KDE gears mesh well!]]
[[File:Mascot konqi-app-system.png|thumbnail|right|Help [[Konqi]] keep all KDE gears mesh well!]]
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
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


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)


For that we have various ideas:
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?"


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 ;)


Do routine passes over reviewboard trying to identify stale requests and finding people to help moving those.
== 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.


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.
=== Bugzilla ===
* [[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.


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!
=== GitLab ===
* 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.


== Current Bug Of The Month ==
=== Designate "Love Projects" ===
[[Gardening/BugOfTheMonth|Bug 309193: Keyboard shortcuts doesn't work if non-english keyboard layout is set before english one]]
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 ==
==== Current Love project ====
* [[Gardening/systemsettings|System Settings]]
None! Let's pick one!


== Past Love Projects ==
==== Past Love Projects ====
* [[Gardening/docwebsites|Documentation Sites]]
* [[Gardening/docwebsites|Documentation Sites]]
* [[Gardening/KRecipes|KRecipes]]
* [[Gardening/KRecipes|KRecipes]]
* [[Gardening/K3b|K3b]]
* [[Gardening/K3b|K3b]]
* [[Gardening/systemsettings|System Settings]]
=== Designate a "Bug of the month" ===
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 ;)
==== Current bug of the month ====
[[Gardening/BugOfTheMonth|Bug 309193: Keyboard shortcuts doesn't work if non-english keyboard layout is set before english one]]


== Love Project Bug Triage ==
To collaboratively go through a Love project bug list, look at each bug and for mark the flags gardening field as + for reallyCriticalCrashers ? for easy bugs and - for outOfScope.


== Origin ==
= 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.
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 02:26, 26 July 2020

Help Konqi keep all KDE gears mesh well!

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 "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

Designate a "Bug of the month"

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 ;)

Current bug of the month

Bug 309193: Keyboard shortcuts doesn't work if non-english keyboard layout is set before english one


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.