KDE has now started its fifth round of “goal-setting” — a process that began in 2017.
These goals are big, high-level goals. Think “focus on large strategic topic X” more so than “fix my pet bugs A, B, and C”.
And it’s up to the KDE community to choose the goals! Up to you, up to me, up to all of us. They will then be voted on, with the top three informing KDE’s overall direction for the next two years.
KDE needs you! Your fresh ideas, your contributions, your budding leadership talent. But not your imposter-syndrome-driven fear of coming out of your shell. 🙂 Overcome that!
I’ve now been the champion for two goals: “Usability & Productivity” and “Automate & Systematize Internal Processes“. I’d count the first as pretty successful; the second, less so. So at this point I feel like I have a pretty good idea of what works and what doesn’t, and I’d like to use that knowledge to help others submit their own high-quality actionable goals.
Here’s what works, in my experience:
- Articulate an immediately obvious large problem or aspiration. If you’ve spent any time in KDE or using KDE software, you’ll have encountered stuff that sucks. Big stuff. That’s the topic to write a goal around! Not “Discover is too slow to refresh when I launch it” but rather “First-class software delivery UX” (you can steal that).
- Have a technical lead and a communications lead. They can be different people, but you need both. Only have a tech lead? Not enough communication, people forget about it, don’t join, and the tech lead burns out. Only have a comms lead? Not enough work happens and the goal limps embarrassingly towards the finish line.
- If you propose a goal, be the tech lead. You can be the comms lead too. But you should be prepared to be the tech lead. It’s much easier to recruit people to do other things than it is to recruit a tech lead to do a ton of work on your behalf that you can’t to yourself.
- Don’t bite off more than you can chew. If you can’t be the tech lead on your idea, scale it back or change its scope so that you can be the tech lead. This doesn’t mean you have to know how to do everything. It just means you can do a big chunk of the technical work, and at least understand the concepts of the things you can’t personally do.
It’s really fun, and you end up having a huge impact on how awesome KDE is.
I’ve submitted a goal proposal about improving KDE’s documentation. Credible choices make voting useful, but right now we have as many submissions as goal slots, and that’s no fun. So get yours in too!