AmarokBlog – Page 5 – life at the end of the universe

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!

Experiences

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 KDevelop, Konqueror 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 😉

Join KDE for Google Code-in!

Google Code-in is a program for 13 to 18 year old students to get involved in a number of Free Software projects, among them KDE. You will get a cool mentor from the KDE community and work with him or her on exciting tasks. Check out the over 100 tasks that are available currently. We will be adding some more in the next days. There are tasks for nearly every area of KDE. You can find translations, coding, artwork, outreach, research and more among them. Some examples: Help Guillermo prepare a news section for his KDE podcast, help Frederik solve a tricky code problem in Parley, help me figure out how to better present KDE on OpenHatch and much more. Found a task you like? Claim it and wait for your mentor to approve it. And then you can start being part of a team that changes the world one step at a time. Get started walking! 😉 If you have questions join our IRC channel #kde-soc on freenode or ask on the mailinglist kde-soc at kde.org.

There are prizes involved as well. Students get 100$ for each 3 tasks they finish successfully up to 500$ and the 10 best participants get to go to Google’s headquarter in Mountain View. (It is pretty damn awesome there I can tell you.) A little birdie tells me there are t-shirts involved as well. Go go go!

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 😛

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!

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.)

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.

Thanks

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.

unicorns and laser beams

As part of my computer science studies I needed to work on a research project which I finally finished not too long ago – the title: “Planning of 3-dimensional complex cutting trajectories for robot-assisted surgery”. I worked on a program for a robot-assisted laser surgery on bones (in particular the human skull). It’s written in C++ using Qt and VTK. My task was to work on the planning module. The surgeon can mark points on a model of the patient’s skull and then connect them either with straight lines on the skull or create more complex connections. This was then used in another module to calculate positions and movements of the robot that was handling the laser. Laser beams ZOMG! All this will hopefully help make skull surgeries safer and less invasive as well as allow surgeries currently not possible due to tool limitations.

Despite having contributed to KDE for a few years now pretty much all over the place this was my first really big C++/Qt coding experience. I’ve not really touched KDE code in all those years except a few small changes here and there. Unbelievable right? Not really. On the one hand I think that so far KDE was better served with me doing community work – and maybe always will? And on the other hand it was damn scary. Oh and of course there was no pressure to climb that rather huge imaginary mountain and learn all the stuff I’d need to actually be any useful in that area. This university project helped quite a bit with both now 😉 This is btw also one of the reasons why I think GSoC is so invaluable: It gives the needed pressure and incentive to not give up when things get tough that some people (including me) need.

The robot, laser head and a plastic skull:

Cut on the plastic skull:

Cut on a part of a pig’s bone:

And the actual planning program:

Thanks to Jessica, my advisor, for having patience and letting me screw up a few times. Thanks to everyone working on Qt and VTK for letting me do amazing stuff.

Guess it’s time now to find a good KDE project to get my hands dirty on. Be warned 😀

Oh and next time a new contributor vanishes: Nudge them a bit. They might just be standing in front of that huge imaginary mountain and need someone to tell them it’s not actually that huge or give a helping hand. And if you’re standing in front of it yourself right now: Don’t give up! Take it step by step. You’ll get up there.