Gardening: Difference between revisions

From KDE Community Wiki
No edit summary
(Add Gcompris and KDiff3 to MR exclusions)
 
(33 intermediate revisions by 8 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.
You can also join the [https://go.kde.org/matrix/#/#gardening-team:kde.org Gardening Team Matrix room] for live chat.


Kanboard: https://todo.kde.org/?controller=board&action=show&project_id=26
== 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|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/KDE For All|KDE For All: Boosting Accessibility]], [[Goals/Sustainable Software|Sustainable Software]] and [[Goals/Automate and systematize internal processes|Automate and systematize internal processes]]. See also https://kde.org/goals


The mandate of the team is to:
== Methods and Tasks ==
# Find *really* important bugs and ping people to fix them
To support the goals mentioned above, focus on the following actions that need doing:
# Find stale reviewboards and ping people to review them
# Bugzilla gardening, close old products etc
# Find projects that need love and give them some


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


For that we have various ideas:
=== 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.


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 ;)
=== GitLab ===
* Find [https://invent.kde.org/dashboard/merge_requests?draft=no&not%5Blabel_name%5D%5B%5D=Gardening%3A+Stale&scope=all&sort=updated_asc&state=opened 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.


Do routine passes over reviewboard trying to identify stale requests and finding people to help moving those.
A template response for stale merge requests (defined as a merge request with no activity for 30 days) is below:


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


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!
Note that KDE Gardening will **NOT** close this MR, only the projects maintainers or the author of an MR can close it.


== Current Bug Of The Month ==
Thanks,
[[Gardening/BugOfTheMonth|Bug 324975: Volume gets restored to 100% after each knotify event]]
[NAME], KDE Gardening



== Current Love Project ==
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
Deciding


== Past Love Projects ==
=== Pay attention to feedback ===
[[Gardening/K3b|K3b]]
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?"


== Love Project Bug Triage ==
=== Designate a "Bug of the Month" ===
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.
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.


== Origin ==
==== 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 ====
* [[Gardening/docwebsites|Documentation Sites]]
* [[Gardening/KRecipes|KRecipes]]
* [[Gardening/K3b|K3b]]
* [[Gardening/systemsettings|System Settings]]
 
= Exclusions =
 
{| class="wikitable"
! Project
! Initiatives to be excluded
! Requester
! Requester Email Address
|-
| Krita
| All
| Halla Rempt
|-
| Okteta
| All
| Friedrich W. H. Kossebau
|-
| Falkon
| All
| Juraj Oravec
|-
| KDiff3
| Merge Requests
| Michael Reeves
|-
| Gcompris
| Merge Requests
| Johnny Jazeix
|-
| Harald Sitter's Bug Reports
| Bug reports
| Harald Sitter
|}
 
= 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.

Latest revision as of 06:45, 15 March 2023

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. You can also join the Gardening Team Matrix room for live chat.

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