GSoC: How can I improve next year?

For those students who are disappointed with a rejection email, here are some common mistakes and strengths we noticed. Keep these in mind to strengthen your proposal next year.

Common Mistakes:

• Did not follow directions
• Did not subscribe to and use the mail lists, IRC channels, attend team meetings, etc.
• Did not submit a final, complete proposal
• Misunderstood the project's scope, or failed to include writing documentation and tests throughout the coding period
• Poor timeline: unrealistic, or lack of implementation or time detail
• Did not take mentors' proposal feedback into consideration, or submitted too late to get input
• Did not link to commits to the KDE codebase
• Had no engagement with the community
• Demonstrated no knowledge of the KDE community's needs

On the other hand, some students have active since many months, or even a year.

Accepted Students:

• Showed extra effort, thought, and time spent on making a great proposal
• Submitted a complete draft soon after applications opened. Some even asked for feedback before that
• Improved each draft iteration with mentor feedback
• Demonstrated areas of growth and collaboration, through linked commits
• Engaged on mail lists and chat
• Engaged with the community past the submission deadline
• Detailed timeline included time for code review, unit testing, and writing documentation throughout the coding period
• Included all features planned to improve and/or implement the project
• Marked clear deliverables
• Included all other commitments, and adjusted timeline based on absences

There is no need to wait around for GSoC deadlines to get started or continue in any open source organization, including KDE.

This year, KDE had great student engagement and a good level of commitment for all students so even if you followed all of these points, you may still have gotten a rejection email. We realize that this can be discouraging. However, we did our best to pick the students whom we think can fulfill the project's needs, and continue along in the future as KDE developers.

We really appreciate all the effort and thank you for applying to KDE. Our community covers the world, and we're here to help you get started in open source development at any time. In fact, if you are interested in being mentored and do not need funding, we'll be rolling out Season of KDE in a couple of months.

Rest in peace, Ted Cowan 1926-2016

I've been a bit quiet online lately. A few weeks back, my father had a stroke, from which he seemed to at least partly recover. However, last week we found that he could not recover, and was in fact dying.

He died 12 May 2016. I wrote about that a bit here: http://genweblog.blogspot.com/2016/05/rest-in-peace-ted-cowan-1926-2016.html . I was holding his hand as he passed, as was my sister. We're both happy that he is free of his pain, but are both grieving that both our parents are now dead.

Grieving is strange. Sometimes life seems normal, but sometimes not. So I will help out when I have the energy and interest, and at other times, withdraw and recharge. Talking about this is fine in open channels or privately, if you want. This is not a sensitive subject; we'll all die in the end after all.

Challenges and opportunities

Challenges are a normal part of life; and seeing opportunities is a skill all of us can get better at. This past week, though, has been something new.

The Ubuntu community and philosophy has been home to me. The Ubuntu Code of Conduct is not just about individual conduct, but how we make a community. In fact, the first sentence is Ubuntu is about showing humanity to one another: the word itself captures the spirit of being human.[1] This is my kind of place, where we not only have high ideals, but live those out in our practice. And so it has been for many years.

So it was a complete shock to get a secret email from the Community Council to me as a Kubuntu Council member announcing that Jonathan Riddell had been asked to step down from Kubuntu leadership. We (the KC) recently met with the CC, and there was no discussion of any issues they had with Jon. They never wrote to us asking for feedback or discussion.

Jonathan's questions to the CC about a legal issue and that of funds donated to the flavors were not personal, but done on behalf of the Ubuntu community, and on behalf of us, the Kubuntu Council and the Kubuntu community as a whole. We are still concerned about both these issues, but that pales in comparison to the serious breach in governance we've experienced this past week.

The Code of Conduct states: We expect participants in the project to resolve disagreements constructively. When they cannot, we escalate the matter to structures with designated leaders to arbitrate and provide clarity and direction.

The CC did not follow this basic procedure. The Community Council is full of great people; a couple of them are personal friends. The CC was established after the Kubuntu Council, and while the KC consists of members nominated and elected by the Kubuntu Members, the CC candidates are selected by Mark Shuttleworth, and then elected by the Ubuntu Members. [2]All Kubuntu Members are also Ubuntu Members. I first stated that the CC is unelected, which is incorrect.[3] I regret the error.

The fact remains that the CC did not follow the Code of Conduct in their procedure.

We have had a number of emails back and forth during the week.[4] What has stood out to me is the contrast between their approach, and our own. They have focussed on their feelings (feelings about working with Jon), whereas we continue to point out facts and ask them to follow the Code of Conduct. Naturally, we all experienced emotions about the situation, but emotion is not a basis for decision-making.

Of course, the members of the CC may perceive the situation entirely differently.

I wish I knew how this conflict will work out long-term. The Council supports Jonathan, and continues to ask for resolution to the issues he has raised with the CC on the community list. We have done so formally yesterday.

Jon is the person who brought KDE to Ubuntu, and Ubuntu to KDE, and has always functioned as a bridge between the two projects and the two communities. He will continue to do this as long as he is able, and we rely on his faithfulness for the success of Kubuntu. He is the magnet who draws new developers to us, and his loss would spell the end of Kubuntu-the-project.

The CC did not follow the basic procedure and raise bring the issue they had with Jon to us, the Kubuntu Council. We await their return to this principle as we work to find a way forward. We are determined to find a way to make this work.

1. http://www.ubuntu.com/about/about-ubuntu/conduct
2. http://www.kubuntu.org/kubuntu-council
3. https://wiki.ubuntu.com/CommunityCouncil/Restaffing
4. https://skitterman.wordpress.com/2015/05/26/information-exchange-between-the-ubuntu-community-council-and-the-kubuntu-council/

Last chance to celebrate KDE 2014 fundraiser

Today is your last chance to get a KDE-branded exclusive postcards! Donate at the KDE End of Year 2014 Fundraising.

https://www.kde.org/fundraisers/yearend2014/

They are beautiful!

Drawing in new contributors and growing the community

It's a really exciting time to be active in both KDE and Kubuntu. So many new initiatives, projects, new collaborations. And yet.

Comment often heard over the past couple of years: we've lost $person / we're missing people to maintain/lead/do $project. This is understandable, and to be expected in a large, mature organization such as KDE; a dynamic project loses people as well as gains new contributors.

In contrast, almost daily in #kde and #kde-devel IRC channels we have new people trying to find some way to get involved with KDE. In an effort
to bring the solution and the problem together, at Akademy we
brainstormed and came up with the Mission forum.

What that forum needs is postings! When a developer is thinking
about giving up maintainership, please write a Maintainer Wanted
post. When you are fixing bugs, and see a valuable bit of code which needs
porting, please write that up and put it on the forum.

Naturally we always need ideas for possible Google Summer of Code projects, and the forum is a good place to post and develop those ideas. Eventually they will be moved to our GSoC docs, but they can be discussed and refined on the forum.

New skills needed, documentation, internationalization, translation, artwork, promo, and web work tasks are also suitable. If you have written a "help wanted" blog or mail list email in the past, dig it out and post it on the forum. Be sure to clearly outline for people how to undertake your tasks.



In fact, once Google Code-in is over, how about putting some of those tasks which remain into the forum? Those teams who didn't have time to mentor during the contest can still write up small tasks and put them into the forum as well. Once you get into the habit of creating postings, you'll be prepared and want to participate in GCi next year!

I know developers often don't like forums, but guess who does like them?
Beginners and people who are using search engines. We need these
people to join our community and start helping out. That will happen
when we ask in a public place, which is the forum.

One more time:  https://forum.kde.org/viewforum.php?f=291

Students, Google Summer of Code is coming, but not quite yet....

We've been seeing more and more questions about GSoC and how to get involved.

GSoC 2015 will be happening, but it is not yet time for orgs to even apply, much less be accepted. So we have no ideas page as yet for GSoC 2015.

That said, the best way to have your GSoC proposal accepted is to join
a team NOW and work with them on triaging and fixing bugs, and working
on old and new projects. As you work with your team members and the
codebase, you will be learn how to create a proposal which fits the needs
of the project, and also find willing and able mentors willing to guide you. Remember, mentoring is hard work. Probable mentors want to choose students they can trust to complete their proposal successfully.

The time to prepare for GSoC is now -- but it is not the time for
creating proposals yet. The important part of GSoC is embedding
yourself into your chosen project.Your energy can transform a project
from one lacking a spark into one brimming with enthusiasm. Go for it!

How to join a team:

• Find the best list(s) and subscribe, and scan the archives.
• Join the relevant IRC channels and hang out there All The Time.
• Search the forum for areas/posts where you can help out.
• Start searching https://bugs.kde.org for bugs which you can test, and fix.
• Learn how to propose your code changes to Reviewboard.

Other ways to prepare yourself:

• Read the KDE Developers manual and prepare your development environment.
• Read the GSoC Student Manual.
• As you work your way through the documentation, please fix errors you find, or update it. Remember, documentation is part of the code we provide to both other developers and users.

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.

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!

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.

Good Advice from Bad People: Selected Wisdom from Murderers, Stock Swindlers, and Lance Armstrong

Wow, what a book title: Good Advice from Bad People: Selected Wisdom from Murderers, Stock Swindlers, and Lance Armstrong, by Zac Bissonnette. I heard the author talk about his book on the Tavis Smiley radio show earlier, and it made me think about Jonathan Haidt's point about how people have wonderful advice for others, even when they themselves seem unable to follow it.

That got me thinking about some recent discussions, arguments and even fights in the KDE community in the past few months. Some arguments are exciting. You hear the deep thinking, the examination and presentation of fresh points of view, and hear people thinking together. This is what we want for every conversation! But sometimes instead, you hear criticism, to which the reaction is defensiveness. This is painful to watch, as both (or all) sides are injured, and their hurt is being ignored.

What makes the difference? It seems to me what is lacking in the second scenario is trust. Haidt advises asking people for their advice and judgement about you, and listening with an open mind and heart.  That is rather hard to do when it is your project that is being measured and criticized. Yet it is critical to success, because we often literally cannot see flaws in our processes and products that others can see quite clearly.

One thing that has bothered me for years in the whole FLOSS movement is the attitude towards users, as "lusers." I know that started out as a pun, but it seems to me that it correctly labels the orientation that developers often have. Good projects have people who use bug reports, critical blog posts and complaints on the lists, forums and IRC as feedback, in order to not just fix crashes, but to make their product better. Projects in trouble make it difficult to file bugs, or simply ignore them, and rather than viewing criticism as feedback, interpret it as a personal attack.

Unfortunately, I am seeing this defensive attitude far too often lately in KDE. This can happen within teams, when someone proposes a new idea, and then others shoot it down. I don't mean they dispute the idea, or propose a different alternative, but rather state the criticism in a take-no-prisoners way. I've also seen this after a release, when an aspect of the new application or feature is criticized by users. Rather than collaborating with the reporters, to make the application or feature better, the discussion is framed as a war by both sides. In other words, "KDE developers are dictators" vs. "KDE users/distributions/packagers hate progress".

Guess what? Wars aren't productive of good software, and are destructive to every combatant and even those within earshot. Fortunately, later I heard Ed Catmull, the co-founder of Pixar Animation Studios and president of Pixar and Disney animation, about managing creative people and his new book Creativity Inc: Overcoming The Unseen Forces That Stand In The Way Of True Inspiration. Catmull gives the credit for the success of Pixar to an open, nurturing work environment. I think we need to focus on this more in our community. It should be safe for anyone to talk to anybody. According to Catmull, at Pixar they assume that any movie is crap when they start out. But somewhere in the idea is some spark that can become great. He says,

I've spent nearly forty years thinking about how to help smart, ambitious people work effectively with one another. The way I see it, my job as a manager is to create a fertile environment, keep it healthy, and watch for the things that undermine it....The thesis of this book is that there are many blocks to creativity, but there are active steps we can take to protect the creative process....identifying these destructive forces isn't merely a philosophical exercise. It is a crucial, central mission.

He used a term I love, candor. He says that creating a safe space where people can fully express their thoughts and feelings is key to keeping creativity flowing. Of course I'm going to read this book! Here is the interview (11 minutes): kuow.org/post/president-pixar-and-disney-animation-fostering-creativity.

We already have the Team Health Check which can be found here: permalink.gmane.org/gmane.comp.kde.devel.plasma/19755. I'll use Catmull's book to look again at that team tool, and see if it can be improved.

For now, I hope that before any of us speaks or writes, we'll think about our choice of words. Candor is crucial. Remember though, that feedback can be framed as helpful information, or as an attack. You might mean your feedback as helpful, but can it be read as harsh criticism? If so, please edit before publishing. Developers, think about how to invite candor, by asking others for their honest feedback. Welcome reports of problems, bug reports, and respond in a collaborative way. If you need someone to triage bugs to keep sane, ask for that help! Everything you can do to lower the barriers to honest criticism, the better your work products will be.

Prospective GSoC Students: Now is the time to submit proposals

Greetings to all you students we've been talking with in IRC (#kde-soc and your chosen team's channel(s)) and on the mailing lists. By now, hopefully you have met and talked with your teams, and begun formulating your plan for GSoC, with advice from your prospective mentor(s).

I hope you have followed Myriam's advice and done your homework. If you have worked on some junior jobs, have your KDE developer credentials, joined the necessary lists *including KDE-soc*, you have a good foundation built.

Pro-tip: always check out the links in the /topic of your IRC channels. The #kde-soc channel topic is particularly rich.

Many prospective mentors hang out in that channel, but not all. Us admins are there as often as possible as well. I'm always willing to help edit a proposal for grammar, spelling, organization, formatting, etc. And I can be brutally honest, so if you ask my opinion, be aware that I won't waste your time with anything but the truth.

Now is the time to log into melange, and submit your proposals. If you have not yet had a team member vet your plan, give them the link to your melange proposal and ask. Don't waste their time with mere ideas; you need a clear plan of action, and a realistic timeline.

Go, go, go!

Changing behavior

I just finished a book called The Science of Consequences, by Susan M. Schneider. A couple of items in the Glossary struck me as interesting (yes, I'm the sort of person who reads the glossary and endnotes!).

Negative: If a behavior declines because of a consequence, that consequence is a negative (a punisher, an aversive) and the relationship is punishment. (Note that the negative can be an outcome involving the removal of a positive....)
It's important to note that things that seem like negatives sometimes aren't; what matters is what actually happens, not the intention or the appearance.... "Negatives" that have no effect on a behavior are not truly negatives; indeed, if the behavior is strengthened, they are reinforcers. Again, it's what actually happens that matters. [p263]

Reinforcement: When a consequence sustains a behavior, the relationship is reinforcement....The consequence can be an outcome involving the presentation of a positive, or the removal of a negative, or both simultaneously. [p263]

These are good things to keep in mind as we interact with others in life, and in our projects. Things go well when there is a ratio of 5/1 positive/negative. Things go badly when that ratio is reversed; you see divorces, the end of friendships, and forks in projects.

I'm mostly publishing this to remind me to pass along compliments, and remember to thank people for the good work they do. Thanks should outnumber bug reports and other complaints FIVE to ONE!

Confrontation is scary! Confront your fear.

One of my recent CWG (KDE Community Working Group) emails said, in part:

...the confrontation seems to have clarified some issues...

Of course! That is what confrontation is about. It isn't necessarily a power struggle, although it's usually seen that way. Confrontation, argument, fights are all about issues. Of course sometimes the issue is power, and access to resources, but more often the issue is about how to get to a shared goal or value. Confrontation is best and most productive when it clarifies: How can we best collaborate?

Arguments aren't bad! They bring issues out in the open. And if people learn to 'fight fair' - focus on resolving issues, not people, not positions, then stuff gets done. Even if you aren't directly involved in an argument, sometimes your part is to remind the 'opponents' of that, and support them as they 'get to yes.' If there is anger involved, it's good to be able to blow off steam without injecting that heat into the argument itself. Often a friendly ear is invaluable there.

I think confrontation is scary to people because most of us are taught as children NOT to confront, but to obey authority. This is understandable from the parents' point of view, but over the long term, people need to learn confrontation, negotiation, and fighting fair. As a parent I tried to teach my kids how to fight fair --even with me. Because mama is not always right.

I've only been in the community for a few years, so I can't compare 'the old days' to now. The KDE, Kubuntu and Ubuntu communities are spread all over the world, with people from a lot of different cultures; it would be amazing if we had no misunderstandings, spats, fights, disagreements. It is my hope that we all learn to do this better, and remember to be respectful during the struggle.

The Codes of Conduct are our support here. A CoC is often seen as a club, or a codification of law, which I think is wrong. Re-read your CoC, and I think you'll find that it is a description of the community we want, and the way we want to work. I hope to see fewer mentions of "CoC violation" and more examples of living up to our shared ideals. Read 'em again:

KDE Code of Conduct: http://www.kde.org/code-of-conduct/

Ubuntu Code of Conduct: http://www.ubuntu.com/about/about-ubuntu/conduct

Linuxchix boils it down the best, I think. Two rules: Be polite, and be helpful.

The Decipherment of Linear B

This wonderful little book has been recommended quite a few times by my friend Sho_. Today it arrived from the library, and I'm so happy to have read it. Yes, it's slim and readable; with afterward and appendices less than 150 pages. It's a loving tribute to Michael Ventris, who 'broke the code' of Linear B, then died before his publication presenting it to the word, by his co-author, John Chadwick.

Why a book on such an obscure subject? Yes, it's about Mycenaean Greek! But more important, it's about how a young person with an interest in languages and training in architecture (Michael Ventris) could use this background to crack one of the biggest mysteries revealed by modern archaeology. And he contradicted the leading experts and prevailing opinion that Linear B could not be Greek. When he proved that the Mycenaeans spoke Greek, he pushed the beginnings of European history back many centuries.

Ventris won over the experts by doing careful analysis, and always sharing his work as he proceeded. In fact, after reading all the published research, he began his work by surveying the twelve leading experts with a series of questions. This questionnaire was penetrating enough that he got ten answers. After compiling these answers and adding his own analysis, he sent out the survey results to all the experts. By getting a good grasp of current scholarship, he had built a wonderful foundation on which to build his study of the inscriptions.

Although it has not been proven that Ventris did any code-breaking during the war, his method of analysis certainly owes much to that Bletchley Park work. Also discussed here is Alice Kober, whose early work set Ventris on the right path. Her card catalogue was invaluable to Ventris, after her life was cut short by cancer. Ventris always consulted other experts, and was generous in sharing credit. He never succeeded in proving what he set out to do, which was prove that Linear B was Etruscan. Instead, he put in the hard work of analysis of all the evidence, and followed the trail to the end, proving what he started out believing impossible: Linear B is ancient Greek.

Read this book, and be inspired! Grab it used or get it from the library as I did. Although available for Kindle, the symbols render badly in that edition.

Catalyst Leadership

I read a list post thread tonight that saddened me. I won't say what community it is part of, or point out the participants, because it is far too common in many of our community meeting places, whether they be lists, IRC or forums. Stereotypes are used rather than names here.

Newperson speaks up, I think for the first time, wondering when a new project result will be put to use, and offering a possible sample.

Longtime Devel speaks up, using rather angry questions about how the old symbol came to be displaced.

Another Oldtimer speaks up defending the symbol, accusing Longtime Devel of being out of touch.

And on. And on. The listowners don't redirect the discussion, and when questions are asked, they are answered angrily.

Newperson probably has departed by this point.

This seems like a small occurrence, but it is bad for every single participant, and each bystander has the power to change the conversation at each point.

This blog is a call for each of us to think about our power to influence the community spaces we inhabit, to exercise leadership, to become a catalyst for dialog, to open up trust. When I was first asked to become an IRC channel operator, I was asked to read the Freenode Philosopy: Catalysts. Whether or not you use IRC, I recommend reading this page to change your thinking about how you interact with others in your free software project. In fact, these ways of thinking about personal interaction would transform business, education and politics if put into wide use.

We know that bullying in schools can be brought to a stop by bystanders who show the courage to immediately speak up on behalf of the victim, and walk away from the confrontation. While I don't want to label those who use abusive language as bullies, we can transform tense situations in similar ways by speaking up in a positive, calm manner, as outlined in the Catalyst page.

Labeling people as trolls doesn't defuse the situation, or create an atmosphere of trust and dialog.

Please folks, if you are in an IRC channel, on a list, or help out on a forum: read the Catalyst page, and remind yourself often to be the change you want to see in the world. You don't need to be an op, a listowner, or a moderator, to be a leader; bloom where you are! Our Codes of Conduct aren't bludgeons to be used against evildoers; rather they are guides to our everyday interaction with one another.

New to the commandline? Don't lose heart

Beginners, you are not alone! Many of us have tried to work through problems, only to be stymied when the steps to work through the problem don't work, and efforts to google those error messages yields nothing helpful. In fact, that's why I started this blog; not just to remind myself how to fix various problems, but to point the way to others who are trying to learn the way to CLI-foo.

A word to the wise who are trying to help beginners -- please don't leave out "obvious" steps!

I'll illustrate with a recent experience I had, trying to help a user work through a problem using Krusader.  A bit of googling told me that s/he wasn't alone; there are bugs filed on both launchpad[1] and bugs.kde.org[2]. First, kudos to the unnamed person for asking for help in IRC. That's an excellent place to get step-by-step help.

In the launchpad bug, a helpful person posted a series of step to fix the bug by building an updated version from source:

Made my own deb from 2.4.0.beta3 which solved the `krarc` problem.
How to:
0 Uninstall Krusader
1 download source from http://www.krusader.org/
2 cd krusader-2.4.0-beta3
3 cmake -DCMAKE_INSTALL_PREFIX=/usr/ -DQT_INCLUDES=/usr/share/qt4/include
4 make
5 sudo checkinstall
Don´t forget in step 5 to set version on 3 instead of beta3, only digits are allowed in versions in debs nowadays.

The unfortunate user came back into IRC, and posted this error message:

xy@xy-ubuntu:~/Downloads$ cmake -DCMAKE_INSTALL_PREFIX=/home/user/app/krusader-2.4.0-b3-2 -DQT_INCLUDES=/usr/share/qt4/include
CMake Error: The source directory "/home/jony/Downloads" does not appear to contain CMakeLists.txt.

Having struggled through this process myself, I see what's missing in the instructions. The person posting them didn't realize, I'm sure, that steps were being left out, because they have become automatic. To a beginner, they are bewildering.

Step zero, uninstall, is unambiguous. So far, so good.
Step one, download source, leaves out the best practice, which is to create a directory into which you want your source file! Probably not specified as people have their own schemes of organization, but in general, I advise a ~/kde folder into which I put all source files and builds (thank you for your advice on that, Myriam!)

So step one should be: a) open a konsole, and type or paste: mkdir kde && cd kde && mkdir krusader && cd krusader && wget http://downloads.sourceforge.net/krusader/krusader-2.4.0-beta3.tar.bz2
Then, step b) tar xf krusader-2.4.0-beta3.tar.bz2

Then, do step two, which is correctly stated as cd krusader-2.4.0-beta3

Step three is almost all there, with a missing note: be sure you have cmake installed! My bet is that my troubled user did not.

Cmake ran uneventfully, as did make, so steps three and four are perfect. Step five, however, does not work at all for me, because I don't have checkinstall installed. And I don't think I'll do that for the sake of finishing this blogpost! I don't need a deb file, when Krusader is available from source.

I hope our Kubuntu packagers will get the newest version packaged soon, and make it easy for my troubled user.

1. https://bugs.launchpad.net/ubuntu/+source/krusader/+bug/1065110
2. https://bugs.kde.org/show_bug.cgi?id=294542

Promote Lamarckian evolution through GSoC

A short TED talk by neuroscientist Vilayanur Ramachandran inspired me to blog one more time about our upcoming Google Summer of Code project. Whether you are thinking of applying, are preparing to mentor, or are part of a team with some project ideas, give a listen (it's only 7:44 minutes) about how we are literally built to teach and learn from one another. http://www.ted.com/talks/vs_ramachandran_the_neurons_that_shaped_civilization.html?quote=628

What caught my ear was his comparison of Darwinian evolution, which is very slow, with Larmarckian evolution, which can leap ahead, exactly as our culture does. The students who struggle in GSoC, are the ones out of touch with the team, and with their mentors. Sometimes it is the students who withdraw contact when they're in trouble, and sometimes mentors are the ones who are not staying in touch. Either way, the team can notice what is happening, and in a friendly, helpful way, draw the two back into contact.

Success happens when we communicate, because that's how learning happens. Students, when you encounter difficulty, please remember to get into the IRC channel, and if no one answers, write an email. Don't wait a day; don't wait an hour. The summer rushes by and you need all the time so that you can relax and do good work.

Mentors, please experiment with your student at the beginning of your bonding time, what forms of communication work the best for the two of you, or three of you if you have a mentor team. Google hangouts or other voice chats work, as long as someone writes an email summing up the understanding of the road ahead. IRC is important for the team, and students can get a bouncer account by asking the KDE sysadmins once their developer accounts are in place.

Stay in touch! As Vilayanur Ramachandran says,

There is no real independent self, aloof from other human beings, inspecting the world, inspecting other people. You are, in fact, connected not just via Facebook and Internet, you’re actually quite literally connected by your neurons.

So work with your brain, and stay connected.