Dear Debian, today you turn 17 ...

... happy birthday!

I've already argued how you're in very good health now that you're close to the major age and how unique and important you are for the whole ecosystem of free software. So, no, I won't insist on that here.

Still, today sounds like a good day to say thank you, Debian for being here promoting software freedom and showing to the world that all this can be done do-ocratically, democratically, relying on volunteer work and donations.

If you too think Debian deserves being thanked for what it is giving to the world, just say “thank you, Debian”.

My first (meta) thank you messages go to Marga, Maxy, Valessio, Raphael, Ana, and Rhonda for ideating and spreading the 1st Debian Appreciation Day ever.

Update: fix 404 Penta b0rkage in the slides link

It is not that I've missed DebConf10, I've totally been there (as some embarrassing video and photo evidence can prove ...).
Rather, I've just got back home and I already miss DebConf10, melancholy is in the air. It will probably stay around for a while and then leave room to a vivid memory of 2 weeks of Debian life, as strong as I've never experienced before.

So, before I become too sentimental, let me just thank everyone who has made the conference possible: the orga team, the video team, all the volunteers, the sponsors, the speakers, the attendees, and everyone else I couldn't possibly remember.

Specific kudos of mine goes to the Debian NYC cabal: DDs and non-DDs, new to our project and not-so-new. You guys made me remember what does living Debian mean, you guys made all this possible (emotions included!), you guys rock. Say whaaaaaat?

Here at DebConf10 the schedule is starting to get really packed of events, which is great! About a half of those events are BoFs (in the IETF sense), i.e. discussion sessions among people interested in specific topics. (Other conferences use "BoF" to refer to impromptu, non-scheduled, and spontaneous events, while at DebConf we have traditionally submitted, reviewed, and scheduled BoFs in advance.)

As most DebConf regulars, I've attended quite some BoFs in the past and I share with others the impression that the quality and usefulness for the project of BoFs varies substantially from BoF to BoF. That's why I'd like to share a BoF recipe, which comes from possibly the best organized BoF I've ever attended. As it happens with all good recipes (and with free software), I've took the liberty of customizing it a bit.

DebConf BoF HOWTO

have a coordinator

A good BoF should have a coordinator, which is usually (but not necessarily) the person who proposed the BoF in the first place. The role of the coordinator encompasses at least 2 tasks: preparing the BoF in advance (read below) and moderating the discussion to ensure everybody get a chance to participate.

prepare in advance

A good BoF is more than just getting together, vaguely knowing the BoF topic, and ... discuss. Mind you, it might work very well that way too, but the chances of having a successful BoF are much higher if attendees arrive prepared.

That is quite simple to achieve. It just takes the BoF coordinator to prepare some working questions and/or detailed discussion topics, and advertise them as such. That way potential participants can make up their minds, recall experiences that they want to share, note down comments they want to bring into the discussion, etc. In my experience, the BoF time will then be used in a much more productive, exciting, and ultimately fun way.

Most BoFs can also benefit from a few introductory slides on the BoF topic, to ensure all participants start from a common ground. The last slide could contain a brief recap of the working questions, so that the audience have them handy.

don't be exclusive

Debian is not a company and Debian contributors are not employees, therefore we cannot expect all relevant people to attend a specific BoF, just if they had to. As usual, the risk of cutting off community members who cannot attend should be mitigated as much as possible. To that end, minutes are just great; after the BoF, minutes should be posted where appropriate, and possibly uploaded to Penta as event attachments.

... but taking minutes is just boring and not everyone is good at that (for instance, yours truly used to suck at taking minutes, even if I'm trying to get better ...). If you have a trusted participant which is good at taking minutes, great, go for it!

If you don't, use collaboration. During past DebConfs as well as at UDS this year, I've been shown a nice way of doing that. It takes a dedicated projector in the BoF room showing some real-time, collaborative editing facility (e.g. gobby). With such a setup, people usually just start taking minutes collaboratively, although explicitly inviting the audience to do that is a very good idea.

Ideally, the room should have two projectors, one for supporting slides, another for collaborative minutes taking. In case there is only one, as it is usually the case for DebConf, it's probably better to use it for minutes and switch to them as soon as supporting slides are over.

gobby.debian.net for BoF minutes at DebConf10

For DebConf10, the DebConf team has setup a gobby (infinote) server at gobby.debian.net. Just do the following in order to be ready for collaborative minutes taking:

    # apt-get install gobby-0.5
    $ gobby-0.5 -c gobby.debian.net

(Note: you shouldn't use the non versioned gobby package as it uses a different protocol and doesn't support undo, which is quite risky; see Debian bug #590753 for more background.)

As the naming convention for DebConf10 minutes, using document names that start with dc10- sounds sensible.

comments welcome!

So, what do you think of the above suggestions? Do you have further best practices to share on BoF organization at DebConf? Leave a comment or mail me. In the end it would be nice to author a proper "DebConf BoF HOWTO" document for further reference.

Thanks to Gregor for his feedback on early versions of this post.

How to have a Debian meeting without turning into a secret cabal (redux)

Brief status update on my past RFC about Debian meeting sponsoring guidelines. I've now actually drafted the guidelines, integrating the received feedback.

The result is now available on the Debian wiki at Teams/DPL/SponsoringGuidelines. Feel free to comment further and improve the wording. I'll then make the text "more official" by announcing it to -project or d-d-a, as suggested.

Recipe for RCBC - Release Critical Bug squashing Contest:

It has been a while since my last post in the RCBW tradition. Luckily, the tradition is in very good health of its own, thanks to many others that have picked up the habit of SPAM-ing planet with good news for Debian, encouraging others to do the same.

With all that RC-obsessed people around and with the Squeeze release forthcoming, can DebConf10 be devoid of geeky RC-squashing activities? Of course not! Thanks to the orga team we expect the conference to contain a 2-week long RC bug squashing pride with tutorials, BoFs, a permanent bug squashing party, ... and a contest!

I won't indulge much on the contest as the wiki page contains all rules and gory details. Obviously, all usual rules and best practices of bug squashing parties will apply; coordination will happen on #debian-bugs.

Get involved, it starts today, and it's open to everyone (DebConf10 attendees as well as Debian enthusiasts abroad, regular RC squashers as well as casual bystanders, etc).

All this wouldn't have been possible without the help of many people that love Debian, so many thanks to:

• the sponsors of RCBC:
  • Marvell, for offering a GuruPlug
    (of course, the winner of this device is expected to help with Debian support for it *g*)
  • HP, for offering t-shirts
  • Pearson, for offering books
• micah - who dragged me into this (it hasn't been hard)
• gregoa and mehdi - the almighty judges - who have been transitively dragged into this (it hasn't been hard either)

PS a corresponding announcement is in the debconf-announce pipeline already

This Week In Debian

I've been contacted by Jonathan Nadeau of Frostbite Systems, a company selling computer hardware with pre-installed GNU/Linux distros, including Debian (of course!). (Usual disclaimer applies: I haven't tried their products, I've just skimmed through their website ...) Both for promotion and as a service to the communities, Jonathan has started various podcasts, such as This Week in Fedora.

Jonathan has contacted me to check whether Debian is interested in having a This Week in Debian podcast, which will be discussing weekly Debian-related topics, interviewing at each episode someone from the community.

So, folks, are you interested in seeing that happen?
Personally I like the idea, as I'm myself an eager podcast listener and I've always missed something Debian-specific.

To make it a reality however we need to plan and record some episode in advance, to ensure the podcast will have enough "buffer" to start. That's why I've created the ThisWeekInDebian wiki page, where interested people should drop a line, proposing a topic and volunteering to speak about it. Any Debian-related topic is a good candidate: a team, an initiative, a general discussion about a relevant project aspect, etc. You don't even need any particular upfront preparation, as it'll be interview-like. So, what are you waiting for? Drop a line to the wiki page.

Jonathan will attend DebConf10 so, in case you are attending, that can be a nice occasion to record some episode in person (otherwise recordings usually happen over the net).

and the newbies are ...

A long time ago, in a couple of blog posts far far away, we have introduced the DebConf Newbies initiative.

I'm hereby happy to announce the actual DebConf newbies and I'm looking forward to meet them at the forthcoming DebConf10 in New York City:

• Jonathan Wiltshire
• Jon Bernard
• Arnaud Fontaine
• Ben Armstrong
• Arthur Loiret
• Serafeim Zanikolas
• Andreas B. Mundt

Now, folks, please be kind with them, they (still) don't know how crazy we can be(come) during DebConf. Above all: do not harm them (too much) at Mao. In exchange, they have already promised that they will fix all RC bugs that will still be open at the beginning of DebConf10 (or maybe I've just read that in their minds, I don't quite remember ...).

Does that mean that DebConf10 travel sponsoring is completely OK as of now? No, not really. This initiative was specifically targeting DebConf newbies, but several DebConf "regulars" are planning to attend too. For some of them the amazing DebConf sponsoring team has already found enough resources to secure their travel sponsorship, for quite some others it is not the case yet. This is a pity, because we know from the past that having more Debian folks at DebConf means more hacking, a better distribution, and a better community, ultimately it means a better Debian.

Some of the readers of this blog post will be in the condition to improve the situation: it is as simple as donating to Debian or, better, becoming a DebConf10 sponsor by simply mailing the sponsoring team.

on the interaction of FOSS communities with EU research projects

The 7th Framework Programme (or FP7) is a well-known European program to fund research projects and promote the creation of the European Research Area. For some European countries, FP7-funded projects are so important that they can make the difference between an institution that has the resources to pursue its research & teaching activities and an institution that doesn't, which will then have hard time surviving.

As part of FP7 and its previous editions, the European Commission (EC) has been funding research into FOSS for a while now, with different degrees of "FOSS-involvement". Some projects routinely use FOSS products, some fund the development of relevant FOSS projects (e.g. PyPy), some try to address shortcomings of specific communities (e.g. EDOS and Mancoosi, on which you surely are aware of my bias ...), some others try to remove barriers to FOSS adoption in various contexts (e.g. FLOSSinclude). A nice overview of EU-funded FOSS projects is available as a leaflet.

As with all project funding initiatives: having a project funded does not mean it will be successfully. By analogy: the fact that the project (proposal) mentions FOSS does not mean it will be successful in interacting with FOSS communities. Luckily, the EC is well aware of existing difficulties and is now seeking input from FOSS communities to understand how to better interact with them, from the standpoint of FP7 research projects.

That is why last week I've joined, upon invitation and as a Debian representative, a meeting at the EC in Brussels on the above topics. At the table we were about a dozen people, including representatives of ongoing research projects (both from academia and large industries), EC commissioners, ... and Debian (i.e. yours truly). Beside joining the brainstorming, what I've brought to the table are some thoughts on best and worst practices on the interaction between research projects and FOSS communities, answering to some working questions.

There is probably little to see in the slides for people belonging to FOSS communities, as all suggestions would seem fairly obvious (e.g.: do not invent/use yet another FOSS license, do not jail people into specific forges, do not expect people to work at your place, etc.). Still, I assure you that most of them were not obvious for EC commissioners and that they have been very much interested in hearing Debian feedback, which is perceived has having no other interest than serving Free Software. I'm personally very proud of the fact that Debian was there, as a purely community-driven project run by volunteers, whose opinion is clearly valued by an important program as FP7 is.

Various possible next steps have been discussed: from drafting guidelines that will help reviewers in evaluating the commitment of project proposals to FOSS communities, to create a scenario-based license chooser based on the needs of FP7 projects. While I did not volunteer to take part in all such initiatives, I'll keep you posted of advancements.

A couple of months ago, Steve McIntyre introduced the notion of Developer Certification. In essence, if you are (or have been) a Debian Developer, you can ask for a certificate of that status of yours; that might be useful in case you need to "prove" it to anyone (more precisely: to anyone who would care about / believe in a certificate ...).

Some people has asked me to provide such certificates and at the n-th iteration I took the chance to streamline a bit the process (yes, I'm lazy). In case you're interested, please check the DDCertificate wiki page and follow the instructions there.
While you are at it, join me in thanking Agnieszka Cicha-Cisek and Patryk Cisek, as they have prepared the LaTeX template.

Some other people were interested in being certified, but missed the announcement, so I'm blogging about it mainly to spread the news. Paul Wise has already submitted a request for proper documentation of this possibility.

We currently don't have a template for Debian Maintainers, but it should be straightforward to add: patches are welcome!

How to have a (Debian) summit without turning into a secret cabal

It seems rather uncontroversial that sponsoring various kinds of Debian meetings (conferences, sprints, BSPs, etc.) is a good way to spend, actually invest, Debian money.

Historically, that has not always saved the Debian community from muttering about "cabal-ish" meetings in very few specific occasions. (No, there is no cabal, in case you wonder.) I've always believed in the good faith of people and I don't think that we have ever had "secret meetings" on purpose. Nevertheless the question of how to have meetings in a community-compatible way is a sound one. Answering properly to such a question is something that it's harder than what it might seem at first sight (at least for me).

In particular, organizers have to carefully balance the high efficiency that meetings offer (e.g.: communication bandwidth is higher than when working remotely, people have less distractions, more enthusiasm, more fun!, etc.) with the risk of cutting out the rest of the community which cannot attend the meeting, for whatever reason. Note also that since Debian is not a company, we cannot just require that everybody who is interested attend the meeting.

As DPL, I'm starting to get quite some requests for meeting sponsorship, and that's just wonderful: it means that we have thrilling groups of people that are eager to get together and hack to improve Debian! Still, in doing so, we should all try to minimize the above risk; that's why I've started to apply the following Debian meeting guidelines, as a kind of prerequisite for sponsoring.

1. Before the meeting: the meeting should be announced to the most relevant public mailing list(s); ideally, the tentative agenda of the meeting should be included in the announcement.
   That will enable people interested in the meeting topics to provide their inputs and more generally to know what is going on.

2. During the meeting (preparation): expenses should be minimized, as a form of respect for all people that donate to Debian. Since we value their contributions, we do our best not to waste them. (TTBOMK, we've always done that, but making it explicit won't hurt.)

3. After the meeting: meeting minutes should be sent to the most relevant public mailing list(s), usually to d-d-a for meetings that cover topics of general development interest.
   As an obvious consequence, minutes should be taken during the meeting; it is a bit of extra burden, but the risk of leaving the rest of the community in the dark is just not acceptable a community as wide and diverse as ours.

4. In general, think about communication, e.g.: (micro)blog about the meeting, contact press/-publicity to prepare a news item about it, enable others to attend virtually on IRC or other media, etc.

For now, the above is just a brain dump.
Now, what do you think? Are the above reasonable demands? What else should we ask for?
Feel free to leave a comment or mail me about that.