The openSUSE conference team adopted the UNIX acronym RWX for this year’s conference. The goal with this theme is to emphasize the stronger focus on getting-things-done and hands-on sessions. So, what sessions are we talking about? In this article we’ll dive into one type of interactive session: the BoF.
Wikipedia defines a BoF as ‘an informal discussion group’, ‘often formed in an ad-hoc manner’. It also describes a BoF as ‘an informal meet-up at conferences, where the attendees group together based on a shared interest and carry out discussions without any pre-planned agenda’.
The central concepts are informal, shared interests and ad-hoc. What is not mentioned are goals, the why of such a session. But based on the concepts, you can get an idea. The informal factor means everyone is equal and can and should voice their opinions. The shared interests mean you get together people who care about a particular subject. The ad-hoc factor merely re-inforces the other two. A BoF is very much like meeting for dinner: you talk as friends about whatever interests you! That is not to say a BoF can’t have goals. Often, BoFs have a number of things the participants want to discuss. The person organizing the BoF is usually the person who puts one or more topics forward, but everyone is free to bring up other issues. This is central to the concept of a BoF - discuss things.
Free Software communities work online in a collaborative fashion. That’s marketing speak for: we work together, alone. While each of us sits behind his computer, either alone or with others in an office, we form one team. We communicate over mail, IRC and other online channels.
For asking questions, basic decision making or just getting work done, this is excellent. For socializing, it is less optimal, but you’ll still find plenty of social interactions especially in IRC channels. It gets much harder however, when complicated issues surface. If decisions have to be made about processes or fundamental technical directions, the online aspect gets in the way. You quickly run into misunderstandings and while our hacker culture compels us to fairly direct (‘rude’) communication, still emotions can run wild.
At the conference, Cédric Bosdonnat wants to discuss using statistics from the LibreOffice git repositories to show information about contributions and contributors. He will first present the way statistics are extracted from the repository and then pose the question how to turn these rough statistics into valuable, meaningful numbers. How do you relate the lines-of-code added to the complexity of a change? How can one decide, from the stats, if someone is a long-term contributor? A core developer?
This is where face to face meetings help. Getting to know each other over dinner or during a party is a powerful enabler for future online communication. But it is also the perfect moment to make those hard decisions! And that is where the BoF comes in.
Discussions about future directions or day to day business like improving a review process or working together more efficiently - all things done better in person. In a BoF, a team working together on-line meets and discusses these things, face to face, in an open manner. Not completely unstructured, mind you, but still very open. The organizer of the BoF is there merely to start up the discussion and possibly facilitate it. Facilitate by making sure some decisions are actually taken. And recorded!
A typical BoF starts with a short ‘hi all, thanks for coming’, and if needed an introduction of the participants. Then, it is time to find the subjects of the discussion at hand. The organizer can coin a few things he or she things need to be discussed and others can chime in. From there on, it’s a matter of actually going over the subjects one by one.
Jean-Daniel Dodin is involved with testing in openSUSE. At the conference, he wants to have a BoF centered around improving the process of testing multimedia applications. Many of these applications don’t work as expected or not at all. How can we ensure applications are tested reliably and don’t end up on a user’s desktop just if they compile but only after they are proven to actually work?
The challenge now is to keep the discussion from going in all directions - something which is fine at a dinner but not productive at a BoF. Gently reminding the team of what the goal of the current topic is is usually sufficient. You all share the same goals, after all. The second challenge is to make sure decisions are taken and recorded. Creating the typical action list of who does what is the best way to go. It might make sense, with a large BoF team, to have one person lead the discussion while someone else takes notes.
Know that the person organizing the BoF does not have to be a ‘team leader’, nor a ‘great communicator’! Every attendee is equally responsible for the quality and results of the discussion. Organizing the BoF is merely a technical detail - not a huge deal at all, and anyone can do it.
Responsibilities and tools
Organizing a BoF is surprisingly simple if the right people turn up. For that, a clear description is usually enough. A title like “Factory review process discussion” will most likely attract those involved with review of packages in Factory and interested in improving the process. If the review process has had hickups in the last few months it is highly unlikely that the discussion won’t be attended or not attract the right people. Nor is it likely to not have ‘enough to talk about’. The problem is usually more one of getting sidetracked and not actually finishing discussing the topic with a proper todo list!
What do you need to organize a BoF? Almost nothing. Pen and paper (for the todo!) will usually suffice. A whiteboard might be nice for more complicated problems like mapping out a new API, creating a flow diagram of a process or simply noting down the agreed-upon topics for the BoF. Otherwise, just talk! Introduce the topic quickly and ask for opinions will fire it off easily.
Usually, BoF’s are scheduled ‘on the spot’ using a big whiteboard in the main hall of the conference or on an open wiki page. That can lead to two similar BoF’s or two BoF’s targeting the same team at the same time, however. It also means you might not have a spot at a decent time. Which might result in being forced to plan a BoF in the time slot of a talk about the same subject . This is why the openSUSE CfP team asks you to plan BoF’s in advance!
The biggest perceived problem with planning a BoF is the inherent contradiction in ‘planning’ and ‘BoF’. Yes, you might not know now what will be an issue 3 months from now. However, you don’t have to nail the agenda down today, that would indeed run counter to the whole concept of a BoF. If you think your team will benefit from having a good, open discussion about what you do and how you (want to) do it, simply send in a quick proposal to the openSUSE Conference Paper Committee. It is no problem if something more urgent pops up and you discuss that instead of following the initial description. The main reason for ‘planning’ (part of) the BoF’s beforehand is to allow the CfP team to try and schedule things in such a way there is little overlap with talks and other BoF’s and to allow teams to reserve a room.
So go to the conference page and add a BoF!