In the current state of affairs, people might have forgotten what it is like to go to a conference in person. Without attending a live conference for over a year now, I fully understand their importance. Conferences are where you interact with others, and although you may still receive a lot of information from a virtual conference, it just doesn’t achieve the benefits one can receive at a live one.
The Usual
What exactly are the benefits of a conference? It really matters who the audience is and what they want to get out of it. I find most conferences with expos tend to have a lot of marketing involved. I enjoy attending expos to view newly available products, but they are not as useful for learning about new technologies. For technical conferences, there are two formats that are very common: Presentations and Birds of a Feather (BoFs). There are also lightning talks, but they are typically used for letting people know about something that’s being worked on (i.e., a technology infomercial).
Presentations are where a single person or two present on a topic for which they have some expertise. You pick presentations based on your interest, and hear talks from people that know more about that topic than you do. Depending on how much the presenter knows about the topic and how well they deliver the material determines how much you can get out of a presentation. Usually, a presentation ends with some Q&A where you might get a chance to ask a question on the topic.
BoFs seem to not be well-defined. I find them to be like snowflakes. You’ll never find two that are run the same. Ideally, they are for like-minded people to discuss a topic. In practice they span from presentations with a Q&A to a room of people having a discussion. They can be productive if the right people attend, but they tend to be hit or miss due to lack of clarity around the exchange.
The Microconference
Now there’s a new type of format that technical conferences are starting to include: the microconference. Back in 2008, I was asked to run a Tracing microconference at the first Linux Plumbers. When I asked what a “microconference” was, I was told that it’s a two-and-a-half hour “mini conference” where I get to pick the topics that other people in my field may propose. How to run it was completely up to me. I had no idea what I was doing, but the result ended up being productive.
Over the last decade, I have participated in every Linux Plumbers conference, and seen several microconferences. Some were productive and some were lackluster. I felt the shortcomings were due to ambiguity about how to run them, and they suffered the same fate as BoFs. I complained about this at the 2016 Linux Plumbers, and the response from the programming committee was to have me join them and fix it myself!
By 2019, I became Microconference Chair and was in charge of organizing all the microconferences. By then, I had a clear idea on what made a good microconference and why Linux Plumbers is held as one of, if not the, most productive technical conferences.
“The program committee will work with the runners to clarify what the microconference category will be on, who needs to be there for it to be successful and what types of topics should be discussed.”
Topic Selection Evolution
Today, microconferences are typically three-and-a-half hours of content each. One of the biggest differences of a microconference compared to presentations or BoFs, is how they are accepted. In the typical situation, a presenter will submit an abstract or paper in response to a Call for Presentations (CFP), and the program committee will look only at the submission to decide what presentations to accept and what to reject. I find this unfortunate as the decisions that are made for the selection of presentations is held by the interpretation of the committee members on the abstracts and papers. If there’s doubt about something in the submission, good presentations may be rejected, and poor ones may be accepted. With microconferences, the runners submit a category. Then the program committee will work with the runners to clarify what the microconference category will be on, who needs to be there for it to be successful and what types of topics should be discussed. When a microconference is well defined, then it gets accepted. Microconferences are accepted on a first come first serve basis, based on when a microconference is ready to be accepted.
For a microconference to be accepted, it must demonstrate the following:
- It must have a clear description of what the category is about.
- It must demonstrate that there are enough topics to engage developers to cover the three-and-a-half hours of discussions. This makes microconferences a bit more involved than ordinary BoFs.
- It must list key people that need to attend to make sure that not only decisions that are made at the conference will be accepted after they are implemented, but those that are skilled enough to do the implementation are also in attendance.
The Problem Statement
The next part of a microconference is the acceptance of topics. When a topic is submitted, it should not be presented as an “abstract,” but instead, it should be in the form of a “problem statement.” A microconference is about solving issues of the present and the future, so it should not be discussing accomplishments of the past. A microconference is not the place to talk about something you have developed or achieved. Leave those for presentations. A microcoference is to get a group of engineers together to come up with solutions to tough problems people are facing today.
The Logistics
A topic within a microconference is all about discussion on how to solve a problem. At the live events, a microconference may have anywhere between 20 to 200 people in the room. At the last live event for Linux Plumbers, each microconference room had four microphones – one handheld microphone, one lavalier lapel microphone, and two catchboxes. The catchbox microphones are padded wireless microphones and made to be thrown. This way you can literally toss the microphone to anyone in the room so that they can speak and be recorded.
The Setup
As topics are about discussion, there may still be a need for a presentation. But as a topic may be only 15 minutes in length (and at most up to a half hour), any presentation should be focused only on bringing the audience up to speed on what the problem is that you want to discuss. This allows an engineer to understand the issues you are having and give constructive input to the conversation. Giving a seven minute presentation on an issue followed by eight minutes of discussion on the issue can be very productive. Keeping the presentation focused on the issue is critical for having enough time to have a meaningful discussion around it. It should also be stated that a topic of a microconference does not need to solve the problem during that short time in discussion. It’s to be used to have a brainstorm with other engineers that you normally don’t see and have access to different points of views that can lead to diverse thinking, which often leads to better results. The conversation may continue after the microconference over email or another medium, as 15 to 30 minutes of face-to-face can help get everyone on the same page and have a better discussion online if necessary.
Following these guidelines for running a microconference is a guaranteed way to have a very productive result, and make the most of everyone’s time. The 2019 Linux Plumbers microconferences were recorded. If you are interested in seeing them in action, I highly recommend you watch a few.
