multihead saga continues

I received no testing feedback from my last blog entry about multihead improvements for Plasma Desktop, which underscores the challenges we face with multihead support very nicely.

In any case, today I went through plasma-desktop and moved all the relevant code over to the new solution and committed all the changes to trunk. In theory this should improve plasma-desktop on multihead even further, with things like moving panels around with the mouse working as expected and what not.

Again: in theory, and I can't stress that enough. For those of us without multihead, the changes make zero difference as in the non-multihead case they are just small detours in the code that lead to the exact same calls that were being made previously, so there is quite literally no way of testing this beyond "Hey, it compiles, let's commit that." To know what the impacts are, we need people testing this.

These changes will not be a part of the 4.6beta1 release, but they should be part of beta2. Please install and test that if you have multihead and let me know how it goes.

Read More

20 years ago, a story

(Note: This is not KDE or F/OSS related in the least, but rather a personal reflection on a musical work that I find a lot of meaning in and which I realized only tonight was experiencing its 20th anniversary. Feel free to skip this one, but I felt compelled to write about it. :)

In 1990, an amazing piece of modern art was being created out of the ashes of grief. What made it beautiful was not only the qualities of the finished work, but what inspired it and drove its creation. A landmark in the art of the generation, it became a punctuating moment, an ellipsis between what was and what was coming.

In that year, two young musicians were sharing an apartment in the city, which is in itself a completely unremarkable event. They were both front men for local bands who were starting to enjoy touring successes. As friends and roommates, these creative minds shared the journey of finding a way to make a living doing what they loved. At the end of winter, in March, their paths separated dramatically.

One of them had become addicted to the musician's drug de jour: heroin. On the very day that his roommate returned from a road tour with his band, he died of an accidental overdose. Such losses of creative souls to the drug was becoming a disturbing trend, and this was just one more ugly notch in its belt.

The surviving roommate was set to leave again and go back out on tour in just a few days. With the black cloud of his friend's death following him while on tour, he turned to what he knew in search of solace and wrote two powerful songs in memory of his friend. When he returned home, he approached the bandmates of the deceased and suggested they record and release those two songs as a tribute, and perhaps even find some closure in the process. The idea grew and they started writing more songs together, eventually producing an entire album's worth of material: ten songs in all, each amazing. What a fantastic way to deal with such a horrible experience: to create something beautiful and lasting, something that caries meaning and memory, that heals as it commemorates.

While creating the album and its material, the now singer-less band went in search of a replacement and along with it a sense of new direction. They found a rather amazing person to fill those shoes before the tribute album was complete. In fact, he (famously) joined in on back-up vocals on some of the recording sessions and sung co-lead on one song on the album. It was, in retrospect, such a perfectly seamless bridge over such troubled waters.

They released the tribute album in the spring of the next year and went on their separate creative paths. Both bands recorded new albums, toured extensively and rose to fame, fortune and acclaim in the process. The band with the new lead singer would rise meteorically, in fact, and crank out album after album of songs about human passage with great success, even though they often did so in a manner that was stubbornly industry-uncooperative. They also created one of the most enduring, large and active fan clubs for a band in recent times. The roommate's band would also become a house hold name, thought it would take them a few more years to do so before eventually breaking up, after which the singer carved out a successful solo career.

It was their musical successes of the early 90s that ended up bringing their tribute album, and with it the story and memory of their friend, into the limelight. After their breakthrough debut album, people wanted more and they found it in this obscure piece of work that had been released earlier the same year.

The tribute album definitely stands on its own merits, however: the inspiration and energy can be experienced in every word and every note. They had erected it as a doorway through their grief, and on the other side success fueled by their profound musical expression was to be found.

Perhaps it sounds like a movie script or a plot from a novel, but this is precisely makes it so amazing: it actually happened just like that. The creative dominoes that led to a great piece of modern art were tipped, and now it sits there for any one to find and listen to twenty years later.

In fact, I still find inspiration in the music and what it communicates even though I've listened to it countless times. For me it is a testament to the healing that can be found in a creative endeavor. It also serves as tangible evidence that fantastic yet true stories are unfolding in this world around us, probably far more often than we expect. It is so easy to become jaded and to start thinking that such events only exist as the products of our imagination, floating about in the words and images and sounds of art. But these events are as real as they are profound. They underwrite our musings, forge our imaginations and are the bedrock upon which we lay our art.

They are not just products of our creation, but cause us to produce great things.

Read More

KDE and web developers

KDE contributors are typically not web application people. Most of us can create something resembling a web app when push comes to shove, and we have some shining exceptions to this in our community such as the stellar KDE Forums, the ever improving kde.org family of sites, identity.kde.org and the increasingly useful, but sadly still powered by a proprietary code base, OpenDesktop.org.

(The OpenDekstop.org situation is something I truly struggle with given my personal ethics with regards to Free software and what I feel KDE stands for. The people involved know this and have their reasons, which I don't agree with (for what it's worth), for the current state of things. This is not what I want to write about here, but I am not comfortable with appearing to be in tacit approval of the state of that.)

What I want to discuss is the open-ended question of: "Can the KDE community grow to also encompass a web development component?"

What do I mean by a "web development component"? Well, increasingly our applications use services, but not all services we'd probably find useful are available out there randomly on the web. For instance, I'd love a way to manage the queue of user contributed data addons (scripted Plasmoids for Plasma Desktop, widow manager scripts for KWin, puzzles for Palepeli, routes for Marble, etc.) before they are set to appear in the "Get Hot New Stuff" user interface.

Then there's the issue of "things that would make KDE function more efficiently", such as a development sprint manager. Right now we use a wiki and lots and lots of copy and pasting, manual editing and pestering of people to plan and run a developer sprint. My dream solution would be a simple bespoke web application that uses identity.kde.org for authentication and provides a set of forms for someone to start the process of setting up a developer sprint (KDE e.V. board could even get an automated email notifying them of this), allowing people to register their interest in attending (a single simple form plus their identity.kde.org account should suffice) and provide a simple web form to record the results of the sprint for use in Dot stories and KDE e.V. quarterly reports. Back when we did a handful of sprints a year, it wasn't a big deal to do all this "by hand", but now that were doing dozens every year it's getting to the point that some level of standardization and automation would be most welcome. The process is pretty well documented on commuity.kde.org these days, it "just" needs to be made into a web app.

Unfortunately for us, I don't see any external web application project whipping up such a thing on their own. We're one of the few F/OSS communities that drives so much development through such sprints month after month, so the audience for the app is fairly limited, though I do believe we're starting to see more F/OSS communities picking up a similar model that would also benefit from such software.

I also don't believe that it is reasonable to expect these works to spring up out of the web-developer-poor soil of the current KDE community. What web focused people we have are already amazingly busy doing really important things.

Then I look at communities in KDE like KDE Games or KDE Edu. These are tight knit bands of developers who work on very specific topics and who have their own home grown sets of expertise. Is it beyond imagination that one or more similar groups could form around the idea of creating web based applications that are written with KDE applications (on mobile, desktop, whatever) in mind and/or the needs of the KDE community itself? Is it possible that one day some intrepid individuals with the web developer spirit and skills would start Just Doing It and build up a whole new area of the KDE community, just as our artists did some years ago for visual design efforts?

I don't know the answers, nor am I in a place to attempt to explore them in full. I just know the needs exist and the questions are there to be asked. Discuss ... :)

Read More

multihead plasma desktop needs YOU!

Multihead, where there is more than one physical screen and one X server per physical screen (not to be confused with xinerama, xrandr, mergefb, etc.), and Plasma Desktop is getting into a rather usable state thanks to testing and feedback from users with those systems that goes beyond "it doesn't work". Thanks to the digging and debugging work of several individuals, my "coding in the blind" has produced finally produced useful results as of the 4.5.3 release. There are still some KWin issues, apparently, but plasma-desktop is pretty well there.

Today I added a boolean multihead variable to the Plasma Desktop Scripting, and yes it is documented. This allows scripts, should they need to, do different things in a multihead setup.

There are some unique annoyances with multihead, though. For instance, when enumerating the screens with Kephal it will report that there are N screens, but each the origin point of the geometry of each screen will be (0,0) meaning that it looks like they overlap, even thought they don't. This leads to some awkward behavior both in the initial layout set up as well as things like repositioning panels on screens other than the first one. Nothing fatal, but not optimal either.

An approach occurred to me today that might make this easier to handle: make plasma-desktop's Corona "lie" when in multihead mode and say it has just one screen and map screen "0" to the real screen id transparently behind everything's back. It's a bit of a hack, but so is multihead. ;)

I have no idea how well this works due to not having a system to test it with, though in theory it should be an improvement. What I need are people with multihead systems who are running trunk to try this patch to plasma-desktop and report back what happens. I expect that it does nothing for the panel moving issue, but other things should improve or at least not degrade. If that is the case, then fixing the panel moving issue becomes trivial by extending this approach there as well.

Please test if you can and let me know on plasma-devel at kde.org or in a comment on my blog here. Cheers.

Read More

articulation

"Articulate" is a fascinating word in that it captures a very fundamental idea related to connectedness, harmony and flow. A person can speak articulately, and they can successfully (or not) articulate an idea. A mechanism can be articulated, such as the human hand or the links on a chain. Likewise, ideas can be articulate in how they are connected to each other. This also allows us to say that a painting or a philosophical position is articulate.

Among the 250 to 750 thousand words estimated to be in the English language, only a small and hallowed few contain the essence of such a fundamental idea that it pops up so profoundly in so many contexts.

I have a fondness for the word, if that wasn't already apparent by this point, and it has a lot of personal meaning for me. I relate to the word in terms of speech and writing, two things I enjoy doing and which I have practiced for most of my life. I also associate the word with how my life has been put together, its articulation.

I keep expecting after that passing of each year that it will be the one in which unique surprises and new plateaus start to thin out and become the exception rather than the norm. Over thirty five years in to this existence of mine and it hasn't happened yet. The punctuation marks in my life have come in an unusual stream with fewer comas, semicolons and periods than one probably should expect. Rather there's been a fairly steady series of short loud phrases mixed with questions of unusual severity that have combined to create something like a Jackson Pollock canvas. Not that I would change anything. The path we each walk is the one that leads to where we are, with no other path leading to that point. It is a process that is sacred in a way that requires no deity to say it is sacred for it to be so.

It's been a pretty amazing ride at times: I've had the privilege to live in what can best be described as "magical" places. I recently heard one such former home described as being "idyllic" during the period that I happened to be there. (To be clear: it obviously wasn't idyllic because I was there, but I had the opportunity to experience that.) I was blessed to have met two particularly amazing people who played roles in my life that my parents probably should have, and I had a sister who watched over me with her heart and her being. I have had the opportunity to love great loves, though none greater than the love that found me in the form of my son. These are among the experiences that I cherish.

The universe likes balance, however, and there are stretches in my story that I would not have chosen for myself. Every mountain leaves a valley, or as Eddy Vedder wrote, "I have faced it, a life wasted. I'm never going back again." I've lived in places and experienced moments far less than idyllic. Yet while life has been unpredictable and untamable, it has also been alluring and rewarding. It has held me like the ocean does a ship.

Today is the usual. I'm in the midst of a confluence of events that in combination have been taking all the attention, energy and resources I can provide. I am embroiled in a custody battle for my son so that he may accompany me to Zurich, something that would be amazing for him and which would provide a continuity to the last three years of he and I sharing an abode together. Regardless of the outcome, I am moving to a new the place that will become my home from which I can do that which I do, and a place where I will be doing something quite specific that I had honestly not foreseen for myself even a couple years ago: getting married to a rather wonderful person. That she is half-way around the world from me seems to make it all the more fitting. As all this swirls in the now, I am looking forward to this future that begins at the end of winter, even if the right now is proving challenging to walk through.

Those who may have been wondering at my relative absence from some of my usual haunts (irc, for example; personal business projects for another) may understand a bit more of the why. I feel rather poorly about things like "Project Elegance" not getting lift-off (especially after the work some of us put into the foundations for it), but such is life and I know that there will be space later for all of this.

Last night I poured myself a hot bath, added some gently scented oils, lit candles and turned off the lights; I cracked open a new (for me) book that is turning out to be brilliant (he says, only 85 pages in) while listening to music sung by people with perfectly imperfect voices, voices they used to present our collective souls through. Most simply, and profoundly: I breathed. It's easy to forget how fundamentally useful it is to do that task well. It was cleansing, literally and otherwise, and the thinking has been denser and clearer since.

Thoughts have been turning around and around during and after, pondering the articulation of my life. I thought about those I've spent time with in the past and those who are part of my life now. I thought about how I am using my existence.

Among other things, I started drafting some thoughts about articulation within the context of KDE. That is for another blog entry, however. We have much to do.

Read More

commonality and community

Jono Bacon, Ubuntu community manager for Canonical and Heavy Metal Thrash Machine, has just put up a website he named OpenRespect. It's an interesting read, and I do encourage you to go read it because I think there are some really good points made in it, in particular this bit:

"When we place respect at the center of our interactions, we enrich our lives, discover new ways of thinking, and expand our horizons with new ideas and experiences. When we remove this respect, our conversations suffer, which in turn makes our community suffer, and this ultimately risks our ability to bring our message of freedom and openness to others."

Words to live by, no doubt.

Jono asked if I'd be interested in becoming an "OpenRespect Advocate", which means my name would appear on the website in support of the text and I would generally go and tell others about it to spread the meme and support for it. Not entirely unlike what I just did here, I suppose. However, I declined to sign on as an advocate of OpenRespect. Horrors!

Wait .. what? Didn't I just use the phrase "words to live by" right before "I declined"? *confused look*

Simply put, here's how I feel about it: the statement is great for people within a given community (any given community), but I do not believe it to be applicable between communities as written. With something like respect, if you set up a set of non-applicable aspirations, it will only cause more problems than it solves.

It's perhaps quite counter-intuitive that promoting respect could result in anything but good things, but it comes down to what community is, how respect works within that context and the assertion that everyone who is "creating software, content, and culture that is freely available for others to share, enjoy and enrich their lives" is part of a single community. Are we?

Community can be described from the individual's point of view as a combination of membership, influence, integration, fulfillment of need and shared emotional connection. This is not my formulation: it's what the social scientists have told us. There's a nice article about the sense of community on Wikipedia, if you're interested.

This means that despite the fact that I am most certainly involved in creating artifacts of Free culture and that I personally identify as being part of a few communities that have Free culture as a central concept, I am still unable to state that I am a member, have influence in or am influenced by, am integrated into or share an emotional connection with the vast majority of Free culture communities out there. Why is that?

Community is a deeply valuable thing. It's valuable because it is based on a richness of investment that takes the form of trading of goods between people that are both tangible and intangible. The key word there is investment, aka "value". Like most resources in my life, I only have so much to invest and therefore I can only truly be part of so many communities. I can slap my name on as many Free culture products as I wish, but I'll still only truly be a part of a small number of communities.

Hold on, though! At the same time, I do deeply sympathize with other Free culture communities and (nearly) universally empathize with their efforts and goals. This is because there are commonalities between these communities. Jono hints at this when he says, "Together we believe that freedom is good. We believe it helps people do good things, make better choices, and lead safer and more secure lives." It is tempting to try and paper over boundaries between communities by emphasizing such commonalities. This does not, however, change the reality that there are many different communities. Empathizing with commonalities is not nearly the same thing as community.

Why does that matter? Here are some reasons I can offer:

• Respect is communicated and earned in culturally specific ways


• Assumed respect fails where earned respect holds up


• Respect does not actually equate to better treatment


• Respect operates under different assumptions within a community versus between communities

Let's drill down a bit into each of those assertions.

Respect is Cultural

I've traveled through a fairly significant number of cultures, and lived for periods of time in a few different ones. One thing I learned in doing so is that people are more alike than different. I also learned that culture changes how we communicate just about everything, including respect. It also influences how we gain respect and display the things that we do or have that earn us that respect.

One of my favorite personal stories about this involves sitting a table discussing business issues with a German fellow and some North Americans. Both started demonstrating their respect for each other in conversation, but in short order the German had been too blunt for the Americans in sharing his viewpoint on the topic at hand and a dispute arose because of it. My German friend was actually acting out of his sense of respect for the others at the table: he felt they deserved only his true feelings on it, and he delivered them openly without any emotionality behind it, just the facts. My American friends were shocked by this as "obviously" he couldn't muster the basic courtesies anyone who had a shred of respect and dignity would! They told him so, though as only (at least in my experience) a good American can. ;) This was deeply shocking to my German friend at the table. Who was not showing respect to whom? Both thought the other party wasn't. Truth is, both were trying to, but culture got in the way.

I've also traveled around the Free software ecosystem quite a bit and to a lesser extent the larger Free culture world. I've come in contact with various communities within those spheres and have found that the cultures in those communities are just as varied, and entrenched, as the geographical ones. Some are soft and put listening first and foremost; some relish creative flair above all else; some respect hard criticism; some demand rigor while others look for nuance; some come together and have a big fight before embracing each other again (often "in their own way") over issues that other communities will sit back and become introspective over instead. There is huge variance, and this has led me to realize that there is huge variance in what respect means between these communities. You earn it differently, you display it differently, you act based on your respect differently depending on the community.

So asking for respect between people of random communities doesn't work very well unless you first step back and define what is meant by that respect. Jono's definitions include the highly cultural subjective terms "quality and content of discourse", "civility", "sharing", "persecution", "honest", "polite", "sensitive" .. all highly concepts whose definitions are highly cultural.

Therefore within any given community, I think what Jono wrote is excellent material. Unfortunately, we are not one culturally homogenous community, we are many communities with a high degree of commonality. Unfortunately, it often turns out that communities with large amounts of similarity often end up polarizing around their differences much more so that people from communities with larger differences. Democrats and Republicans in the USA are the example de jour. It is glib to hope, due to the cultural underpinnings of respect, that urging people towards the abstract notion of respect is enough.

Assumed Respect is to Earned Respect as Glass is to Plexiglass

When I meet someone from the Free culture ecosystem, I assume a level of immediate respect about them. This is because I know we have similarities and commonalities due to our expressed interests in Free culture. So there is an immediate affordance of respect and understanding, something I certainly don't immediately feel to someone who is, for instance, openly lobbying for software patents. This respect, however, it speculative: I am speculating that there is reason to respect this person because of the commonalities, even though I don't know many specifics. Speculative respect is a cheap commodity, however, and like a glass window can be broken fairly easily. (Something I used to specialize in as a child. ;)

It is understandable why it is this way: there is no real foundation for the respect, and so if there is a hint that the assumption is wrong, the feeling of respect can quite quickly turn to feelings of betrayal. We rarely feel we have misidentified the other person, rather we tend to assume they misrepresented themselves. This often feels like being lied to, and that calls up feelings similar to those engendered by betrayal. I've witnessed people being treated absolutely horribly as result of this phenomenon.

If we remove the cultural underpinnings of respect and with it an earned foundation for that respect, we are left with only assumed respect.

Respect that is earned through culturally relevant means (e.g. specific actions, assets or behaviors) is much, much stronger. It can withstand misunderstandings and even actual instances of betrayal. It can give two aggrieved parties the opportunity to put aside other feelings and readdress their relationship, work through issues. As such, it is an amazingly powerful mechanism by which to modify our behavior to one another, much as Jono describes in his OpenRespect statement.

To think, however, that we can use assumed respect in the same manner is a false hope. The problem comes if and when it fails to prevent a problem due to its brittle nature. At that point, we then deal with the overly negative feelings that may never have existed if we didn't start with the required assumption of respect. It is therefore my experience that when bringing people together from different communities to encourage the creation of respect rather than ask for the assumption of it. Mutual respect is indeed always the goal, but without the fabric of common community and its culture to hold it together, one is served well to start a step back from there.

Respect is a modifier, but in which direction?

Respect (or lack thereof) moderates behavior, there is no doubt about that. How it does so is dependent on the relationship between the people involved, however. Put another way, the effects of respect on interactions is only predictable if given the context of the involved parties.

For instance, I may respect an opponent that I face off against in a game, but that may result in me playing harder and with a more ruthless strategy against them than I would against someone whose skills I respect less. In fact, in situations where there is competition at play, feelings of empathy are more of a powerful way to get equitable behavior out of people than respect is.

Let's be honest with ourselves here: there are many instances where Free culture communities compete with each other. The competition can be for monetary resources at the most crude level, but often they involve competition for minds, hearts, attention and "superior" results (which is another qualitative, culturally dependent term). As such, encouraging respect as the driver in such situations may not lead to more equitable behavior at all.

I have seen this time and time again in the Free software desktop world, where one project will use highly political means to attempt to "get one over" on another project. For some projects, this becomes the modus operandi for dealing with other projects (other in general or just for specific "outsider" projects). The lack of empathy between the communities coupled with a deep respect for the capabilities of those same communities has led to many unnecessary and, quite frankly, stupid struggles. I have a whole bag of fun GNOME and KDE stories that follow that plot line. We've gotten quite a bit better over the years, though sometimes old demons raise their heads, and those advances have come through a mix of empathy building exercises and appeals to self-interest by making the argument for "only together we can". Respect hasn't really been a positive factor, nor has it been lacking. There have been lots of polite, respectful conversations and agreements and lots of mutual admiration for various achievements in times when the results or actions ended up not being equitable.

What I'm trying to say is that respect is an important thing, but it's not enough on its own. It is often not even useful as a primary driver. Empathy, shared assumptions, protocols to build the interactions we seek among other tools are as or more important.

Respect, Inter- versus Intra-community

I immigrated on the day I turned 12 to a rather different community compared to the one I had lived in up until then. I went from part of the visible majority (fair skinned people) in a stable middle class environment (rural West coast Canada) to being a visible minority (white in a predominantly Polynesian and Asian community) in a community with many struggles (drugs, gangs, violence, visible racism, visible poverty). Both communities I lived in had their dark sides, and both had their amazing sides. I feel privileged to this day to have been able to a part of both of those communities.

In both, respect was expected and in evidence everywhere one cared to look. But I learned something from being dropped into another community like that: I could not demonstrate my honest respect for others in my new community the way existing members of the community could to each other, and I couldn't use the mechanisms of respect from my old community verbatim in my new one. I was not yet part of their community, so trying to behave as if I were by adopting their affectations immediately was perceived as not being genuine; indeed, it would be mere mimicry. Those who attempted this were treated poorly. At the same time, my cultural respect cues were just plain confusing from their cultural perspective, to the point that I (seriously!) almost got beat up a few times simply for asking a polite Canadian "Pardon me?" when I didn't understand what someone else had said.

This was my first brush with respect as a foreigner in a community. My strategy became to present myself using my "natural" respect mechanisms from Canada, while making it clear that this was what I was doing. This lives on in my habit of often introducing myself as "Aaron, from Canada" when I meet people abroad. It allows me to communicate in a genuine way, while letting the others know that while it will come across as quite honest it may also seem a bit odd to them due to cultural differences. If nothing else, it saved my teenage hide more than once and has gotten me into a few fun parties while traveling abroad. ;)

In my adult years, I've had the privilege of discussing these issues with people who do this professionally, people who work as international ambassadors, cultural specialists with the U.N. Their insights are far more fascinating, profound and deep than my "down home" offering above, but resonate with me because I often hear similarities to my own experience: you have to come from a genuine place, but you also have to know it's going to get lost in translation to some extent and prepare for that.

So it is that building and effectively demonstrating respect between communities is a very different experience with a very different language and mechanism behind it than building respect between members of an existing community. Given that Free culture does not have one monolithic community, we need to acknowledge that and prepare ourselves for it. Oversimplifications will fail us and lead to disappointments that lead to fissures that are very hard to mend.

(I could also go on about our lack of skilled ambassadors and the scary job some of us do when we pretend to do that kind of work between F/OSS projects ... but I won't do so here. :)

Monoculture?

This begs the question: should we strive to become one big community, then, with one big set of cultural standards? This turns out to be a useless question to ask because it is not be possible to achieve such a monoculture.

Whether or not a single culture would be useful, it is not attainable if we are large and successful. Community evolves due to interaction over time, and that evolution causes drift in culture and values that are not "wrong" relative to each other but which are (usually) merely different ways of interacting with the same issues. We would have to all start working together on near-daily basis to counteract that, and that's simply impossible due to the basic logistics that come with the scales we deal with. Success begets scale, and scale begets cultural drift: there are too many people working on too many very different kinds of projects in too many different interest areas to build a single community. This also happens to be amplified by the decentralized mechanisms that drive Free culture at its core.

We can certainly celebrate our commonalities, but we will probably never have a single common culture or community. We can form agreements and draft papers together (which OpenRespect could be a good start to, in my humble opinion, if it is evolved further), but that doesn't engage the spirit of individuals (which is what community does). Instead, it relies on the intellect of groups. This is not to cheapen it in the least, just to put it into a realistic frame.

So what about OpenRespect?

Community agreement and coherence isn't a simple topic, and global agreement even less so. They are, however, both very important ones. I applaud Jono for tackling it so directly, and I have to give him some mad respect ;) for that. I do think that to be a useful tool, versus one that will set up false situations and lay land mines despite good intentions, it needs to be evolved considerably.

If what was there was simply refined to talk about "within a given community", it would probably work as-is, but I don't think that's what Jono is after. I get the impression that he wants to see us "all just get along" and that is something I think we could really use. To accomplish that, OpenRespect would need to take in the realities of interaction between disparate communities.

OpenRespect talks about sharing and debate, but listening with openness, without judgment and engaging in forms of communication other than debate (which is conflict centric) are at best hiding between the cracks.

There is a mention of honesty in debate, but the undermining effect of half-truths, convenient positioning and other tactics that undermine community relations outside of debate are not covered at all, despite being a key to building as well as demonstrating respect.

Today many communities, including both KDE and Ubuntu, have codes of conduct that are culturally relevant and which emphasizes mechanisms of respect as part of their core tenets. In fact, they tend to be documentary of the existing cultural norms and expectations rather than prescriptive. For OpenRespect to add to that conversation and bring real additional value, it needs to be similarly documentary rather than perscriptive and what it should describe, at least in my opinion, is what it takes to bridge between communities.

OpenRespect could even house both: a template for community codes of conduct that have a strong basis in mutual respect as well as a realistic framework for a commitment that disparate communities can buy into to good effect. Those are not the same documents, however, even if they are complimentary. They are also documents that are probably best drafted not on our own, but with the aid of people who live and breath community bridging as their profession and passion who can bring profound understandings that we can only poke at in the dark with sticks.

I'd be proud to advocate such an achievement.


With much love,
including to Jono and his effort thus far with OpenRespect,
coupled with and tempered by a deep care for this topic,
Aaron.

Read More

quick notes on using review board effectively

The Plasma team has been using review board for quite a while. We were the pioneering project within KDE for its use, in fact, which leads to an interesting observation about how such things often come up in KDE: one group tries something for a while, determines how well it works (or doesn't), other groups either start adopting it or express interest in it and eventually it is proven enough, consensus is reached and if it is a good thing it becomes a "KDE thing". It's a bit of a slow process at times, but it lets us as a community perform many experiments safely and pick out the ones that work well for people.

During our time using review board, I've noticed a few things that make it work better or worse, and I thought I'd share them here in case others were interested:

• Closing requests when they are done (committed, rejected, withdrawn, etc) is really important to keeping the queue useful. If I can't distinguish between reviews that have been languishing unattended for a month or a review that has been committed but not closed it isn't helpful.


• Screenshots for things that change the UI are hugely valuable. I've been tempted to start a "if it has a visual consequence and there is not screenshot, it won't be approved" policy to try and get more people doing this, but I also don't want to raise the bar too high to contribution. Still, screenshots make it so much faster and easier to communicate about a give patch.


• Give the patch a useful name before uploading it, otherwise I end up with a directory full of patches named "bug(N).diff" and other similarly unhelpful information. Names like "improve_foo_visual.diff" are much nicer. It makes it faster to apply them and lets me clean out my patches dir quicker if I can identify which is which.


• Start the diff at the lowest sensible directory. Diffing a change against a component 3 directories deep against the top level module isn't the most helpful: I tend to apply not at the top level but where the work is being done, e.g. at the application's or plugin's directory if in a combined module. For example, if patching the plasma-destop app, start the diff at kdebase/workspace/plasma/desktop/shell as opposed to kdebase or kdebase/workspace. This makes it easy to guess where the diff will start from and leave me at the "right" place in the tree once the diff is applied.


• Keep conversations on the review request. Usually, at least in KDE projects, all comments get CC'd to a mailing list. Replying to mailing list, however, results in the conversation being split up, partly on the review request and partly on the mailing list. Keeping it all on the review request keeps the comments together and closest to the actual data in question.

Do you have your own set of best practices for review board? Share them in the comments! I plan on adding such a list to Techbase for future reference. As review board is becoming a more and more common part of our workflow, using it efficiently is important.

Read More

+10 on Linux Journal Reader's Choice Awards

The 2010 Linux Journal Reader's Choice Awards are out and several KDE efforts have done paricularly well this year. While these kinds of awards can not be used as reliable indicators of real world usage patterns, they do give some insight into how the vocal and involved F/OSS community feels about things and they do provide some interesting hints at directions within F/OSS.

Amarok and Digikam both took top spots in their respective categories, and quite deservedly: they are awesome applications. They are also both "Extragear" applications: applications that are not bundled with the KDE software compilation that gets released twice a year along with the Development Platform and Workspaces. Like many such KDE applications, Amarok and Digikam have reasonably large and dedicated development and development support teams. It is great evidence not only that terrific apps can be made with the Qt and KDE Platform, but that the bundled apps in the software compilation are not the only path to support and success as an application.

There were also several runner up, 3rd and 4th place showings for applications such as Choqok for microblogging, Kopete for IM, Konqueror for web, KMail for email, Konversation for IRC, Krita for graphic design tool and KOffice for office document creation. VLC, an application that made the jump to Qt in the last couple of years, also showed well taking top spot for media players and making a show in the best audio tools section. It wasn't the only Qt app in their either.

MeeGo and the N900 from Nokia also took top honors in two different categories, showing the momentum Nokia and Intel have built around the MeeGo platform.

The real good news to me, though, was how "KDE", by which they mean our desktop offering, did. In the last few years we have gone through some hard, though somewhat necessary, progressions. There was the difficulty of the transition from KDE 3 to the 4.x versions of the platform, desktop and applications. We adjusted our branding message to reflect a more complex reality and experienced a number of technology speedbumps, some of which were firmly in our control and some of which were less so. In the last year, we've emerged from that period with a stronger technology foundation, better applications, clearer communication, stronger vision and a healthy community. This wasn't the only challenge we faced, however.

There was also the rise of Ubuntu in popularity amongst the F/OSS enthusiasts with a near constant spray of articles and communication labeled "Ubuntu" regardless of whether the content was Ubuntu specific or not. Ubuntu has quite firmly been a GNOME distribution, though with the move to Unity and the increased support we're seeing for Kubuntu, Qt and KDE applications from Canonical this isn't as black-and-white as it once as. Still, this "Ubuntu, ergo GNOME" connection was hugely helpful for GNOME and it sometimes came at our expense. We persevered through it, and various things in the landscape have shifted.

I think this is reflected in the "Best Desktop" and "Product of the Year" awards. KDE's desktop offering jumped 10 points in Linux Journal's poll over last year, reaching parity with GNOME's poll numbers. That is a significant jump, after a two year slump. It was also very telling that in "Product of the Year", we snagged the runner-up position behind only Android. That is a huge achievement for people to consider what we do, year in and year out, as something that contends for F/OSS' best achievement of the year across all categories.

Four years ago, we knew we had some very hard decisions to make. We knew that we could try and ride our laurels and past success and likely fade out into the sunset as we did so. We knew we could also take on the task of retooling that which needed to be, though that would bring disruption with it. Not an easy decision, and not one you get to make twice. There is yet so much more that we can explore and accomplish thanks to the decisions we did make, how we dealt with not just the positives but also the uncomfortable negatives and how the entire community of contributors around KDE picked up their boots in support of what needed to be done.

We're not done yet. Next year I hope to see even more KDE and Qt applications polling at the top spots in their category, and we'll certainly be shooting for another jump in the Desktop Environment poll based on great upcoming releases.

Cheers to everyone involved with making KDE software winners in the minds and hearts of ourselves and our users! :)

Read More