We’ve got some really big things planned and in progress for Plasma 5.18 and Frameworks, and work proceeds smoothly. None of it is quite done yet, but we did land a number of nice bugfixes and user interface polish for issues that have been irritating people for years…and mere days! Have a look:
Do you like to categorize things? So do I! Then why not try your hand at triaging bugs? KDE’s faithful users file about 25 of them every day, and they all need to be looked at, categorized, moved to the correct products, marked appropriately, closed if the issue has already been fixed–in short, triaged. It’s fun and easy and can be done in 5-minute spurts during boring periods of the day. Triaging bugs is a super helpful way to relieve some of the developers’ burdens if you’re not a developer yourself–developers vastly prefer writing code and fixing bugs to triaging them! For more information, check out https://community.kde.org/Guidelines_and_HOWTOs/Bug_triaging!
More generally, have a look at https://community.kde.org/Get_Involved and find out more ways to help be part of a project that really matters. Each contributor makes a huge difference in KDE; you are not a number or a cog in a machine! You don’t have to already be a programmer, either. I wasn’t when I got started. Try it, you’ll like it! We don’t bite!
Patch review is a process by which newcomers and experts debate proposed changes to a codebase–a textual description of how a particular human-created system is to function. In KDE, we use Phabricator for this, but we’re switching to GitLab soon. Both serve the same purpose: to provide a forum where proposed changes can be discussed, revised, and decided upon.
It occurred to me recently that this sounds a bit like the process of lawmaking. Politicians propose bills (patches) that amend their government’s code of laws (codebase) which are passed through committees and hearings (the review process) and eventually get voted on (reviewed) and either pass (get merged) or require revision (go around for updates), or fail (get abandoned).
Pictured: typical 18th-century patch review process
I’m reasonably confident that there’s little overlap between politicians and software enthusiasts. In my home country of the USA for example, most of our federal government politicians are former lawyers, businesspeople, or educators. “Software engineer” is listed as a “more unusual” former profession.
This strikes me as a shame, since the process of transforming a proposal for improvement on a systemic scale into a permanent alteration of the rules that affects everyone is quite unfamiliar to lawyers, businesspeople, and educators, but it’s quite natural so software people. We do it every day. Likewise, software people like us tend to have little experience in the lawmaking process. We act like we invented patch review, but our governments have been doing it for hundreds of years! The overlap got me thinking: perhaps there is something that each group can learn from one another.
Have a constitution
Governments write constitutions to make their foundational principles clear and obvious. That way, everybody knows which ideas are central to the society’s identity, which which ones are off-limits.
Lesson for software engineers: Make your software’s guiding principles, explicit, not implicit. People often figure this out organically, but it’s much easier if your software has a constitution-like document and clearly indicates which features are non-negotiable when it comes to proposing their implementation or removal.
Don’t neglect trust
If you have a bad relationship with the people reviewing your patch, they will suspect your motives, nitpick your changes, and generally react with low enthusiasm. Even if your patch is a good one, the reviewers’ opinion of it will be clouded by their judgment of you. Therefore, don’t neglect your social relationships and act like a jerk, or else the whole process basically doesn’t work.
Lesson for politicians: don’t ignore or damage your social relationships with your colleagues or else your entire job is a big waste of time. Adopt a mindset that legislation is a collaboration rather than a majority-rules deathmatch or an opportunity to make speeches on a stage. Also, arrive with pure motives. If you’re there to try to tilt the playing field towards your favored groups, the people who represent the opposite side will notice and oppose you at every turn, and you’re likely to have a frustrating and unproductive career full of outrage-filled press conferences but not much real accomplishment.
Review in stages
In governments, often bills undergo review by multiple committed before they’re presented to the full body for debate and voting. This is good, because it gives a chance for obvious mistakes to be corrected in advance of the final vote.
Lesson for software engineers: use a multi-step patch review process, with relevant experts in control at each step of the way. For example, the big-picture software architects should review a patch for to make sure it conceptually makes sense in the first place; then backend programmers should dive into its technical implementation; the UI designers should go over its user interface, and so on.
Keep patches small
Large patches are hard to review and fill the reviewers with a sense of dread. They touch many things and therefore have more opportunities to change something in a way that a stakeholder will object to. They often get bogged down in process and conceptual arguments. For these reasons, it’s best to keep patches small and focused, and split a large change into a series of individually-manageable patches that each depend on one another, known as a dependency chain.
Lesson for politicians: avoid 1,000 page mega-bills. If a bill needs to be enormous in order to work, there’s probably a deeper conceptual issue with it that everyone senses.
Have an institutional memory
Records of how bills are moved along in the lawmaking process are kept meticulously. This preserves institutional memory, so that newcomers don’t make the same mistakes that their older colleagues and forefathers already learned from.
Lesson for software engineers: Keep records of why decisions were made–and even more importantly, why they were reverted. This prevents the phenomenon of newcomers who propose the same changes and repeat the commit/regress/revert cycle.
Make reversion easy
When a patch causes regressions, it can be reverted. Oftentimes it’s better to fix it, but if the fixes are too invasive or the regressions outnumber the benefits, it may be a better idea to revert the change and try again. Making reversion easy promotes a culture of innovation and experimentation. People won’t be as worried about merging things, because if they cause problems, it’s easy to undo the changes. Change becomes playful and fun, rather than consequential and scary.
Lesson for politicians: Don’t make it too hard to repeal bad laws. When a newly-passed law causes problems in a society, it’s tempting to try to amend it to fix the problems, and sometimes this works. But sometimes it just needs to be re-done from scratch, like a bad patch in software. Being willing to repeal laws that aren’t working defuses tension. That said…
Don’t rush
Bills and patches that get through their processes quickly are often problematic, riddled with unseen regressions and unanticipated consequences. This is much less common in governments, because the lawmaking process usually has deliberate safeguards put in place to ensure that a bill is not transformed into a law too quickly before there’s been adequate time for debate.
Lesson for software engineers: Take your time so you don’t push out buggy, regression-filled software. However…
Don’t make your users live on the master branch
Rushing isn’t such a huge deal as long as you have a QA process and discrete releases. These tools provide time for regressions to be fixed and rough edges to be smoothed out. When patches can be evaluated in a safe sandbox of sorts and subsequently tweaked before their effects are released to users, it’s not so bad to move quickly. But you can’t expose your users to the churn stirred up by a fast process; it needs to be contained internally.
Lesson for politicians: You don’t need so much process surrounding lawmaking if you don’t roll out all approved changes immediately. Before new bills take effect, let them simmer for a while in a “release branch” where they can undergo QA so that regressions can be found before they’re inflicted on unsuspected citizens (users)!
As software people, there are lessons we can take from our governments’ successes (and more often these days it seems, their failures), because this aspect of our professions overlaps quite a bit. It also exposes an uncomfortable truth: changing the rules and behaviors of a system that effects everyone is inherently political. That’s why we invented patch review processes: to make sure that important voices are heard, that the system doesn’t become inhumane for people who depend on it, and that its overall trajectory is positive.
Personally I’m a lot more sanguine about the prospect of this in software than government right now, and I think that’s something that needs to change. The efficacy and positive societal impacts of our governments’ lawmaking seems to be at a bit of an ebb at this moment in time. But there may come a point in time when our experience in patch review becomes useful on a larger stage, and benefits not only users of KDE software, but also the people of the world. We shouldn’t shy away from politics. Our everyday experiences in KDE are in fact the prefect preparation! Far from being distant and scary, it’s something we’re engaging in–and succeeding at–every time we contribute to KDE.
Something cool this way comes… easy Emoji input! Speaking personally, lack of easy Emoji input on Plasma has been irritation for years. But no longer! Plasma now has a built-in Emoji chooser similar to the ones on other competing operating systems. Ours is invoked with the Meta+period keyboard shortcut.
Here it is:
Let’s give a big hand to to Aleix Pol Gonzalez for implementing this! It’ll be available in Plasma 5.18, and in the meantime we’re going to continue to improve its polish, integration, and discoverability.
Ar you good at web design? KDE has approximately five hundred million (okay, slight exaggeration) websites in need of visual refreshing and technical improvement! Our web team is desperately overworked and in need of help–yours, perhaps. 🙂 Each individual person who joins in will be making a humongous difference! If this sounds like your cup of tea, check out https://community.kde.org/KDE.org
More generally, have a look at https://community.kde.org/Get_Involved and find out more ways to help be part of a project that really matters. Each contributor makes a huge difference in KDE; you are not a number or a cog in a machine! You don’t have to already be a programmer, either. I wasn’t when I got started. Try it, you’ll like it! We don’t bite!
I’ve got big news today. Something major landed: full support for the GTK_FRAME_EXTENTS_ protocol, which hugely improves the user experience for running GTK apps that use client-side decoration headerbars! This includes GNOME apps and an increasing number of 3rd-party GTK apps too. In particular, these apps now display window shadows and have proper resize areas without needing to use a thick border. Here’s how Gedit now looks:
It’s almost native-looking! And it fits right in with the rest of your apps.
I’d like to extend a big thanks for Vlad Zahorodnii who has been working hard on this for months! The feature lands in the upcoming Plasma 5.18 LTS.
Do you love KDE’s apps? Would you like to help develop for them? I knew you would. 🙂 It’s really fun, and you can have a major impact. Many of KDE’s apps are quite beginner-friendly; among them are Dolphin, Elisa, and Spectacle. See the full list here! These apps’ maintainers as well as KDE’s experienced developers are happy to help and mentor newcomers who want to contribute. For more information on how to get help and who to ask, see https://community.kde.org/Get_Involved#Start_Here.21
More generally, have a look at https://community.kde.org/Get_Involved and find out more ways to help be part of a project that really matters. Each contributor makes a huge difference in KDE; you are not a number or a cog in a machine! You don’t have to already be a programmer, either. I wasn’t when I got started. Try it, you’ll like it! We don’t bite!
We’re nearing the release of the 19.12 versions of many KDE apps, and in the first third of the Plasma 5.18 cycle. With this week, all the major regressions from 5.17 that I’ve been tracking have gotten fixed! If you’re still suffering from other 5.17 regressions not listed here and not yet fixed, please let me know. We want to make sure that the 5.18 LTS release is as smooth and stable as possible.
The list of applications and system services in the System Settings Notifications page now has full keyboard navigation (me: Nate Graham, Plasma 5.17.4)
The KDE Frameworks 6 sprint is happeningright now! Much work and planning for the future is being done. Alas, in just three days, all the work will not get done. This is where you can help! The KF6 workboard is chock full of small, manageable to-do items just begging for someone to knock a few out. Maybe you? 😉
More generally, have a look at https://community.kde.org/Get_Involved and find out more ways to help be part of a project that really matters. Each contributor makes a huge difference in KDE; you are not a number or a cog in a machine! You don’t have to already be a programmer, either. I wasn’t when I got started. Try it, you’ll like it! We don’t bite!
There are some neat things to report and I think you will enjoy them! In particular, I think folks are really going to like the improvements to GNOME/GTK app integration and two sets of touch- and scrolling-related improvements to Okular and the Kickoff Application Launcher, detailed below:
When scrolling in Okular with the mouse, touchscreen, or keyboard keys, the scroll transitions are now animated and have inertia. I find this to be a huge improvement for reading documents with a convertible laptop! (Kezi Olio, Okular 1.10.0)
Do you like icons? Of course you do! But more importantly, are you interested in helping to make them? I bet you are! And you should be, because there’s lots to do! Luckily, it’s actually really easy, and we have a page in the Human Interface Guidelines that describes the rules to help guide you along. Icons in the Breeze icon theme are vector SVG files, and we use Inkscape to make and edit them. I started doing it recently with no prior experience whatsoever in either icon design or the Inkscape program. My work was crude, but VDG members very gently and patiently helped me along, and you can do it too! Here’s how: https://community.kde.org/Guidelines_and_HOWTOs/Submit_an_icon
More generally, have a look at https://community.kde.org/Get_Involved and find out more ways to help be part of a project that really matters. Each contributor makes a huge difference in KDE; you are not a number or a cog in a machine! You don’t have to already be a programmer, either. I wasn’t when I got started. Try it, you’ll like it! We don’t bite!
We’re mid-cycle in Plasma 5.17 and still working hard to fix bugs and regressions, while planning for Plasma 5.18, our next LTS release! There’s also been continued work on our apps. Check it out:
Qt 6 is around the corner! …And everything will need to be ported to use it. But don’t worry, the 5 -> 6 transition promises to be a relatively smooth one thanks to the Qt folks working hard on compatibility and us having already started the work of porting our software away from deprecated APIs. on that subject, it’s a great way to help out if you’re into backend work and appreciate a clean codebase. Check out the Phabricator workboard for the KF6 transition to learn more!
More generally, have a look at https://community.kde.org/Get_Involved and find out more ways to help be part of a project that really matters. Each contributor makes a huge difference in KDE; you are not a number or a cog in a machine! You don’t have to already be a programmer, either. I wasn’t when I got started. Try it, you’ll like it! We don’t bite!
