Automate and systematize internal processes
Open, Needs TriagePublic

Tokens
"Like" token, awarded by murrant."Like" token, awarded by mart."Like" token, awarded by kmaterka."Like" token, awarded by iclementine."Like" token, awarded by SGOrava."Love" token, awarded by maxrd2."Love" token, awarded by cuperino."Love" token, awarded by rwbarat."Love" token, awarded by jdk."Like" token, awarded by abrahams."Love" token, awarded by akselmo."Love" token, awarded by szwendacz."Love" token, awarded by thomross."Love" token, awarded by logicalwillow."Love" token, awarded by hellokartikey."Love" token, awarded by thiagosueto."Mountain of Wealth" token, awarded by adrlopgal."Love" token, awarded by Guilhermems."100" token, awarded by alexde."Mountain of Wealth" token, awarded by vkhatab."Like" token, awarded by idimitrov."Love" token, awarded by momocao."Love" token, awarded by dmitrym."Love" token, awarded by fhek."Love" token, awarded by frdbr."Love" token, awarded by martintorres."Like" token, awarded by ravier."Love" token, awarded by aronkvh."Love" token, awarded by kilab."Love" token, awarded by niccolove.
Assigned To
Authored By
ngraham, Jun 22 2022

Description

Motivation

Today KDE's technical activities are very people-powered. People perform code review, people propose formatting changes, people triage bugs, and so on. As a result, a lot of our work is labor intensive and prone to human error. It's also often done by specific individuals who have specialized knowledge, rather than teams with knowledge broadly documented.

KDE already has some team-based workflows and documention, and has moved towards some greater automation with changes like pre-commit continuous integration in GitLab, running clang-format across our codebases with git hookscripts, and a bugzilla bot that can automatically close old bug reports. These tools amplify the productivity of individual contributors by reducing manual busywork. But this effort has been sporadic and we can go much further to minimize human error and turbocharge productivity!

Plan

Here are some examples of what we can do:

Automate everything

  • Make the bugzilla bot detect more problematic bug reports and apply canned replies, to reduce the need for manual bug triaging.
  • Move clang-format from a git hookscript to pre-commit CI so that merge requests will show a CI failure when badly-formatted changes exist, and people can see this in a nice UI and fix them
  • Add CI checks for English spellchecking.
  • Add CI checks for missing i18n() context markers and text.
  • When we make a change to our code format policy, enshrine it in clang-format; make it more opinionated so that code style arguments are avoided.
  • Add automatic fuzzing.
  • Add a QML linter to detect common errors or omissions in QML code.
  • Delete or fix tests that have been failing forever to increase the signal-to-noise-ratio.
  • Continue moving in the direction of uploading crashes to Sentry rather than making users jump through the hoops of submitting bug reports.

Systematize everything

  • Codify and document the steps required for adequately QAing merge requests.
  • 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.
  • 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.
  • 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.
  • Require that all unit tests in a project pass before merge requests can be merged; tolerate no test regressions!
  • Expand the scope of what KUserFeedback sends for users who have opted in, so that KDE developers can make more decisions based on metrics rather than gut feelings.
  • Unify our release tooling so that we can have one release team with many members that is technically capable and knowledgeable about how to release anything.
  • Encourage apps to join KDE Gear and adopt its version numbering schema, so that they don't have to be self-released.

Rely more on teams and less on individual people's labor

  • 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 a QA team on invent.kde.org that people can volunteer to join. 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.
  • Perform offboarding when you stop contributing to KDE. Don't just vanish without a word!

Risks and needs

Some of these changes are controversial and would require diplomacy and persistence to push past the finish line without upsetting people. Others are technically challenging or complicated and would require buy-in from experienced KDE contributors.

Champion

I'm Nate Graham. From 2018 to 2020, I successfully championed the Usability & Productivity goal, I write the "This week in KDE" blog post series, I'm a member of KDE's Gardening team, and I currently perform bug triage and QA on all new Plasma-aligned bug reports and merge requests. In my day job, I'm a QA Manager at Blue Systems, which is a KDE Patron. In terms of technical contributions, I hack on Elisa and Plasma a lot, but I also do a little bit of everything.

Interest

@ognarb (Carl Schwan)
@niccolove (Niccolò Venerandi)
@aronkvh (Áron Kovács)

There are a very large number of changes, so older changes are hidden. Show Older Changes
ngraham added a comment.EditedJun 25 2022, 1:59 PM

This might seem like unhelpful pedantry, but "KDE" is a community-driven institution, not a desktop, product, or platform. KDE makes a bunch of those, but the goal here is to professionalize the institution itself so that its desktop, other products, and platforms become more professional and consistent in their quality level. I want Plasma to be used as the base desktop for every device on planet Earth, but getting Krita to largely displace Photoshop or Kirigami to become a dominant cross-platform UI toolkit would also be huge wins. All of those products can benefit from professionalization of the institutions backing them, IMO. Krita is actually already much further along in this process then the rest of KDE, so there's a lot we can all learn from them IMO.

ngraham updated the task description. (Show Details)Jun 27 2022, 8:41 PM

For the goal-based crowdfunding scheme, it would be a good idea to hire a UX professional to formulate a coherent design and oversee its execution to completion. Gnome has a guy like that I think. Without this, it will be very hard make a compelling pitch because crowdfunding works by showcasing a "product" and asking "you want this?", at which point your audience hopefully responds with "Shut up and take my money!"

Depending on how much money you have to start, this may be a chicken-egg problem, but it should be possible to acquire the money via a "preliminary" crowdfunding campaign, before you make any multi-million dollar pitch.

The more I think about it, the less I feel crowdfunding like Kickstarter and the like represent a good match for KDE. Most of our projects are already mature and need more regular maintenance, not total redesigns, flashy features, or entirely new apps--which are the sorts of things you pitch to generate excitement on crowdfunding platforms. The idea of this professionalization goal is basically to make the boring work more common and more sustainable. We've already got good coverage on things that are fun and exciting through volunteer contributions.

I think the first step with any hiring expansion is the fundraising director, as otherwise we'll run out of money real fast.

vkhatab added a comment.EditedJun 28 2022, 11:45 PM

Can I be frank here? In the spirit of this thread, suppose you brought in a small team of highly reputable software architects and designers - cause what professional project doesn't need them, correct? - and they told you that KDE is not in fact "mature." This is what Gnome did a while back and they told them that the patient needs major surgery, not a few more bandaids. The Gnome team proceeded to fix the problem by radically pairing down the scope of their projects, because there is only so much volunteers can do well (hence the need for "professionalism"). And it still took them almost a decade to bring what is essentially a "showcase" - by the standards of corporate-backed offerings - up to snuff. (Sidenote: Obviously the comparison to corporate projects is unfair but from an end user PoV it will be made, ditto if we wish to invoke "professial" standards. Can't be helped. You alluded to as much when you said probably tongue in cheek that you want KDE as "base desktop for every device on planet Earth" )

So let's say, for the sake of argument, that this happened. Would this or anything else cause you to change your mind about KDE being "mostly mature"? And if so, would that change your opinion about crowdfunding? Or are there internal institutional constraints that rended such an idea unworkable? That's the real question here.

not total redesigns, flashy features, or entirely new apps

I don't know about some "total" paradigm shift like Gnome 3, but a substantial redesign would a pre-requesite for crowfunding. Entirely new apps would not be required but major changes to the platform and apps would be (so that everything fits together well, like on Mac OS, at least in theory). Flashy features would probably need to be cut back if anything, in order to keep the design coherent and workable. The last point is what I mean when I talk about insitutional constraints. Like let's say the hypothetical team of full-time professionals decides, we need to get rid of desktop cube, activities and per-monitor wallpapers (cause it's still not actually possible to change the wallpaper once for all monitors and login screens on KDE, i.e. it's not possible to change the *desktop* wallpaper in the strict sense of the word). This might lead to a lot drama, maybe even a schism, in the wider community.

This thread of the discussion is becoming a bit off-topic, as IMO we're quite far from the point of hiring professional designers to make major judgments like that.

This goal is also not in any way, shape, or form advocating scaling back the scope of KDE; this goal is about the opposite thing: getting more resources for KDE.

Let's try to keep the focus on goal-related topics. :)

vkhatab added a comment.EditedJun 29 2022, 11:30 AM

Edit: just going to revise this reply to Nate for clarity.

We agree that KDE needs full time professionals to do certain things. But we disagree about the amount of professional work that's required here. Nate thinks that KDE has somehow managed to become "mostly mature" with largely uncoordinated volunteer labor, and hence needs only a couple "professional" bug fixers and one fundraising guy/gal to polish things up.

I don't think that KDE is even remotely "mature" by any industry standard (outside maybe Krita), so I think it needs a lot more than this. And I think the only way to do this is though crowdfunding.

This is a valid dispute for this topic IMO. We could argue who is right or wrong here, but might agree on at least a couple things. First, if KDE is going to bother hiring a full time professional fundraiser, then this person should be able to raise more than just the salaries of one or two "bug fixers." This leads to the question of what to do with the extra money. Second, a professional assessment can't hurt, so why not get - for example - a usability assessment of the project? If KDE is "mostly mature" then it will suggest a few relatively cheap incremental improvements that might not even require a full time fundraiser. But if the scale of the problem is as great as I think it is, then why not try to raise as money as possible (I mean you're already hiring a fundraiser), then actually get a team of full time paid professionals to meet that challenge?

@vkhatab I don't think we really disagree much, and I like your ambition. I think we're very far from the place you're describing, and I'm proposing that we start small. There are rightful concerns about having an adequate budget to support a bunch of paid employees and I think we need to ease into it by hiring people who will generate rapid results. A fundraising director, engineers, and sysadmins can provide that, which I hope will start a self-reinforcing cycle of us being able to justify asking for more donations to support more impactful hiring, people donating more, us hiring more employees, and so on. I'm 100% on board with eventually hiring a UX professional, but I think we're not really in a position to take advantage of such a person yet.

I also think we would need to be careful to hire the right person who's a good cultural match for KDE so that we don't get someone who concludes, "wow, this is a huge mess of confusing options and niche features, you need to get rid of at least half of them and follow in GNOME's footsteps." I believe fairly strongly that if we try that, we'll fail and die, because GNOME already does that successfully and we need to remain differentiated from them and their culture to preserve our reason to exist.

vkhatab added a comment.EditedJul 4 2022, 6:21 PM

Oh yeah, pacing is not an issue. Easing in is fine, as is just not wanting to do it because it would be a pretty big undertaking and a pretty big departure from business as usual (like I wouldn't want the job personally lol).

I was more concerned that we might be disagreeing on principle, because of your claim that KDE is "mostly mature." That had me a little worried ;) But if we define it differently that's fine by me.

right person who's a good cultural match for KDE so that we don't get someone who concludes, "wow, this is a huge mess of confusing options and niche features, you need to get rid of at least half of them"

But you wouldn't want pure "team players" either. Ideally you'd want people who won't sugarcoat the diagnosis - no matter how dire - but then work on solutions that are actually viable given the "culture" and the rest of it. Same as a doctor.

I'd add that having a focused project doesn't mean you end up with the same product as Gnome. Obviously some planning and prioritization is necessary in any project, and that means that means letting go of some things to focus on what's genuinely important. The end result could be different and better for some people, so KDE would still be competitive. If you remember Unity, that desktop was coherent and focused with few bells and whistles, but it was very different from Gnome.

The regrettable aspect of Gnome for many people is that they narrowed the scope of their project too aggressively and then walled themselves off from any criticism. KDE doesn't need to go down that path if it can muster enough resources and maintain an open mind.

PS: Slightly off topic but just an example of the importance of paid professional development. If KDE followed through on the Dynamic Window Decorations idea eight years ago, the Linux desktop would look remarkably better today. But something like that requires too much concerted effort, including outside the project, so it was never done. Something like that can't be done just by volunteers.

ngraham updated the task description. (Show Details)Jul 7 2022, 5:04 PM
logicalwillow added a subscriber: logicalwillow.EditedJul 8 2022, 11:12 PM

Would it be a good idea to have someone make sure the HIG is good and is actually used in KDE apps?

hellokartikey added a subscriber: hellokartikey.

That would be a good idea obviously, with a strong emphasis on the first part.

In general I think we should look at the parts of KDE that are really important but don't tend to get a lot of volunteer labor. Documentation is definitely one of them IMO (with the HIG falling under that umbrella), and I think the board agrees, which is why they hired two documentation contractors last year . For various reasons, it didn't end up working out, but I think the idea was sound. I have some ideas of my own for how we might be able to have more success next time: for example, hire one as a full-time employee rather than two as part-time contractors, and improve oversight of that person's work.

I get all that but it's a good idea to make sure the foundation's in order before piling on more bricks. The sooner the foundation is fixed the the more productive the later efforts will be (unless you think it's already close to perfect).

No, I acknowledge that our HIG's content is old and crusty with parts being inaccurate or outdated, and that KDE developers are not really in the habit of using it as a reference guide due to those issues. Again, I'm 100% on board with the idea of having a paid professional work on this.

Keep in mind that KDE is still a 90%+ volunteer organization and will likely remain that way; there isn't a concept of "halt everything until the foundation is fixed". There is no way to make volunteers stop work until something else is done first or work on different things; you can only try to convince them, which is very very difficult. And there are other critical needs as well, which can go on in parallel with a HIG refurbishment project. So yes, we should update our HIG, and yes, we should hire someone to work on documentation, and also work on the HIG as a part of that. But we don't need to stop everything until that's done, and can't even if we wanted to.

Yeah we agree.

lydia added a subscriber: lydia.Jul 10 2022, 4:05 PM

Just picking out one comment but I think this applies to more of this topic:

"Would it be a good idea to have a professional make sure the HIG is good"

I think we are going down a bad path and are severely undervaluing ourselves if we frame this as professional vs. amateur and equate it to being paid and not paid to work on KDE software. The KDE community has many highly knowledgeable, experienced and professional people. The fact that you are paid or not for contributing to KDE is not related to your skill or professionalism and it should not be.

I thought about that when I wrote the comment but I wasn't sure how to make the comment not sound like that. I've edited my comment to just say "someone". I don't know if that's better, but "professional vs. amateur" isn't what I meant when I said "professional".

ngraham added a comment.EditedJul 10 2022, 4:23 PM

I agree, Lydia.

My goal here is not in any way to denigrate KDE's volunteers (I'm volunteering for KDE right now, it being a weekend), or transform KDE into a soulless corporation, but rather to help amplify what KDE's volunteers are able to accomplish. It's been my observation that KDE's highly knowledgeable, experienced, and professional people have preferences regarding what they prefer to work on when it's a volunteer thing, and this results in other things sometimes being neglected. So one part of this proposal is to focus our hiring activity on the things that volunteers prefer not to do, in general.

But that's only one part of the goal. The other major part is to implement more professional-style systemic and team-based changes, to amplify what KDE's volunteer base is able to accomplish and help attract more volunteers with more diverse skills and interest. For example, I hope that creating and popularizing a formal QA team attracts the attention of people who are picky and detail-oriented who want to help improve the quality of technical contributions before they're merged but currently don't know how. That doesn't require any professional hiring.

vkhatab added a comment.EditedJul 10 2022, 7:57 PM

KDE could of course just hire professionals from the community. The larger point is that in order for professionals to do professional work, it usually helps if they can do the job full time. This is why I think it's necessary to pay some people to do the "fun work", not just the stuff that volunteers don't want to do.

aronkvh updated the task description. (Show Details)Aug 4 2022, 12:40 PM
aronkvh added a subscriber: aronkvh.

I think simply appointing a fundraising director or cultivating a more active fundraising arm may go a long way. It would also create a more reasonable 2-year goal.

jdk awarded a token.Aug 5 2022, 12:42 AM

Generally increasing the quality of our software through more automated testing and QA is a part of what this is all about.

I think simply appointing a fundraising director or cultivating a more active fundraising arm may go a long way.

Personally, I think professionalizing KDE's software quality requires clearer, more rigorous software logic to produce reliable, maintainable software (alongside testing when logical reasoning is tedious or misses bugs), simplifying testing to encourage it and catch more bugs given limited effort, and improving knowledge transfer to new contributors to enable them to correctly modify and extend software.

When writing code, I try to avoid writing bugs by thinking through code (impossible without understanding nearby code, callers/callees, and data invariants), using compiler errors to catch mistakes, or reviewing the code before I push it. Automated testing can catch buggy implementations, and help find edge cases for you to handle in a correct implementation, but needs to be combined with a deliberate effort to write comprehensible and "correct by construction" code if you want maintainable results and not Oracle DB. I find that complex but deterministic logic is hard to verify but possible to "iron out" bugs with testing, but multithreading/concurrency (plasmashell) and complex state management (plasma-systemmonitor instability) is difficult to verify or test, and requires preemption/delay (like rr chaos mode) or thread-affinity fuzzing/testing to discover bugs, injecting sleep() delays to reproduce specific bugs, or Rust's loom to verify specific scenarios are free of inconsistencies. I hope the bugs that escape are caught by peer review, CI servers, or human QA.

Automated testing is well suited as a check to catch bugs introduced when refactoring or modifying code, since you write it once upfront with the code, and it continues to catch bugs for "free" as the code evolves (so you can spend less time tracing code "from first principles" and still catch as many bugs), for as long as the the tests can evolve with the code's changing contract and postconditions. Additionally, simplifying writing tests makes it less unpleasant and possible to catch more bugs with the same effort spent writing tests, and more rewarding/worthwhile to spend time on.

To ensure software remains maintainable over time, I value knowledge transfer (one-to-many architectural documentation and one-on-one question answering), so when you or others come to the code years later, you can more easily (re)build a "theory" of a program in the Peter Naur sense. IMO you need to understand code thoroughly, to work on it (adding features or refactoring) without bodging the architecture or adding bugs. When I've tried to refactor or bugfix foreign codebases like KDE or PipeWire, one major obstacle I've faced is learning how code works; other obstacles include thinking of solutions, or sometimes adapting mountains of code to a new structure. Interestingly, I find that when refactoring code, I often discover muddled logic which sometimes causes user-facing bugs.

However, unfortunately rigorous logic is less useful for identifying good user experience, which requires user-testing implementations and iterating on them to fix flaws (also not through automated testing, but perhaps hiring a testing team can help here).

rwbarat added a subscriber: rwbarat.
marzal added a subscriber: marzal.Aug 6 2022, 8:50 AM

I worry a little bit that this proposal is too much "The KDE e.V. should do $THING", which is something that's not very interactive for the whole KDE community. But I'm also wary of making it more on the side of "volunteers should act more professional" because that doesn't seem reasonable either, and it would be kind of insulting.

Perhaps we need to beef up the "Institute repeatable systematic processes" which is something that the whole KDE community can participate in.

Thoughts?

lydia added a comment.Aug 9 2022, 5:35 PM

I'd very much support this. It addresses a major problem I have with the proposal as it stands. (Happy to jump on a call to bounce off ideas if that'd help you.)

The other problem I see is the title: do we want to talk about "professionalizing KDE" for the next few years in our public communication? I'm not sure we're doing ourselves a favor by portraying the current situation as unprofessional. Maybe we can find a better framing for that? (I don't have a good idea yet.)

I'm happy to field suggestions here, or on a call--whatever folks are more comfortable with!

I can think of many approaches that could possibly improve the quality of our software (more automatic tests, more manual QA, stricter review, using other, more menory-safe languages, just to name a few)

Something that might help this discussion and may be worth doing is a quantitative analysis of the defects we had in our software (i.e. the bug reports) to give us a better understanding of which measures would be the most effective.

A more methodical and scientific approach could really help with this proposal and could avoid investing in ineffective processes or policies

I don't have any formal training in quantitative analysis, but I can tell you from my perspective as KDE's primary bug triager and QA manager in my day job that most of the regressions we ship to users are known in the form of bug reports before being released. What we lack is the ability to reliably translate those bug reports into fixes before the release, or even after the release. It's quite common for the person whose code introduced the regression to not fix it in a timely manner. And so today Plasma 5.25 still has 45 known unfixed regressions from 5.24, 7 of which are classified as "very high" priority. One is even a critical "can't unlock the screen" bug that can cause user data loss due to the need to force-reboot the system. It's been open for over a month.

Another factor is our time-based releases, which lack "shipping blockers" meetings where major known regressions can be discussed from the perspective of whether they should block the release until fixed. We don't even talk about major regressions in our normal weekly meetings; I tried this in the weekly Plasma meetings for a bit but gave up after I got the sense that nobody really cared, and people weren't exactly lining up to volunteer to fix random bugs. :) If we had paid bugfixing engineers, they could be assigned tasks that they were expected to accomplish. But if we're not going to do that, we really need a mindset shift in KDE so that people feel more responsible for regressions they cause, they pay attention to Bugzilla, they're more responsive to email, they don't randomly stop responding to conversations they're participating in, they reserve time for reviewing merge requests in repos they care about, they actually test those merge requests instead of just doing code review, and so on.

But is it possible to have this without making KDE seem like a job? In recognition that most KDE contributors are volunteers, I think we can't do anything that makes it feel too much like work. That was originally why I proposed farming out a lot of the "worky" stuff to paid employees. If we're not going to make that a part of this goal, I think we'll have to be careful that we don't add enough bureaucracy and rules that KDE stops being fun for volunteers.

I'm open to ideas on how we can thread that needle.

I feel " unlock earning potential from our ecosystem" can be part of this goal.

See also: https://discourse.gnome.org/t/evolving-a-strategy-for-2022-and-beyond/9759

Initiative 2: Diverse and sustainable Linux app ecosystem. I spoke at the Linux App Summit about the work that GNOME and Endless has been supporting in Flathub, but this is an example of something which has a great overlap between commercial, technical and mission-based advantages. The key goal here is to improve the financial sustainability of participating in our community, which in turn has an impact on the diversity of who we can expect to afford to enter and remain in our community. We believe the existence of this is critically important for individual developers and contributors to unlock earning potential from our ecosystem, through donations or app sales. In turn, a healthy app ecosystem also improves the usefulness of the Linux desktop as a whole for potential users. We believe that we can build a case for commercial vendors in the space to join an advisory board alongside with GNOME, KDE, etc to input into the governance and contribute to the costs of growing Flathub.

adam added a subscriber: adam.Aug 21 2022, 6:16 PM

Notes from the refinement session:

We talked about this proposal and all the comments are already reflected in the discussion that is ongoing.

adam added a comment.Aug 21 2022, 6:50 PM

The voting starts in a week, if you plan to update the proposal it is best to do it soon. @ngraham do you feel that the proposal right now is how you want it to be before voting or are you still working on it?

Generally I appreciate and agree with the sentiment of this goal. However, there are some parts that could be improved, starting with the title.

"professional" is a somewhat ambiguous term. In its literal sense it means "it's my profession/job do to this". Getting people to work professionally on, i.e. get people paid to work on KDE software is certainly a worthwhile thing to achieve. However, as has been pointed out before, the question of "Can/should the KDE e.V. pay people to hack on KDE Software" is mostly a KDE e.V. question and not something that the community at large can do much work on. Perhaps it makes sense to ignore that part for the scope of this goal and focus on the other meaning of "professional" instead.

That other meaning would roughly be "of good quality". In this particular context we could also talk about a "engineering discipline". From my experience working in the industry I can tell you that getting paid to do something by no means implies that the work is done well or with good engineering discipline. In some ways we are miles ahead of what the industry does in terms of software engineering discipline. In others we are not. There is certainly lots of room for improvements in this regard, but we also have to keep in mind that KDE (or community-driven FOSS projects in general) are very different to industrial software engineering, and what works in one doesn't necessarily work in the other.

In a nutshell, I very much agree with rephrasing it as "Institute repeatable systematic processes" instead of the ambiguous term of "professionalism"

Create a QA team on invent.kde.org that people can volunteer to join. Encourage projects to make use of the QA team by requiring that nontrivial merge requests have a QA approval before being merged.

Getting more people to do QA work is certainly good, but what matters is what those people end up doing. Different people do QA in different ways with varying degrees of thoroughness. Perhaps we should add some more structure to the QA process so that people know what they are expected to do when performing a QA review. A list of "things to check" like "When making a change in component A we need to check whether X, Y, and Z still work" could go a long way. Of course in an ideal world all of the testing would be automated, but that's not going to happen anytime soon, so having a sort of standard test checklist that a developer or QA person can replicate manually could be valuable.

Create even more teams; one per project! Encourage people to join a project's team when they contribute to that project. Contributing to KDE should feel like being a member of a group, not an individual feeding inputs into a giant machine.

I'm not sure what specifically you are referring to with "team". Do you mean teams as in https://invent.kde.org/teams? What would be the benefit of having e.g. a "Kate" team in addition to the Kate repository?

When talking about adding stricter processes we need to also consider that KDE has a very diverse set of subprojects with varying levels of activity and different requirements. We have projects with a very high number of regular contributors and activity, such as Plasma or Krita. But then we also have projects with only very few or no regular contributors where it can be hard to even find someone to review or test your code. We need to make sure that rules imposed for the requirements of one project don't negatively impact other projects.

Generally I appreciate and agree with the sentiment of this goal. However, there are some parts that could be improved, starting with the title.

"professional" is a somewhat ambiguous term. In its literal sense it means "it's my profession/job do to this". Getting people to work professionally on, i.e. get people paid to work on KDE software is certainly a worthwhile thing to achieve. However, as has been pointed out before, the question of "Can/should the KDE e.V. pay people to hack on KDE Software" is mostly a KDE e.V. question and not something that the community at large can do much work on. Perhaps it makes sense to ignore that part for the scope of this goal and focus on the other meaning of "professional" instead.

That other meaning would roughly be "of good quality". In this particular context we could also talk about a "engineering discipline". From my experience working in the industry I can tell you that getting paid to do something by no means implies that the work is done well or with good engineering discipline. In some ways we are miles ahead of what the industry does in terms of software engineering discipline. In others we are not. There is certainly lots of room for improvements in this regard, but we also have to keep in mind that KDE (or community-driven FOSS projects in general) are very different to industrial software engineering, and what works in one doesn't necessarily work in the other.

In a nutshell, I very much agree with rephrasing it as "Institute repeatable systematic processes" instead of the ambiguous term of "professionalism"

Yeah, I think this is probably a good path forward and I appreciate the idea. I'll edit the proposal.

Create a QA team on invent.kde.org that people can volunteer to join. Encourage projects to make use of the QA team by requiring that nontrivial merge requests have a QA approval before being merged.

Getting more people to do QA work is certainly good, but what matters is what those people end up doing. Different people do QA in different ways with varying degrees of thoroughness. Perhaps we should add some more structure to the QA process so that people know what they are expected to do when performing a QA review. A list of "things to check" like "When making a change in component A we need to check whether X, Y, and Z still work" could go a long way. Of course in an ideal world all of the testing would be automated, but that's not going to happen anytime soon, so having a sort of standard test checklist that a developer or QA person can replicate manually could be valuable.

This is a good point. We already have some documentation at https://community.kde.org/Infrastructure/GitLab#Perform_QA but it is quite rudimentary and in need of improvement. This can be a goal task. :)

Create even more teams; one per project! Encourage people to join a project's team when they contribute to that project. Contributing to KDE should feel like being a member of a group, not an individual feeding inputs into a giant machine.

I'm not sure what specifically you are referring to with "team". Do you mean teams as in https://invent.kde.org/teams? What would be the benefit of having e.g. a "Kate" team in addition to the Kate repository?

I had envisioned a team on Invent, yeah. The benefit would primary accrue to projects that are split across more than one repo (Plasma, PIM, Systrem Settings, etc), and teams that are not inherently tied to repos (VDG, QA, Localization, Usability, etc). The idea here is to get us in the habig of addressing and pinging teams rather than people, because people come and go and may not be personally known to everyone.

When talking about adding stricter processes we need to also consider that KDE has a very diverse set of subprojects with varying levels of activity and different requirements. We have projects with a very high number of regular contributors and activity, such as Plasma or Krita. But then we also have projects with only very few or no regular contributors where it can be hard to even find someone to review or test your code. We need to make sure that rules imposed for the requirements of one project don't negatively impact other projects.

Right, the idea is not to add layers of bureaucracy. On the contrary, I envision more testing, QA, and bug triaging being automated such that smaller projects aren't so negatively impacted by having very little regular contribution

ngraham renamed this task from Professionalized KDE to Automate and systematize our processes.Aug 23 2022, 4:32 PM
ngraham updated the task description. (Show Details)

@nicolasfella @lydia what do you think about the updated proposal?

lydia added a comment.Aug 23 2022, 5:46 PM

I really like it! Thanks a lot for updating it.

I'm wondering if we can make the title a bit more exciting still. Random thoughts to build upon: taking KDE's software and community to the next level by automating and systematizing our processes (not super happy with that yet...)

Perhaps "Automate all the boring things" would make for a more catchy title. It doesn't reflect the full scope of this proposal though

ngraham updated the task description. (Show Details)Aug 25 2022, 5:43 AM
ngraham renamed this task from Automate and systematize our processes to Make our internal processes more automatic and more team-based.Aug 25 2022, 8:23 AM
ngraham updated the task description. (Show Details)

I'm not sure "team-based" is a good term to have as part of the title. It don't see it carrying much meaning or it being central to the proposal

Another potential item that came to my mind, given some recent emails:

Institute a process to ensure all active projects have regular releases, and inactive projects are marked as such/archived

Move clang-format from a git hookscript to pre-commit CI so that merge requests will show a CI failure when badly-formatted changes exist, and people can see this in a nice UI and fix them

This is a bit problematic. clang-format output isn't 100% consistent across different clang-format versions, so if CI has a different clang-format than you there will be pain

Add CI checks for missing i18n() context markers and text.

I'm not sure whether the assumption that every i18n should have context is true

Continue moving in the direction of uploading crashes to Sentry rather than making users jump through the hoops of submitting bug reports.

While I'm optimistic that Sentry will be helpful with getting better backtraces with debug symbols we can't really do without proper bugreports though. Sentry reports do not provide any context for how the crash occured, which is often crucial for understanding the issues. We will have to find a way for both Sentry and Bugzilla to work together for the optimal experience

ngraham renamed this task from Make our internal processes more automatic and more team-based to Automate and systematize internal processes.Aug 27 2022, 9:16 PM
ngraham updated the task description. (Show Details)
bcooksley changed the edit policy from "All Users" to "Goal Setting 2022 (Project)".Sep 1 2022, 6:52 PM

I'd very much support this. It addresses a major problem I have with the proposal as it stands. (Happy to jump on a call to bounce off ideas if that'd help you.)

The other problem I see is the title: do we want to talk about "professionalizing KDE" for the next few years in our public communication? I'm not sure we're doing ourselves a favor by portraying the current situation as unprofessional. Maybe we can find a better framing for that? (I don't have a good idea yet.)

But KDE is plainly not a professional endeavor - it's a volunteer project and the final product reflects this. It should be possible to take pride in one's work without denying reality. In fact, setting an impossible standard will only rob you of any genuine sense of accomplishment.

I am disappointed that this goal got completely rewritten and turned into yet another usual recipe for an administrative-technical fix. You guys are regressing back to the idea that volunteer labor can produce the same results as professional work if only you work a little smarter, faster, harder, longer etc. It's the same type of thinking that produced "the year of the linux desktop." But this is fundamentally unattainable because these two types of labor are qualitatively different. There should be room for both types of contributions. Together, they could lead to a very potent synergy that might even surpass purely "professional" proprietary projects on many levels.

Personally I agree with you, it's just that these goals have to be actionable at the community level. Professionalization involving more paid employees, a formal management chain, etc. are all things that basically have to be done by the KDE e.V.; there's little an individual member of the community can do about it. So by removing those elements, the goal became actionable. Given how popular those elements seemed to be, I still plan to pursue the professionalization idea from another angle.

OK, that makes sense.

mart awarded a token.Sep 9 2022, 8:34 AM
mart added a subscriber: mart.