Several if not most typical DebConf events are BoF (Birds of a Feather).
Note: in the context of DebConf, most attendees would interpret the word "BoF" in the historical IETF sense, i.e. a discussion session among people interested in a specific topic. (Other conferences use "BoF" to refer to impromptu, non-scheduled, and spontaneous events, while at DebConf we traditionally have submitted in advance, reviewed, and scheduled BoFs.)
 DebConf BoF HOWTO
The quality and usefulness for both the Debian Project and attendees might vary substantially from BoF to BoF. This document is meant to share tips — if not a proper BoF recipe — collected thanks to the experiences of BoF participants and organizers. If you want a single example of a well-organized BoF you might want to have a look at the team-maintenance BoF at DebConf8.
 have a coordinator
A good BoF should always have a coordinator, which is usually (but not necessarily) the person who has proposed the BoF in the first place.
The role of the coordinator encompasses at least two tasks:
- preparing the BoF in advance; and
- moderating the actual session to ensure everybody get a chance to participate
 schedule the session
Please register your session in penta.debconf.org and then e-mail the ID of the resulting event to talks (at) debconf.org with your preferred slot (and room) and some alternatives.
 prepare in advance
A good BoF is more than just getting together, vaguely knowing the BoF topic, and ... discussing. It might work well that way too, but the chances of having a successful BoF are much higher if attendees arrive prepared. As the DebConf schedule is often tight, it would be a pity to risk having a suboptimal BoF while you can have a very good one by investing a little bit of time in preparation.
Preparation is in general quite simple to achieve. It just takes the BoF coordinator to prepare a set of working questions (e.g. this list for the team-maintenance BoF) and/or a set of thought provoking comments and detailed discussion topics. Once they are ready, they should be advertised as such; mailing them to the debconf-discuss list, as well as posting them on planet are often good choices.
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 the author's experience, the BoF time will then be used in a much more productive, exciting, and even 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 during the discussion.
 don't be exclusive
Debian is not a company and Debian contributors are not employees, therefore you should in general not expect all relevant people to be physically present at a specific BoF, just if they had to be. You should try to mitigate the risk of cutting off community members who cannot attend the BoF as much as possible. To that end, minutes are just great; after the BoF, minutes should be posted to the appropriate mailing list (e.g. a team mailing list) and uploaded to Penta as attachments to the Bof event page.
... but taking minutes is just boring and not everyone is good at that. If you have a trusted participant which is good at taking minutes, great, just go for him/her!
If you don't, use collaboration to take minutes. A nice way of taking minutes has been used for quite a while both at DebConfs and at other Debian-related events that Debian people might have attended (e.g. UDS). It takes a dedicated projector in the BoF room showing some real-time, collaborative editing facility such as gobby. With such a setup, attendees (both local and remote) usually just start taking minutes collaboratively, although explicitly inviting them to do so is a very good idea.
Ideally, if you need proper slides during the discussion, you should equip the Bof room with two projectors, one for the slides and another for collaborative minutes taking. In case there is only one, as it is usually the case at DebConf, it's probably better to use it for minutes and switch to them as soon as supporting slides are over.
 coordinate with the publicity team
If you decided something cool, which might in any way affect or otherwise interest users or anyone outside of your team, please think about contacting the publicity team after the BoF as soon as posible with a short summary. If you know in advance that exciting news will be announced during the BoF please make sure to contact the publicity team before the BoF.
We have routinely a gobby (infinote) server at gobby.debian.org . Just do the following in order to be ready for collaborative minutes taking:
# apt-get install gobby-infinote # (or just "gobby", from Wheezy on) $ gobby -c gobby.debian.org
Then open up the document browser (F9 is the shortcut) and look around.
Starting from DebConf12, BoF documents are located under debconfXX/bof , e.g.: debconf12/bof
 Why not etherpad?
You are of course free to use whatever collaborative minute taking technology, but experience has shown some advantages of gobby over purely online tools such as titan/etherpad, in particular:
- to use titan/etherpad you generally need to share a URL with the attendees, which might be annoying especially for BoF latecomers. With a well-known, conference wide gobby server attendees will know where to start and, provided a suitable naming convention is used, will be able to find out the appropriate document by themselves within the gobby directory listing
- in DebConf experience, with a large number of heavily synchronous participants, titan/etherpad has proven to be less reliable and reactive than gobby-infinote
- the gobby/infinoted server is local to DebConf network, so if there is an upstream outage, we can still communicate locally
- ease of setup:
- infinoted is packaged in debian and as a result is relatively simple to setup and maintain (dogfooding ftw). There were though some efforts to package Etherpad for Debian, too, see #576998.
- etherpad is not trivial to setup. Some Debian/DebConf people have done that and reported it was quite a pain. Also, development is currently quite "balkanized", so its not clear which was to go with it
 Acknowledgements and feedback
This document has been initially written by Stefano Zacchiroli as a blog post for DebConf10, based on the amazing BoF preparation work done by Gregor Herrmann and with substantial feedback from him.
You are more than welcome to contribute your tips or otherwise improve this document.