Saturday, September 27, 2014

Explaining bands of nothing, BASH bugs, and old research

I heard a really interesting little show on the radio tonight, about the man who explained 'bands of nothing.' "Astronomer Daniel Kirkwood... is best known for explaining gaps in the asteroid belt and the rings of Saturn — zones that are clear of the normal debris." http://stardate.org/radio/program/daniel-kirkwood. He taught himself algebra, and used his math background to analyze the work of others, rather than making his own observations. The segment is only 5 minutes; give it a listen.

This reminded me of the how much progress I used to make when I did genealogy research, by looking over the documents I had gotten long ago, in light of facts I more recently uncovered. All of a sudden, I made new discoveries in those old docs. So that has become part of my regular research routine.

And perhaps all of these thoughts were triggered by the BASH bug which I keep hearing about on the news in very vague terms, and in quite specific discussion in IRC and mail lists. Old, stable code can yield new, interesting bugs! Maybe even dangerous vulnerabilities. So it's always worth raking over old ground, to see what comes to the surface.

Friday, September 26, 2014

Overcoming fear

In the last few posts, I've been exploring ideas expressed by Ed Catmull in Creativity, Inc. Everyone likes good ideas! But putting them into practice can be both difficult, and frightening. Change is work, and creating something which has never existed before, is creating the future. The unknown is daunting.

In meetings with the Braintrust, where new film ideas are viewed and judged, Catmull says,
It is natural for people to fear that such an inherently critical environment will feel threatening and unpleasant, like a trip to the dentist. The key is to look at the viewpoints being offered, in any successful feedback group, as additive, not competitive. A competitive approach measures other ideas against your own, turning the discussion into a debate to be won or lost. An additive approach, on the other hand, starts with the understanding that each participant contributes something (even if it's only an idea that fuels the discussion--and ultimately doesn't work). The Braintrust is valuable because it broadens your perspective, allowing you to peer--at least briefly--through other eyes.[101]
Catmull presents an example where the Braintrust found a problem in The Incredibles film. In this case, they knew something was wrong, but failed to correctly diagnose it. Even so, the director was able, with the help of his peers, to ultimately fix the scene. The problem turned out not to be the voices, but the physical scale of the characters on the screen!

This could happen because the director and the team let go of fear and defensiveness, and trust that everyone is working for the greater good. I often see us doing this in KDE, but in the Community Working Group cases which come before us, I see this breaking down sometimes. It is human nature to be defensive. It takes healthy community to build trust so we can overcome that fear.

Tuesday, September 23, 2014

Candor and trust

Catmull uses the term candor in his book Creativity, Inc., because honesty is overloaded with moral overtones. It means forthrightness, frankness, and also indicates a lack of reserve. Of course reserve is sometimes needed, but we want to create a space where complete candor is invited, even if it means scrapping difficult work and starting over. [p. 86] Catmull discusses measures he put into place to institutionalize candor, by explicitly asking for it in some processes. He goes on to discuss the Braintrust which Pixar relies on to push us towards excellence and to root out mediocrity....[It] is our primary delivery system for straight talk.... Put smart, passionate people in a room together, charge them with identifying and solving problems, and encourage them to be candid with one another. [86-7] Does this sound at all familiar?

Naturally the focus is on constructive feedback. The members of such a group must not only trust one another, but see each other as peers. Catmull observes that it is difficult to be candid if you are thinking about not looking like an idiot! [89] He also says that this is crucial in Pixar because, in the beginning, all of our movies suck. [90] I'm not sure this is true with KDE software, but maybe it is. Not until the code is exposed to others, to testing, to accessibility teams, HIG, designers--can it begin to not suck.

I think that we do some of this process in our sprints, on the lists, maybe in IRC and on Reviewboard, but perhaps we can be even more explicit in our calls for review and testing. The key of course is to criticize the product or the process, not the person writing the code or documentation. And on the other side, it can be very difficult to accept criticism of your work even when you trust and admire those giving you that criticism. It is something we must continually learn, in my experience.

Catmull says,
People who take on complicated creative projects become lost at some point in the process....How do you get a director to address a problem he or she cannot see? ...The process of coming to clarity takes patience and candor. [91] We try to create an environment where people want to hear one another's notes [feedback] even where those notes are challenging, and where everyone has a vested interest in one another's success.[92]
Let me repeat that, because to me, that is the key of a working, creative community: "where everyone has a vested interest in one another's success." I think we in KDE feel that but perhaps do not always live it. So let us ask one another for feedback, criticism, and strive to pay attention to it, and evaluate criticism dispassionately. I think we have missed this bit some times in the past in KDE, and it has come back to bite us. We need to get better.

Catmull makes the point that the Braintrust has no authority, and says this is crucial:
the director does not have to follow any of the specific suggestions given. .... It is up to him or her to figure out how to address the feedback....While problems in a movie are fairly easy to identify, the sources of these problems are often extraordinarily difficult to assess.[93]
He continues,
We do not want the Braintrust to solve a director's problem because we believe that...our solution won't be as good....We believe that ideas....only become great when they are challenged and tested.[93]
 More than once, he discusses instances where big problems led to Pixar's greatest successes, because grappling with these problems brought out their greatest creativity. While problems ... are fairly easy to identify, the sources of these problems are often extraordinarily difficult to assess.[93] How familiar does this sound to us working in software!? So, at Pixar,
the Braintrust's notes ...are intended to bring the true causes of the problems to the surface--not to demand a specific remedy. 
Moreover, we don't want the Braintrust to solve a director's problem because we believe that, in all likelihood, our solution won't be as good as the one the director and his or her creative team comes up with. We believe that ideas--and thus films--only become great when they are challenged and tested.[93]
I've seen that often this last bit is a sticking point. People are willing to criticize a piece of code, or even the design, but want their own solution instead. Naturally, this way of working encounters pushback.

Frank talk, spirited debate, laughter, and love [99] is how Catmull sums up Braintrust meetings. Sound familiar? I've just come from Akademy, which I can sum up the same way. Let's keep doing this in all our meetings, whether they take place in IRC, on the lists, or face to face. Let's remember to not hold back; when we see a problem, have the courage to raise the issue. We can handle problems, and facing them is the only way to solve them, and get better.

Thursday, September 11, 2014

Accessible KDE, Kubuntu

KDE is community. We welcome everyone, and make our software work for everyone. So, accessibility is central to all our work, in the community, in testing, coding, documentation. Frederik has been working to make this true in Qt and in KDE for many years, Peter has done valuable work with Simon and Jose is doing testing and some patches to fix stuff.

However, now that KF5 is rolling out, we're finding a few problems with our KDE software such as widgets, KDE configuration modules (kcm) and even websites. However, the a11y team is too small to handle all this! Obviously, we need to grow the team.

So we've decided to make heavier use of the forums, where we might find new testers and folks to fix the problems, and perhaps even people to fix up the https://accessibility.kde.org/ website to be as
awesome as the KDE-Edu site. The Visual Design Group are the leaders here, and they are awesome!

Please drop by #kde-accessibility on Freenode or the Forum https://forum.kde.org/viewforum.php?f=216 to read up on what needs doing, and learn how to test. People stepping up to learn forum
moderation are also welcome. Frederik has recently posted about the BoF: https://forum.kde.org/viewtopic.php?f=216&t=122808

A11y was a topic in the Kubuntu BoF today, and we're going to make a new push to make sure our accessibility options work well out of the box, i.e. from first boot. This will involve working with the Ubuntu a11y team, yeah!

More information is available at
https://community.kde.org/Accessibility and
https://userbase.kde.org/Applications/Accessibility

Tuesday, September 9, 2014

Fixing mistakes and growing stronger

In Creativity, Inc., Catmull explores an example of where their structure had created some problems, and how they identified and fixed that, improving their over-all culture. I know this is a wall of text, but Catmull asks excellent questions. I felt it was worthwhile to copy for you. He says,
Improvements didn't happen overnight. But by the time we finished A Bug's Life, the production managers were no longer seen as impediments to creative process, but as peers--as first-class citizens. We had become better. 
This was success in itself, but it came with an added and unexpected benefit: The act of thinking about the problem and responding to it was invigorating and rewarding. We realized that our purpose was not merely to build a studio that made hit films but to foster a creative culture that would continually ask questions. Questions like: If we had done some things right to achieve success how could we ensure that we understood what those things were? Could we replicate them on our next projects? Perhaps as important, was replication of success even the right thing to do? How many serious, potentially disastrous problems were lurking just out of sight and threatening to undo us? What, if anything, could we do to bring the to light? How much of our success was luck? What would happen to our egos if we continued to succeed? Would they grow so large they could hurt us, and if so, what could we do to address that overconfidence? What dynamics would arise now that we were bringing new people into a successful enterprise as opposed to a struggling startup?

What had drawn me to science, all those years ago, was the search for understanding. Human interaction is far more complex than relativity or string theory, of course, but that only made it more interesting and important; it constantly challenged my presumptions.... Figuring out how to build a sustainable creative culture--one that didn't just pay lip service to the importance of things like honesty, excellence, communication, originality, and self-assessment but really *committed* to them, no matter how uncomfortable that became--wasn't a singular assignment....

As I saw it, our mandate was to foster a culture that would seek to keep our sightlines clear, even as we accepted that we were often trying to engage with and fix what we could not see. My hope was to make this culture so vigorous that it would survive when Pixar's founding members were long gone. [p. 64-5]
Again, I see an almost perfect match between their task and ours, where ours=KDE e.V.. In the Community Working Group (CWG) in particular, I see my task as essentially gardening. This includes improving the soil, weeding, but never removing valuable little shoots which can grow into exciting new directions for the community. Of course I can't carry the metaphor too far, since others do the planting. But we can keep the conditions for growth optimal with our work.

In the documentation workshop yesterday, we explored the current state of the KDE documentation, how we can improve access, and grow the documentation team again. We also found some large choke points, which includes KDE.org. We really need a web team! KDE.org is valuable real estate on the web, which has been neglected for too long. More about that later.....

For now, looking forward to another day of hard work and fun in Brno!


Sunday, September 7, 2014

Late posting: Heading to Brno for Akademy!

So excited to be in the air over Seattle, heading toward Vienna and Brno, and Akademy! Beside me is Scarlett Clark, who will be attending her first Akademy, and first Kubuntu meeting. We've both been sponsored by Ubuntu for the costs of travel; thank you! Scarlett was telling me, as we waited to board our first flight, how long she looked for a place to contribute to a Linux community. She said she tried for years, in many distributions, on mail lists and in IRC. What she was told was "do something." How does a first-time contributor know what is needed, where to ask, and how to make that crucial first step?

I was glad to hear that once she found the KDE-doc-english mail list, that she was encouraged to stick around, get onto IRC, and guided every step of the way. I was also happy to hear that Yuri, Sune and Jonathan Riddell all made her feel welcome, and showed her where to find the information she needed to make her contributions high quality. When Scarlett showed up in #kubuntu-devel offering to learn to package, I was over the moon with happiness. I really love to see more women involved in free and open source, and especially in KDE and Kubuntu, my Linux home.

I was a bit sad that the Debian community was not welcoming to her, with Sune the one bright spot. Yeah SUNE! (By the way, hire him!) I think she will find a nice home there as well, however, if our plans to do some common packaging between Kubuntu and Debian works out in the future. It was interesting to see the blog by the developers of systemd discussing the same issue we've been considering; the waste of time packaging the same applications and other stuff over and over again. So much wasted work, when we could really be using our time more productively. Rather than working harder, let's work smarter! Check out their blog for their take on the issue: http://0pointer.net/blog/revisiting-how-we-put-together-linux-systems.html

Welcome to Scarlett, who is planning to get her blog up and running again, and on the planets. She'll be saying more about these subjects in the future. Scarlett, and all you other first-time Akademy attendees, a hearty hug of greeting. Have a wonderful time! See me in person for a real hug!

PS: I couldn't post this until now, Sunday morning. The Debian folks here, especially Pinotree have been great! I look forward to our meeting with them on Thursday morning.

Saturday, September 6, 2014

Creativity and KDE

Creativity Inc., by Ed Catmull, President of Pixar

My book to read for this trip finally arrived from the library last week, and I could hardly wait to dip into it. I see a profound parallel between the work we do in KDE, and the experiences Catmull recounts in his book. He's structures it as "lessons learned" as he lead one of the most creative teams in both entertainment and in technology. His dream was always to marry the two fields, which he has done brilliantly at Pixar. He tried to make a place where you don't have to ask permission to take responsibility. [p. 51]

Always take a chance on better, even if it seems threatening Catmull says on p. 23. When he hired a person he deemed more qualified for his job than he was, the risk paid off both creatively and personally. Playing it safe is what humans tend to do far too often, especially after they have become successful. Our stone age brains hate to lose, more than they like to win big. Knowing this about ourselves sometimes gives us the courage to 'go big' rather than 'go home.' I have seen us follow this advice in the past year or two, and I hope we have the courage to continue on our brave course.

However, experience showed Catmull that being confident about the value of innovation was not enough. We needed buy-in from the community we were trying to serve.[p 31] My observation is that the leaders in the KDE community have learned this lesson very well. The collaborative way we develop new ideas, new products, new processes helps get that buy in. However, we're not perfect. We often lack knowledge of our "end users" -- not our fellow community members, but some of the millions of students, tech workers and just plain computer users. How often do teams schedule testing sessions where they watch users as they try to accomplish tasks using our software? I know we do it, and we need to do it more often.

Some sources rate us as the largest FOSS community. This can be seen as success. This achievement can have hidden dangers, however. When Catmull ran into trouble, in spite of his 'open door' management style, he found that the good stuff was hiding the bad stuff.... When downsides coexist with upsides, as they often do, people are reluctant to explore what's bugging them for fear of being labeled complainers.[p. 63] This is really dangerous. Those downsides are poison, and they must be exposed to the light, dealt with, fixed, or they will destroy a community or a part of a community. On the upside, the KDE community created the Community Working Group (CWG), and empowered us to do our job properly. On the downside, often people hide their misgivings, their irritations, their fears, until they explode. Not only does such an explosion shock the people surrounding the damage, but it shocks the person exploding as well. And afterwards, the most we can do is often damage control, rather than helping the team grow healthier, and find more creative ways to deal with those downsides.

Another danger is that even the smartest people can form an ineffective team if they are mis-matched. Focus on how a team is performing, not on the talents of the individuals within it.... Getting the right people and the right chemistry is more important than getting the right idea.[p. 74] One of the important strengths of FOSS teams, and KDE teams in particular, is that people feel free to come and go. If anyone feels walled out, or trapped in, we need to remove those barriers. When people are working with those who feed their energy and they in turn can pass it along. When the current stops flowing, it's time to do something different. Of course this prevents burnout, but more important, it keeps teams feeling alive, energetic, and fun. Find, develop, and support good people, and they will find, develop, and own good ideas."[p. 76] I think we instinctively know in KDE that good ideas are common. What is unusual is someone else stepping up to make those "good ideas" we are often given, to make them happen. Instead, the great stuff happens when someone has an itch, and decides to scratch it, and draws others to help her make that vision become reality. 

The final idea I want to present in this post is directed to all the leaders in KDE. This doesn't mean just the board of the e.V., by the way. The leaders in KDE are those who have volunteered to maintain packages, mentor students, moderate the mail lists and forums, become channel ops in IRC, write the promo articles, release notes and announcements, do the artwork, write the documentation, keeps the wikis accurate, helpful and free of spam, organize sprints and other meetings such as Akademy, translate our docs and internationalize our software, design and build-in accessibility, staff booths, and many other responsibilities such as serving on working groups and other committees. This is a shared responsibility we carry to one another, and what keeps our community healthy.

It is management's job to take the long view, to intervene and protect our people from their willingness to pursue excellence at all costs. Not to do so would be irresponsible.... If we are in this for the long haul, we have to take care of ourselves, support healthy habits and encourage our employees to have fullfilling lives outside of work. [p. 77] This is the major task of the e.V. and especially the Board, in my opinion, and of course the task of the CWG as well. 

Isn't this stuff great!? I'll be writing more blog posts inspired by this book as I get further into it.