KDE accepted for Google Summer of Code 2011

I’m thrilled to be able to announce that KDE once again will be taking part in GSoC this year. This is our 7th year in the program. Also check out the other 174 orgs – great projects! Let’s make this a rocking summer once again.

If you are a student now is the time to start working on your proposal. You can either come up with your own idea or get inspired by the ones on our ideas page. Once you know what you want to work on start investigating and write your proposal. Get feedback from the team you want to work with regularly. If you want to write a proposal for your own idea I urge you to get in contact with the team very soon to make sure it is something they want and to get input. If you have questions you can always come to our IRC channel #kde-soc on freenode or join the mailing list kde-soc@kde.org. For details about specific ideas try to contact the respective team directly first via their IRC channel or mailing list please. For more general information about GSoC please visit http://www.google-melange.com – pay special attention to the timeline.

If you are a mentor your next steps are: 1) subscribe to kde-soc-mentor@kde.org  2) sign up on http://www.google-melange.com and apply as a mentor for KDE  3) contact one of the admins to approve your requests. For questions you can reach the admin team in #kde-soc or email them at kde-soc-mentor-owner@kde.org. And of course you’ll have students approach you with questions about their proposals 😉  Below you can find a flowchart with the most important steps of the program. Please check the timeline of the program.

Flattr this

Code-in 2010 – amazingly useful and stressful

For the last 1,5 months I’ve been herding cats for Google Code-in as the KDE admin. For those who are unfamiliar with Code-in: It’s a contest for 13 to 18 year olds to get involved in free software projects, one of them KDE. Today Code-in ended and the students (and mentors and me!) can get some rest 😉 And for me it’s time to write a wrap-up.

Boy, did the students rock! 300 closed tasks was my personal goal and in the end 338 where closed for KDE. Among them things like handbook writing for Amarok, bug triage for KHTML, coding on Marble, Rekonq and others, doing cool video clips for promo and edu and much much more. You might already have seen some of the work on PlanetKDE and more posts will follow. It’s been an amazing ride.

Let me write a bit about KDE’s experience. I’ve asked the mentors to tell me what they liked and didn’t like about the contest. First of all nearly everyone agreed that this is a really cool program. I don’t think we’ve had one before where we got so much done in such a short time with such a largely high-quality output. It’s a great opportunity for students to get to know high-profile free software projects with clear tasks for them to work on. It is great to see how some of the students gain confidence with each task they do and are proud of what they achieved. For me personally the hardest part was having to tell some students that their work wasn’t good enough yet – that they should push themselves a bit more (which they always could). Code-in being a contest encourages students to rush. This is great because it gets so much done but it needs mentors to keep an eye on quality with some students. That being said I was thrilled to see the first very good patch come in only a few hours after the contest had opened.
The other thing that made this a very demanding time for me is the fact that both students and mentors needed an enormous amount of hand-holding with the web app. It’s the same application that is being used for Google Summer of Code and I know it’s quirks and can probably navigate people through it while sleeping by now but new mentors and students had a lot of problems with it and needed help.

For future versions of the contest I’d like to see a few improvements that would make the life of mentors, admin and students a lot easier. Currently a student could only work on one task at a time and needs to wait for his mentor to approve the task before he could claim the next task. Then he has to wait again until the mentor of that next task approves his request and he can start working. This system is very demanding for a contest. It could be improved by allowing students to claim their next task once they have submitted the result of their current task. But as we’ve already learned with GSoC and Season of KDE: mentoring takes time and is demanding – in Code-in doubly so. The other major bottle-neck (which I think/hope I managed pretty well) is the admin. He/she needs to approve every single task the mentors suggest in the web app before students get to see them. This is good to make sure the tasks are ok, are not too easy or too hard and have enough details for the students to start working on them. However it also means that I’ve constantly had mentors and students pinging me to approve tasks. If you don’t have a very attentive admin this is not ideal – given that the contest ran over Christmas this probably happened in a few orgs. Next time I should probably try to get more people for screening tasks.

Oh and one last thing: the naming is a bit unfortunate. I’ve had to explain multiple times that Code-in isn’t actually just about code but also artwork, translations, promotion, testing and much more.

To sum it up Code-in has been an amazingly useful and stressful experience. We’ve gotten a lot of those things done that everyone of us has on their todo list but just doesn’t get around to but that make a huge difference for the project. And of course we gotten an opportunity to introduce a lot of new people to our community. I hope each of them stays around and continues to do awesome.

I’ve been admin for GSoC and SoK (with great help from Leo, Jeff and Ian) for 4 years now and this time also for Code-in. We’ve improved it together with pretty damn amazing mentors and students and I think we’ve reached the point where we can be really proud of our mentoring programs. I’m convinced that they are among the best out there. However I’m also convinced that we can still do better. Two days ago I had a long call with Jos. During that call I realized that we’ve reached a point where I think to make them any better it needs new eyes and fresh ideas. In addition I have the feeling these programs depend way too much on me being around which is always a bad sign. So in order to get some help and fresh ideas I’m looking for someone to help with running the next GSoC and SoK. If you’re interested let me know. I’d be delighted.

Flattr this

call for 4.6 release parties

A new major release is around the corner and it’s time for all of you to help with KDE release parties around the globe. This is a guest blog by my Google Code-in student Sasu.

It’s been over four months now from previous major release by KDE and it’s time for a new one. 4.6 is about to be released on 26th of January and it is party time again! Release parties are very fun and educational for visitors. If your party has represented KDE well you can even get new local KDE community members.

Although organizing KDE release parties costs some time, it can be a very good experience. Release parties bring the local community together. With a stronger community, organizing the next event will be a lot easier.

release parties, basic info

If your local community is not very big the release party can be just having a beer at a local pub (the writer doesn’t have any experience on that… obviously) with friends. However, if you do have a large local KDE community, you can go as big as you want… and can.

If there are people new to KDE, remember to explain and introduce KDE to them first. Release parties should be fun, that’s the main purpose of them. Parties ain’t parties if you just sit and talk seriously. Participating in parties should be a great experience and worth everyone’s time.

To put it simply, all you need for a party is people at same place at same time. However, you most likely need someone to organize the whole thing. The place depends on party size and program. For smaller events a local bar or restaurant is fine. If you are coming with a bigger group, remember to contact the place and reserve a table. You can also advertise the event at IRC channel topics, microblogging services, blogs and even at Facebook. Most importantly, add your party to the KDE 4.6 Release Parties information page: http://community.kde.org/Promo/ReleaseParties/4.6

You can start by everyone introducing and tagging themself for example. After that you can have a preselected topic to talk about at first. If the event is bigger, you need to have a little more specific program to follow. Talks maybe? Games?

Release parties indicate how strong and active the local community is. According to the KDE Community Wiki, there were 26 release parties for 4.5 in twelve countries including Argentina, Austria, Brazil, China, Czech Republic, Denmark, Germany, Norway, Romania, Spain, Switzerland and the United States. If your country isn’t listed here, like mine isn’t, you can change the situation for this release!

Have nice parties! Organize one now!


Like in the software development, user experience (What now? Visitor equals user for me :P) is the most important part of release parties. At this point, you may want to hear a few words from people who participated in one of many 4.5 Release Parties.

Michael Leupold, where and when did the release party that you participated in take place?
It was held in Stuttgart, Germany. The place is called “Letzte Instanz” and it’s located in Untertürkheim.
How many people took part in the party?
13 developers, translators and users. They came from all over southern Germany.
What did you do at the party?
We enjoyed food, drinks and ourselves. Actual release was unexpectedly delayed till after our event (effectively making our event a pre-release event), we still had a great time talking about KDE and getting to know each other.

Valorie Zimmerman, where you had your party and in what group?
I met with the LinuxChix Seattle, at the Caffé Vita Coffee Roasting Co. on Capitol Hill in Seattle.
How many of you were there? How many of them was a KDE user already?
We had three women attending. I was the only Kubuntu/KDE user.
What did you do there?
We worked on creating a bootable USB key, sipped delicious coffee and nibbled wonderful mini-cupcakes.
Pics or it didn’t happen.
Sorry, I forgot to take a picture.

in the middle of Code-in…

Google Code-in has been running for nearly 3 weeks now and we have another 4 weeks to go. I wanted to give a short status report.

First of all: The students are amazing! They’ve produced really really cool stuff in a very short time.  Let me highlight a few of the things that students did so far:

  • Translations: lots of them. Two of the translation teams came to me and said their team was not active recently and Code-in has brought back life into the team. Especially the Russian, Romanian and Polish translations will be a lot more complete for the next release.
  • Short movies: a particularly inspiring ad for KDE was posted to the promo list. It will be improved in the next days and then published. Check it out when it hits PlanetKDE!
  • Screencasts: lots of them. Really cool short intros to features of KDevelopKonqueror and more.
  • Posters and hand-outs: Amarok finally has a nifty poster for the booth at conferences. KDE-edu will get a nice hand-out soon.
  • Documentation: We’ve been meaning to write Amarok’s handbook for ages and slowly been getting there. In the last 3 weeks 5 or 6 students have nearly finished it. Parley got a step-by-step guide showing you how to prepare for an exam with it.
  • Code: Students have been coding all over the place. Check out the Marble earthquake online-service for example or the moodbar generator. You’ll also be able to enjoy new ready-made Plasma activity templates that you can download via GetHotNewStuff.
  • Podcast news: a student will be reading the news segment of the next episode of KDEMU with Guillermo.

There’s a lot more but I can only list so many. Right now we have 113 finished tasks. 32 tasks are being worked on and 50 tasks are up for students to claim and start working on. Rock on!

Google Code-in runs until January 10th. I can still accept tasks. Let me know if you want to mentor or take part as a student. I expect an influx of students over the holidays. Help me not run out of tasks – those 50 will be gone fast 😉

Google Code-in – KDE is in!

KDE has been chosen as one of 20 organisations to mentor students for Google Code-in this year. Wohoooooo. We’re looking forward to working with a bunch of 13 to 18 year olds 🙂 Let’s see how they’ll rock our world. And the most awesome thing: It’s not just about code this time but also documentation, outreach, quality assurance, research, training, translation and user interface.

We’ve been collecting task ideas in the wiki. These tasks need to be transfered into Melange (the webapp that is used for GSoC and Code-In) now. So if you proposed a task there I’ll email you shortly with instructions. If you do have an idea that so far is not in the wiki and you’re willing to mentor it then please email kde-soc-mentor-owner at kde.org with the details.

The students can then start claiming tasks from different organisations starting 22nd. The contest runs until January. Students can claim one task at a time and have a certain amount of hours to complete it. If they complete tasks successfully they get 100$ for each 3 tasks up to 500$ max. And there is a trip to Google’s HQ for the 10 best students \o/ For more details check out the FAQ.

If you’re a student and interested in taking part in Code-in feel free to hang out in our IRC channel #kde-soc on freenode and join our mailing list kde-soc at kde.org if you have questions.

I promise we don’t bite – just like this fellow I met 2 weeks ago on Google’s campus 😛
2010-10-24 11-45-18

Google Code-in preparation

Google Summer of Code has been a huge success for KDE in the last 6 years. Google is now accepting applications for Google Code-in. It is a contest for high-school students aged 13 to 18. Students can work on tasks in 8 different areas:

  • Code: Tasks related to writing or refactoring code
  • Documentation: Tasks related to creating/editing documents
  • Outreach: Tasks related to community management and outreach/marketing
  • Quality Assurance: Tasks related to testing and ensuring code is of high quality
  • Research: Tasks related to studying a problem and recommending solutions
  • Training: Tasks related to helping others learn more
  • Translation: Tasks related to localization
  • User Interface: Tasks related to user experience research or user interface design and interaction

and tasks are categorized as easy medium and hard. Students will be able to claim those tasks and work on them for a given timespan. After that the mentor can decide if the task was successfully completed or goes back into the pool for other students to claim it. Cool prizes are waiting for the best students at the end of the program.

For KDE to have a chance at taking part in Google Code-In this year we need to prepare an ideas page with a lot of great ideas to claim during the program. Please help me fill this page before Friday: http://community.kde.org/GoogleCodeIn/2010/Ideas Go Go Go!

If you want to find out a bit more about Google Code-In you can check http://code.google.com/gci or come to our info session on IRC this week. (Akarsh will blog more about it soon.)

It’s Roktober!

2010-10-02 13-44-56

It’s getting colder outside and like in previous years it is time for the Amarok team to look back on the past 12 months. It’s been an astonishing ride including over 4000 commits, a Quick Start Guide and 6 new releases of Amarok.

Now this would not be possible without financial support from our users. This is why we are calling for your support during this year’s Roktober again. We are aiming to raise 5000 Euro to pay for our server and the team’s expenses during development sprints and trade shows. You can help us with that. As a sign of our appreciation for your support we will add donors agreeing to this to the About Dialog of each Amarok release in the next 12 months. Help us Rok the World and get your share of Amarok 😉

You can find more detail about how to participate at http://amarok.kde.org/en/roktober/2010.

A big Thank You! from the whole Amarok team.

Designed not to scale

(This is the second guest post by Asheesh Laroia of OpenHatch, an “open source involvement engine”. OpenHatch is a website and ongoing project to help new contributors find their place in free software projects. If you like this sort of thing, you could subscribe to the OpenHatch blog.)

Now we'll never find him   (Explore)

For most open source projects, just one new contributor would mean a huge increase in energy. As a team member, what can you do to find that person?

Typically, we configure computers to converse with prospective helpers. This “scales” — a new contributor requests a page from your wiki or searches the OpenHatch volunteer opportunity finder, and you don’t have to do anything at all. If things work out, the patches flow in.

This time, I want to talk about outreach strategies where human effort is the bottleneck.

Fedora Design Bounties

With the aim of bringing in one new contributor, Máirín Duffy sometimes writes a “Fedora Design Bounty”, a long description of something she could do herself.

Look at the first one and you’ll get a sense of the process she underwent. She created a splashy web page and discussed a specific issue at length (rather than simply linking to a ticket). She singled out a specific task for a newcomer and provided context showing why it was important that the work gets done. In the “What’s in it for you?” section, she explained how you’ll totally be cooler if you do it. Finally, she made it a contest: anyone can try working on it for 48 hours, and if they don’t succeed, the next person in line gets a shot.

Then she crossed her fingers in hope, hit “publish”, and waited anxiously.

In this case, there was an outpouring of response. Within only a few hours, a fellow named Jef claimed the “bounty”, and a few days later, Máirín congratulated him on the success.

From one perspective, her actions were incomprehensible. If she wanted someone to help her, why didn’t she just file a ticket in the Fedora Design Trac? If she wanted to publicize it, why spend hours writing all this up and making a contest when she could have just blogged a link to the ticket?

And all this time, Jef could have applied his design skills to the team’s work by looking for a suitable ticket in the tracker. Why didn’t he?

There are some intriguing aspects of her strategy:

  • Her request for help feels unusually human. She spells out the tools to use and documents to read. That kind of information (and tone) isn’t even appropriate for a ticket tracker.
  • By creating a time-limited contest, she creates a sense of urgency. Hers is an opportunity for self-improvement, not a red “Overdue” marker in a bug tracker.
  • She worked to put her request in front of lots of people. It hit Planet Fedora, Planet GNOME, and her microblog.

And it worked. She’s created lasting contributors. Jef and Emily, the two successful “ninjas”, have gone on to contribute to the Fedora Design Team in other ways. (Jef even landed an internship at Red Hat!)

A supportive environment with friendly people and “borrowed” resources

In college, I led the Johns Hopkins Association for Computing Machinery, our computer club, for a few years. When I was chair in fall 2005, students’ computers in dorms could not run servers; the firewall would block inbound connections to them. One enthusiastic-yet-timid freshman came by and seemed like he wanted to tinker with running a Linux box. The ACM office is a great place for that, and we had spare hardware on shelves. But we were running out of IP addresses, and most existing machines were too critical for me to hand out root access to a freshman.

We lucked out when we found a discarded computer in the hallway. A sticker declared its hostname, sea.cs.jhu.edu. We brought it back to the ACM office. Since no other machine was using that IP address, we decided to keep using the address until someone complained. So we plugged it in, installed a fresh OS on it, and he got to fiddling.

Now, five years later, he’s a developer in DragonFly BSD and contributes patches to Ogg Theora, Plan 9, and a host of other projects.

The presence of Linux geeks in the ACM office provided an environment that encouraged asking questions and trying personal projects.

What if the ACM had been inactive? The restrictive Hopkins firewall would have blocked his ability to experiment with SSH and learn about UNIX-like systems. And the spare (albeit dodgy) IP address meant that the ACM sysadmins were never tempted to re-purpose the machine to serve the entire ACM membership.

(Also, I think that IP address is unused again…)

What I take from these examples

Fedora Design Bounties and incubating students in the computer club are time-intensive activities. At a great amount of effort, locked within a short period of time, they reach a tiny number of people.

But for that small number of people, they can have a huge impact.

For a project leader like Máirín, one new contributor can boost the energy level of the community. With that as her goal, working hard to find that new contributor makes perfect sense. I believe there are other projects in similar situations, so Danny Piccirillo and OpenHatch are incubating a similar project called Starling Bounties. To prove to the community it can work, we’ll take on the writing effort.

For me, watching people “get it” has always been rewarding. Not all students have access to a support network knowledgeable about open source. So this past weekend, I visited the University of Pennsylvania to try to create one there. With help from other teachers, we gave 30 students hands-on instruction in GNU/Linux, IRC, git, and other concepts key to open source participation.

These mechanisms can only grow as fast as humans pour effort into them. When you want a substantial change from someone, a costly signal shows dedication.


After reading all these words, you must be exhausted. Go get yourself a glass of water.

For you lovely readers who stuck it out this far: What do you think of the Fedora Design Bounties? Would you be interested in trying a Starling Bounty with your own project? And I want to hear about the fun things you do to help grow the free software community, even if they “don’t scale”!

OpenHatch: Making the first step easier

Baby, originally uploaded by gabi_menashe.

(This is a guest post by Asheesh Laroia of OpenHatch, an “open source involvement engine.” OpenHatch is a website and ongoing project to help new contributors find their place in free software projects. A few months ago, he imported some bugs in KDE’s bug tracker into the OpenHatch volunteer opportunity finder. I invited him to write about it for my blog. OpenHatch has its own blog, too.)

KDE is doing something wonderful with its Junior Jobs. These are issues (often small feature requests) that are appropriate for a first-time contributor. When maintainers create these opportunities, they take information that would otherwise be trapped in their head — how easy or hard an issue is — and make it available as hint to new contributors. Conveniently, creating a “Junior Job” doesn’t take any special work: maintainers just have to find the relevant bug in KDE Bugzilla and add the junior-jobs keyword.

But KDE Bugzilla isn’t necessarily a friendly welcome mat. Probably everyone reading this post can remember a time when Bugzilla seemed like a difficult, arcane tool. Bugzilla works well (enough) as an interface for project maintainers to share the status of what they’re working on with each other.

But imagine you are a prospective contributor. Aim your web browser at the list of junior jobs. (To get that link, I went to KDE Bugzilla and clicked the “Junior Jobs” link on the left side.) This is what I saw when writing this post:

Here are some questions I might have as a new contributor (and some commentary as myself):

  • What do “wis” and “UNCO” mean?
  • Who is JJ? (Maybe that’s a person’s initials; maybe he or she plans to fix it.)
  • What project are these bugs in? (I can guess from the assignee….)
  • Where do I get the source code? (The wrong answer might lead the new contributor to submit a patch against the most recent release; that patch might not apply against trunk.)
  • If I get started on this, who can help me when I get stuck? (Otherwise, a new contributor might make an effort, become confused by something, and fall away.)

I like to joke that bug trackers say lots of information about what the problem is, but they don’t provide any information on how to solve it.

We at OpenHatch noticed that a great number of projects were in a similar situation: they label bugs as “easy”, “bitesize”, or “Junior Jobs” and point first-time contributors straight at the bug tracker. So we created what we call the volunteer opportunity finder to help people find something to work on. It wakes up late at night to download issues from bug trackers representing hundreds of projects. (Since OpenHatch is itself a free software project, we also import the bitesize bugs from our own bug tracker.)

When you browse the available issues, you can click on the project name and see its page on OpenHatch. (We make one for every project that someone says they’ve contributed to, or where we’ve imported bugs for it.) The pages showcase the people who have listed themselves as possible mentors. Contributors can also write instructions or suggestions for how to get involved; for example, the page for Gally does a great job of answering “Other than writing code, how can I contribute?”

If you don’t know how to get involved, you can also browse opportunities by programming language, the kind of help you want to give (such as writing documentation) or flip through a few projects you might want to work on. You can narrow your search to just the ones we call “bitesize” (“Junior Jobs” in KDE, bugs labeled as “easy” in the Python programming language, and so forth).

So OpenHatch is a project to think through how people join free software communities and to build technical tools and social structures to make that better. This browsing tool is one thing we’ve built. It’s a community project, so you can help out! Say hi on IRC or email if you want to join in.

I’d like to hear (in the comments on this post) from you guys and gals: What do you think about our “volunteer opportunity finder”? What works about it for you? What would you change?

If Lydia invites me back, I plan to write about getting non-coders more involved in free software projects. During the weekend I first met Lydia and Jeff Mitchell of Amarok, I had a crazy idea for something you can build on top of OpenHatch. If you want to stay in touch until then, join our IRC channel or subscribe to us on Identi.ca/Twitter/RSS!

KDE GSoC 2010 wrapup

Google Summer of Code 2010 finished. It’s been a blast again for KDE. Of our 50 students 46 completed the program successfully and one withdrew after successful midterm evaluation to start an internship he couldn’t say no to. Each of them has produced something really cool, has learned a lot and I’m sure also found a few new friends. Check PlanetKDE for updates on their projects. Thanks to each of our students and thanks x2 to our amazing mentors who once again rocked very much. And of course thanks to Google for making the whole program possible. A dot story including details about each project will follow soon – stay tuned.

Season of KDE hasn’t wrapped up just yet. Updates on that when it finished.

Oh and if you want to hear me ramble about GSoC and Season of KDE with the awesome Guillermo and Paul, go and listen to the latest KDE and the Masters of the Universe podcast.