One of the BarCamp principles is that if you aren't learning or contributing, you should get up and go somewhere else. So today, day 2 of BarCampBoston, I have gotten up and not gone anywhere, and am sitting at home in Cambridge with an IRC window open just in case something mind-blowing happens in Maynard and somebody there thinks to type about it. I'd guess there were something like 150 people who showed up for day 1, and IRC reports estimate more like 30 who returned for day 2, so I don't appear to be alone in my decision.
Actually, there's probably nothing really un about this unreport, and for me there wasn't enough un about this nominal unconference. The reason I don't go to a lot of regular technology conferences is that I find them too often to consist of a series of sessions driven by over-specific presentations that are, at best, distantly related to some topic in which I am interested. My best hope is usually that they will inspire some discussion that wanders closer, but the structure usually almost guarantees that the presentations will be too long, and the discussions (if they happen at all) too short.
BarCamp was basically just like this. I went to some sessions I liked, but all of these ended just when they were getting going, if not sooner. I went to some I didn't, and these went on too long, or without viable alternatives. At least on day 1, the meeting spaces were far from the staging center, and even farther from each other, making it hard to do anything but pick a room and hope for the best. Day 1 was over-scheduled, day 2 under-scheduled, and in the absence of any compensating plan, this became self-reinforcing: I'm sure I wasn't the only person who moved their presentation from day 2 to day 1 in the fear that if I gave it on day 2 there'd be no audience, and then once I'd given it there was one less reason to come back on day 2 myself.
I can think of two obvious ways to combat this structural problem. One is to have better presentations. I don't know any shortcut to this. The longcut is to have the presentations solicited, proposed, submitted, judged and endorsed ahead of time. This could probably be done in a democratic, ad hoc, self-organizing, non-authoritarian, grassrooted, BarCampy way, but it would be hard, and I don't think that approach takes any fundamental advantage of the unique nature of BarCamp.
The other approach is to acknowledge explicitly that unless the presentations are exceptional, the real value is much more likely in the discussions. This, conversely, is exactly in keeping with the ad hoc, participatory nature of BarCamp. So my proposal for the next BarCampBoston is that it be mostly, or perhaps entirely, about discussions. Forget 30-minute presentations, which usually produce the kind of information quantity and density you could just as well read on the web anyway, and produce way too much scheduling churn and running around.
Instead, organize everything into 90-minute discussion groups with 30-minute blocks in between for logistics. So 10-11:30, 12-1:30 (over lunch), 2-3:30 and 4-5:30. For each discussion group there should be:
- A framing topic, ideally in the form of a theoretically answerable question, like "What is the killer app for the semantic web?", or "What is the next step towards practical distributed identity-management?"
- 3-6 participants prepared to contribute 5-minute demos of (or talks about) directly relevant work, so that the discussion has both concrete references and personal investments.
- A moderator, who is in charge of nudging the conversation out of ruts and back from digressions when necessary, and helping spot the right places to insert the demos. One of the contributors can also serve as moderator, or the moderator can be somebody else.
- Some idea, explicitly stated if it isn't adequately implied by the topic and the list of demos, of the expected context or background of discussion participants. It's particularly worthwhile to distinguish between introductions ("What is the semantic web and why might I care?: An invitation for web developers discovering data structure.") and working groups ("From DTDs to RDFS to OWL: How do you decide how much ontology is worth modeling?")
- Few enough other people that all of you can actually have a discussion. No more than 12 total people who plan on talking, probably, including the moderator and the contributors. And additional silent observers only if the space can still accommodate everyone comfortably for 90 minutes.
- Comfortable, discussion-suited spaces, ideally with net connections and presentation screens, and double-ideally arranged so that they feel connected, and there's a central common area from which everything else can be staged. Nobody should end up sitting somewhere bored because it's too hard to figure out where else they could be.
This can all be totally self-organizing, but most (if not all) of it should be self-organizing in advance: at least the topics, demos, moderators and contexts; and any amount of schedule- and space-assignment will only help. Among other virtues, laying out the options in advance allows participants to anticipate a good experience by actually planning it, and allows the group to potentially consolidate less popular topics and split (or clone) more popular ones. Clone with impunity, in fact. In a self-organizing conference, the participants are generally going to be self-motivated and self-filtered, so the chance of a large group having too much to say is far higher than the chance of splitting it in two and finding that either half runs out of ideas.
And if you can manage to have the unconference be self-reorganizing on the fly, then fantastic. Whether you plan for this or not is a question of your optimism. It sounds cool to say that you'll leave the 4:00 time-slot open until 3:30, for example, so that sessions inspired by earlier developments can spontaneously materialize. I bet it generally won't work, though. At most I might leave some of the spaces in a time-slot unbooked so that a planned session that overflows can be split or cloned on the fly. But ideally I'd state even this possibility ahead of time, so that the potential second session can be provisionally self-organized with a moderator and a share of the contributors. Remember that it's always easier to not do something you were prepared to do than it is to do something you weren't prepared to do.
The one other hope I have for future BarCamps and related gatherings (Geek Dinners, WebInno, RSS Alley experiments...) is that we find a way to get a little more participation from non-startups. I don't want to crowd out the self-employed, the unemployed and the aspiringly employed, but there are times when I feel like this is the Boston Technology Underdogs Club, rather than any kind of representative sample of the real community of people interested in new technology. Credit to Monster for hosting, but the people in the orange shirts weren't acting so much as ushering, and even if they had been participating, when the next largest concern represented is Tabblo, you know we're missing some people.
Actually, there's probably nothing really un about this unreport, and for me there wasn't enough un about this nominal unconference. The reason I don't go to a lot of regular technology conferences is that I find them too often to consist of a series of sessions driven by over-specific presentations that are, at best, distantly related to some topic in which I am interested. My best hope is usually that they will inspire some discussion that wanders closer, but the structure usually almost guarantees that the presentations will be too long, and the discussions (if they happen at all) too short.
BarCamp was basically just like this. I went to some sessions I liked, but all of these ended just when they were getting going, if not sooner. I went to some I didn't, and these went on too long, or without viable alternatives. At least on day 1, the meeting spaces were far from the staging center, and even farther from each other, making it hard to do anything but pick a room and hope for the best. Day 1 was over-scheduled, day 2 under-scheduled, and in the absence of any compensating plan, this became self-reinforcing: I'm sure I wasn't the only person who moved their presentation from day 2 to day 1 in the fear that if I gave it on day 2 there'd be no audience, and then once I'd given it there was one less reason to come back on day 2 myself.
I can think of two obvious ways to combat this structural problem. One is to have better presentations. I don't know any shortcut to this. The longcut is to have the presentations solicited, proposed, submitted, judged and endorsed ahead of time. This could probably be done in a democratic, ad hoc, self-organizing, non-authoritarian, grassrooted, BarCampy way, but it would be hard, and I don't think that approach takes any fundamental advantage of the unique nature of BarCamp.
The other approach is to acknowledge explicitly that unless the presentations are exceptional, the real value is much more likely in the discussions. This, conversely, is exactly in keeping with the ad hoc, participatory nature of BarCamp. So my proposal for the next BarCampBoston is that it be mostly, or perhaps entirely, about discussions. Forget 30-minute presentations, which usually produce the kind of information quantity and density you could just as well read on the web anyway, and produce way too much scheduling churn and running around.
Instead, organize everything into 90-minute discussion groups with 30-minute blocks in between for logistics. So 10-11:30, 12-1:30 (over lunch), 2-3:30 and 4-5:30. For each discussion group there should be:
- A framing topic, ideally in the form of a theoretically answerable question, like "What is the killer app for the semantic web?", or "What is the next step towards practical distributed identity-management?"
- 3-6 participants prepared to contribute 5-minute demos of (or talks about) directly relevant work, so that the discussion has both concrete references and personal investments.
- A moderator, who is in charge of nudging the conversation out of ruts and back from digressions when necessary, and helping spot the right places to insert the demos. One of the contributors can also serve as moderator, or the moderator can be somebody else.
- Some idea, explicitly stated if it isn't adequately implied by the topic and the list of demos, of the expected context or background of discussion participants. It's particularly worthwhile to distinguish between introductions ("What is the semantic web and why might I care?: An invitation for web developers discovering data structure.") and working groups ("From DTDs to RDFS to OWL: How do you decide how much ontology is worth modeling?")
- Few enough other people that all of you can actually have a discussion. No more than 12 total people who plan on talking, probably, including the moderator and the contributors. And additional silent observers only if the space can still accommodate everyone comfortably for 90 minutes.
- Comfortable, discussion-suited spaces, ideally with net connections and presentation screens, and double-ideally arranged so that they feel connected, and there's a central common area from which everything else can be staged. Nobody should end up sitting somewhere bored because it's too hard to figure out where else they could be.
This can all be totally self-organizing, but most (if not all) of it should be self-organizing in advance: at least the topics, demos, moderators and contexts; and any amount of schedule- and space-assignment will only help. Among other virtues, laying out the options in advance allows participants to anticipate a good experience by actually planning it, and allows the group to potentially consolidate less popular topics and split (or clone) more popular ones. Clone with impunity, in fact. In a self-organizing conference, the participants are generally going to be self-motivated and self-filtered, so the chance of a large group having too much to say is far higher than the chance of splitting it in two and finding that either half runs out of ideas.
And if you can manage to have the unconference be self-reorganizing on the fly, then fantastic. Whether you plan for this or not is a question of your optimism. It sounds cool to say that you'll leave the 4:00 time-slot open until 3:30, for example, so that sessions inspired by earlier developments can spontaneously materialize. I bet it generally won't work, though. At most I might leave some of the spaces in a time-slot unbooked so that a planned session that overflows can be split or cloned on the fly. But ideally I'd state even this possibility ahead of time, so that the potential second session can be provisionally self-organized with a moderator and a share of the contributors. Remember that it's always easier to not do something you were prepared to do than it is to do something you weren't prepared to do.
The one other hope I have for future BarCamps and related gatherings (Geek Dinners, WebInno, RSS Alley experiments...) is that we find a way to get a little more participation from non-startups. I don't want to crowd out the self-employed, the unemployed and the aspiringly employed, but there are times when I feel like this is the Boston Technology Underdogs Club, rather than any kind of representative sample of the real community of people interested in new technology. Credit to Monster for hosting, but the people in the orange shirts weren't acting so much as ushering, and even if they had been participating, when the next largest concern represented is Tabblo, you know we're missing some people.