The Plasma team is meeting in Barcelona, Spain these days to work on the next major version of KDE’s popular workspaces. As we are in a transition period, technically and organisationally, this is a very important meeting. I won’t go into too many details in this post, as they are still being fleshed out, but to give you an idea what we are talking about, here’s a quick run-down of some of the things we talked about.
Process & Transpareny
We do not have firm technical results, we are sharing the proposals we come up with here in the meeting on the Plasma mailinglist for feedback first. This is a change we are making in our development and decision-making process. In the past, we sometimes got the feedback that the Plasma team as a group appears a bit too exclusive to the outside. This stands in contrast to its architectural position. One of the things that make it very interesting to work on Plasma is the scope. This scope is usually work on the workspace UI, and of a specific technology. User interfaces don’t stand on themselves, but they express something and allow access. Examples are hardware integration, where issues like powermanagement, device management, etc. have to be presented in the workspace in a way that first of all makes sense technically, but that also is consistent with the way other “things” are presented, and that is beautiful and engaging with the user, while getting out of the way of doing real work. This is a thin line to walk, and in order to achieve great results, it needs close involvement from all sides.
Related to this is the transparency in decision-making processes. Some people have complained that decisions have been made inside a tight group, and that they don’t feel to be part of this process. This stands in the way of team growth (and no growth means shrinking), making it hard to maintain a high level of quality on the one hand, and on the other hand to improve existing functionality and develop new features. We want to change this. Of course this must not stand in the way of firm direction, but the responsibility has to be shared by more people, meaning that not one person is seen as responsible for more controversial changes, but we as a team stand behind it. This reduces stress on individuals, and leads to a fairer distribution of also the negative sides of responsibility.
Lately, we’ve been struggling with an unwelcoming atmosphere in the Plasma communication channels. We’ve talked about this issue, and everybody present agreed that in order to keep our working environment pleasant, we have to be more friendly and respectful to each other. It’s totally not acceptable to lash out against each other, or to answer emails in condescending ways, to talk to people assuming they’ve bad intentions or anything like that. We need to rebuild some mutual trust, but we also need to step in when things threaten to escalate. As an in-person meeting is a good opportunity to talk about these issues in person, this was an important topic. My personal feeling is that we have reestablished strong standards, and everybody is on the same page and willing to defend this newly found balance. We all share the same goals, and we want our working environment to be friendly and enjoyable, as this forms the baseline for being productive and achieving great results as a team.
Drinking from the firehose
Finally, another topic was the situation of Plasma issues in KDE’s Bugzilla. We have a lot of bugs, and are currently lacking the resources to handle this stream of incoming bugs. We do need to do something about this, since it’s an important tool for support and to increase the quality of our codebase, and in extension the user experience. This means that we will, for the technological transitions deprecate a number of bugs of which we know fairly certainly that they do not apply in Plasma 2 anymore. We’ll also draw clearer boundaries around components supported by the core team (essential functionality), and community-supported addons. This means that we will be able to categorize and prioritize better, and hopefully get a grip on the rather messy situation in our issue tracker. Right now, trying to make sense of the issue reports for Plasma very much feels like this:
On the design side, we’ve started on visual guidelines. This is a tool for us to achieve greater beauty and consistency across the components. Plasma 1 feels, in some places, like a collection of individual, separate components. This is of course true, and it has specifically and purposefully designed like that — it’s a good thing technically, but the architecture should not bleed into the visual appearance. We’ve done a lot of work to ensure visual consistency in our components, and we’d like to take this to the next level. For this reason, we’ve worked on visual design guidelines. We’ve taken the new Plasma calendar as a starting point, since that resonated very well with the community, and with professional designers, and we started to extract guidelines that are commonly applicable also to other parts. This is about usage of fonts, spacing and alignment. On the technical side of this, Digia’s Mitch Curtis, who works on the calendar components in QtQuick Components has joined us for a day of design, planning and hacking, so we have some really nice collaboration going on there as well.