Goals/Automate and systematize internal processes

One of KDE's three overarching goals is to improve institutional memory by automating and systematizing internal processes, expanding documentation, and working more as teams rather than isolated individuals. See the original proposal at https://phabricator.kde.org/T15627.

Follow our progress

Weekly progress is posted at https://pointieststick.com/category/automation-systematization!

Communicate with the team

Join the #kde-institutional-memory:kde.org room on Matrix!

There is also a team you can join at https://invent.kde.org/teams/automation. Once you join the team, don't forget to set your notification preferences to "Watch" or else you'll miss things. Long-term task tracking will be done at https://invent.kde.org/teams/automation/issues/-/issues.

How you can help

Here are some examples of things you can do to help make this a reality:

Documentation

• Add and improve API documentation for library components with poor or missing documentation.
• Codify and document the steps required for adequately QAing merge requests at https://community.kde.org/Infrastructure/GitLab#Perform_QA
• Improve developer and internal process documentation to be good enough that contributors can generally answer their own questions rather than asking in real-time chatrooms. Move our specialized knowledge out of our heads!
• Create and document an "offboarding" process so that people transitioning away from KDE can hand off their work to any other interested community members, and their knowledge can be preserved.
• Move documentation into the git repo for the software it describes, and then require that every commit and merge request that changes anything be accompanied by a change to the relevant documentation, so that it always remains accurate.

Continuous integration

• For repos that have CI which does not require all tests to pass, change that and then fix or remove all tests that are persistently or randomly failing, as they have no value.
• Enable the "reuse-lint" CI runner for repos that don't currently have it active, and then fix the license issues it finds by contacting the authors of files with no license information and asking them to decide on a license.
• Add a new CI runner to check for English spelling and grammar mistakes.
• Add a new CI runner to check for translated strings without sufficient context--particularly single-word strings.
• Add a CI runner to do fuzzing; eventually make it a mandatory-pass thing after fixing all issues.
• Make the cppcheck CI runner actually run clang-format and fail for code that isn't compliant. If this is annoying, fix our clang-format rules so it isn't!

Bugzilla

• Change Bugzillas internal rules to require posting a comment when re-opening a resolved bug report.
• Make DrKonqi stricter about accepting un-actionable backtraces without debug symbols. Don't let it!
• Work on the bugzilla bot, making it handle more things. Ideas:
  • Auto-close old UNCONFIRMED bugs after a few warnings (https://bugs.kde.org/show_bug.cgi?id=224641).
  • If a bug report with the crash severity doesn't have a backtrace attached or pasted inline, nag for one.
  • If a backtrace was attached, paste it inline.
  • If an inline backtrace lacks debug symbols (search for " in () at "), nag the reporter to fix it; maybe this can be done by https://bugs.kde.org/show_bug.cgi?id=354217?
  • If a commit references the number of the bug it fixes, infer the version fixed in from the milestone or the target branch of the related merge request

Chat

• Write a chat bot to paste the following into the #plasma room once per day:

X VHI priority regressions (https://tinyurl.com/plasma-vhi-regressions)
X VHI priority bugs (https://tinyurl.com/plasma-vhi-bugss)
X HI priority bugs (https://tinyurl.com/plasma-15-minute-bugs)
X Regressions in general: (https://tinyurl.com/plasma-regressions) n fewer than yesterday etc

GitLab

• Create a merge request template like the Bugzilla bug report template which prompts people to do things like write testing steps and make documentation changes alongside any UI changes.
• Change the culture around QA to adopt the mindset of "it's ready when it stops failing, not when it starts working." Encourage merge requests to be thoroughly tested before they are submitted, as well as during the review process.
• Nag people who make changes in code to also get the accompanying documentation up to date.
• Write a bot to automatically cherry-pick the commits from merge-requests with the "cherry-pick" keyword attached, targeting the branch specified in the milestone. If it tries and fails, it should loudly yell!
• Write a bot to automatically update the milestones for open merge requests that are targeting old milestones when the Plasma version they're for becomes ineligible for new features.
• Write a bot to automatically check whether a commit to be cherry-picked onto a stable branch contains any changes to translatable strings when the Plasma version it targets has become ineligible for string changes. If it does, it should loudly yell!

Release process

• Unify on one set of release tooling for Frameworks, Gear and Plasma, so that any release person becomes capable of making a new release of any of those pieces of software!
• Encourage apps to join KDE Gear and adopt its version numbering schema, so that they don't have to be self-released.

Teams

• Encourage projects to make use of the QA team for merge request review.
• Create project-specific teams on invent.kde.org for large projects that span multiple repos (e.g. Plasma, KDE PIM, System Settings) and encourage people to join those teams when contributing to their projects. Contributing to KDE should feel like being a member of a group, not an individual feeding inputs into a giant machine.
• Encourage people to join the volunteer Gardening team and help coordinate the efforts of volunteers and sponsored contributors.
• Encourage people to join the volunteer QA team and perform QA on open merge requests to make sure they do what they say they do and don't cause regressions.
• I move my "This week in KDE" blog series to KDE infrastructure and open it up to other contributors, standardizing around an open process that has a bus factor greater than 1.