Bobulate

As Sebas has already noted, there was a KDE e.V. board meeting over the weekend. I had Claudia, our business manager, over on wednesday and we had a good thursday at the NLUUG Fall Conference on Security (where Claudia ran the booth and I was acting as part of the NLUUG board). I think there’s a real advantage to getting together before a board meeting and spending some time chatting and whatnot — it takes those topics out of the meeting time and allows us all to synchronize a little on what the current issues are.

You might claim that the main issue was horrific weather, with storm, rain, more rain and cold going on in the city of Nijmegen. I might claim that the main issue was how to eat all the food.

Another issue we ran into was the visible lack of visibility (!?) of the documentation for Sprints and developer events. Sjors is the catalyst here. I think we spend about half of the total KDE e.V. budget on sprints (the rest is Akademy and office and personnel costs), and you can find plenty of mention of events in the quarterly report (PDF) or on the Dot once they’ve happened. So the board thought that the sprint organization mechanism was pretty obvious, and it turns out it’s not.

But thanks to that realization, we now have Sjors being all enthusiastic about a KMess event, and I’m starting to plan an KDE4-OpenIndiana event and there’s something I need to cook up further with Celeste, too. So expect more entries in the upcoming-sprints department soon. One of the tasks I’ve taken away from the board meeting is to improve the sprint HOWTO with perhaps some more fine-grained instructions or checklists. But I’ll give my own interpretation of what a sprint is and what it’s for first:

A sprint is a single event, highly focused on technical results, in one location with a short time frame (a week or less) and a single topic; the topic is most often development of an application or library. A sprint is organized by an existing development community, and has a small core group of attendees (six to ten people). A sprint is 80 percent sweat (e.g. getting work done and of that, let’s say 60/40 for doing stuff and planning future doing) and 20 percent social.

You’ll note that some things we call sprints aren’t, by this personal definition. Those events are swept up by the more general term “developer events.” It’s not like we hold up events plans to this simple descriptive yardstick — feel free to come up with something else.

KDE e.V. supports the organization of these events — financially, sometimes administratively, and rarely (simply because it’s almost never needed) organizationally. However, KDE e.V. doesn’t come up with its own sprint ideas, nor will it (generally) approach people saying “you should do a sprint.” It waits for (sub)communities within KDE to come up with something and to show off a plan — or even a sketch of a plan — before starting to act.

So, to paraphrase the A-Team: if you (collective, addressing a developer community) have a problem, and no one else can help, maybe you should get together to solve it — and then you can ask the K-team (KDE e.V.) to support your efforts by covering the costs of getting together to solve that problem. ( — Ed: that’s not a very good paraphrase at all.)