As announced at Akademy a few days ago, I’m honored that my goal – Automate and Systematize Internal Processes – has been chosen by the KDE community! Those are a bunch of fancy words, but the idea is pretty simple: get our expertise (knowledge, skill, and wisdom) out of our heads, and onto KDE’s infrastructure.
Why? to reduce the burden on us personally to provide so much of that expertise on demand as an ongoing service, and to reduce the impact of breaks, vacations, and departures. Ultimately this will preserve expertise publicly in KDE where it’s easier to learn from, and free us all up to do other things!
There are many ways to contribute which can be found on the goal page. I’ll condense a bit and list some examples here:
- Create automated tests to check for things you currently know to check for manually when reviewing code
- Broadly improve documentation of internal processes; when you make a change to one of them, document it!
- Write code comments that explain why something is implemented the way it is (not what it is or what it’s doing)
- Adopt the
reuse-lintcontinuous integration pipeline and
clang-formatgit hookscript so they can do the boring work of checking for licensing and code formatting
- Extend the Bugzilla bot to check for and provide canned answers in response to more conditions in new bug reports (missing backtrace for a crash bug, backtrace missing symbols, backtrace attached rather than pasted inline, etc)
- Document the responses to common questions in FAQ-type pages, and provide links to them publicly in response to those questions so others know about them and can add to them themselves (e.g. see the VDG’s “Lessons Learned” page)
- Document undocumented public APIs
- Look for synergies; Harald’s idea to do UI testing using the accessibility APIs is a fantastic example, as it would systematically drive improvements for two things at once and prevent them from silently regressing
- Don’t ping individual people; ping teams/groups/mailing lists etc. If there is no applicable collective entity containing the people you want to ping, create one and encourage them to join it
- If you’re leaving KDE or don’t have time to maintain some of your projects anymore, perform offboarding; find people to hand things off to and teach them how to be you
There are a lot more things, but hopefully you get the idea. So let’s get out there and automate and systematize everything!
I’ll be documenting our progress and successes like I did with the Usability & Productivity goal… and, updating that goals wiki page would be a good step too. A GitLab workboard will probably pop up too, and I’ll let folks know about it once it exists. If people think a Matrix room would be helpful, we can get that going as well.
And thanks again for choosing this goal, everyone! You’re the best.
6 thoughts on “Automate and systematize all the things!”
This is an amazing idea! Congrats!
LikeLiked by 1 person
great initiative! One little suggestion: At work we recently evolved from using “only” `git-clang-format` to leverage the full power of `pre-commit`. It’s super useful as it is a whole framework that can integrate arbitrary linters into the git pre-commit hook. It also comes with linters and formatters for cmake and python for example, both of which would be useful to have in KDE too.
It’s also very easy to leverage that same infrastructure in a CI hook, which is another bonus. I can only recommend you look into that and ideally roll that out across all the interested KDE projects.
Absolutely, that sounds like a great idea. The way to do this would be to integrate such functionality into the standard set of sysadmin-provided CI templates that live at https://invent.kde.org/sysadmin/ci-utilities/-/tree/master/gitlab-templates.
Given your pre-existing familiarity with the proposed additions, this would be a super contribution opportunity for you!
> If people think a Matrix room would be helpful, we can get that going as well.
I think it would.
Additionally, for a while I’ve been thinking that on top of API-level docs, adding high-level documentation describing the structure of the code will help contributors get up to speed and start making changes faster. See https://matklad.github.io/2021/02/06/ARCHITECTURE.md.html. I think this would fit well in this goal.
Indeed. As a newcomer toying with contributing, what is not clear is how individual components are related. For example, there is the Kicker and Kickoff start menus, which are name differently in the interface and on github, one of which can develop into Application Dashboard and one of which evidently (?) used to be a much bigger project in KDE4 days – at least that is what I gathered from randomly looking around and googling. I am still not sure why there are two menus, if one of them is preferred and what are the differences between them. Maybe the information is somewhere – I have not found it though.
“If you’re leaving KDE or don’t have time to maintain some of your projects anymore, perform offboarding; find people to hand things off to and teach them how to be you”
This is critical to the future viability of any project, especially one with so many moving parts. Bravo!
LikeLiked by 1 person