(by Pamela Mosiejczuk and Michael W Lucas)
We just sent out submission acceptances and rejections. We’re months out from the conference and everything can change, but if everything works out we’re gonna have a great con. So let’s talk about rejection.
Conferences reject submissions for reasons. Submitters feel that those talks get rejected for completely different reasons. It’s not that unaccepted talks are bad. Conferences generally weed out a very few submissions where the abstract was not of a quality/completeness that we could actually judge, sure, but these committees aren’t gauging your worth like an academic board. We’re tasked with creating a lineup like a programming block for television.
After years of working with poster sessions, colloquium, and conference scheduling, especially for BSD conferences, here are the common reasons why we turn down a submission.
- multiple basically identical talks
- topic too recently covered
- topic covered at other similar conferences
- repeated talk
- won’t pull enough people to keep the opposite talks in the available slot from overcrowding the available spaces
- chose a different talk by the same person
- topic not tied tightly enough to the audience’s skills or professional needs
- ensuring space is left for a student or other member of an underrepresented group
- we have many papers on this part of our field, other areas need attention
- out of wall space designated for that general topic
- simple volume … we can’t take them all
Note that this list does not include “your proposal was bad and you should feel bad.”
People are reluctant to re-propose the same talk again. Don’t be? Maybe people filled up the fuzzy bunnies track really early the first year you submitted and yours was simply one of the sacrificial ones because a few of the others fit together especially nicely thematically. The next year, the masses might be on to slithery snakes and there will be a prime space for your etymology of fuzzy bunnies talk, which was always interesting, there was nothing wrong with the bunnies!
People forget that we are generally not gauging quality at all, we’re rating things like “is this clear for this audience?” and “can this talk be a good way to get people to meet during the discussion and be able to continue to chat into lunch?”
There are certainly ways to slamdunk a submission to get it noticed. An abstract where we can imagine the precise audience who will be interested, which makes it obvious the level of experience required, talks clearly about the topics to cover (and sounds reasonable for the timeframe and experience of the presenter) and explains how the audience will be able to use what they’ve learned for their own purposes? That is immediately noticed. One that simply presents a topic without much context requires that both the committee and the audience know exactly what you are on about and can identify the talk’s purpose and end results on their own. If you want to talk about filaments in light bulbs produced between 1982-1995 we NEED to understand what is interesting about that. We believe you, but you only get a paragraph or two, is it there? Showmanship does matter, but this detail is why we can get excited about your topic.
Sometimes it’s just not exciting, it’s informational. Then we need to have someone around who understands its value. Teams tend to have both specialists and generalists doing these reviews. I’m a generalist and will alert on talks providing interesting looks into history, social topics, future planning, etc. Someone else might be the light bulb person. If we don’t actually represent that specialty to judge well? That’s OUR shortcoming, not yours.
This process is a balancing act where a handful of people try to stack a bunch of blocks in such a way that we’ll hit a nice variety of topics and provide an interesting broad cross-section of what’s going on in a particular world without letting the blocks fall because we didn’t provide a sufficiently varied mix of popular and niche, this topic and that, intro and advanced, rote technical and something-new.
Also, we all want to hear these sample talks about bunnies and light bulbs. But not at BSDCan.
Also also, you should know that the people who handle BSDCan’s money have no say in which papers get accepted. BSDCan has never sold talk slots. (I would say “never will,” but a million dollars up front and a generous trust fund for every attendee might change our minds.)
With that: here is the tentative list of talks for the 20th annual BSDCan! (Subject to change, slippery when wet, use as directed, do not taunt Happy Fun Ball.)
Tutorials
Managing OpenBSD Networks with NSH — Tom Smyth
Network Management with the OpenBSD Packet Filter Toolset — Peter Hansteen
BGP 101 — Massimiliano Stucchi (AS58280.net)
Run Your Own Email Server — Michael Lucas (BSDCan ConCom)
BoF
ZFS BoF — Allan Jude (Klara Inc.)
Implementing Routing Domains on an OpenBSD workstation for use with WireGaurd — Josh Grosse
Contributing to FreeBSD
Contributing to NetBSD
Talks
Supporting Business IT and network needs with OpenBSD and NSH — Tom Smyth
HardenedBSD 2024 State of the Hardened Union: A Decade of Hardened Bits — Shawn Webb (The HardenedBSD Project / The HardenedBSD Foundation)
A Journey Into BSD and Standards: BSD and POSIX — Katie McMillan (Government of Canada)
The FreeBSD and Windows Environments — Michael Dexter (Call For Testing)
NetBSD Subfiles — Elijah Sherwood (Western Washington University)
The State of Email — Michael Lucas (BSDCan ConCom)
Zelta: A Safe and Powerful Approach to ZFS Replication — Daniel Bell (Bell Tower Integration)
Alamosa: A Tiered Disk Block Cache for NetBSD — Kira Ash
20 Years of NYC*BUG, and Can We Handle 20 More? — George Rosamond (NYC*BUG)
Supporting FreeBSD in the Field — Allan Jude (Klara Inc.)
LLDB FreeBSD Kernel Module Improvement — ShengYi Hung (National Taiwan Normal University)
Summa Tetraodontidae: Thomas Aquinas Explores OpenBSD’s Medieval Orderliness — Corey Stephan (University of St. Thomas (Houston, Texas))
Address space reservations: Re-thinking address space management for pointer provenance — Brooks Davis (SRI International)
NetBSD on RISC-V – It Finally Runs NetBSD — Dylan Eskew (Western Washington University)
Running your own network using BGP, OSPF and IS-IS on the BSDs — Massimiliano Stucchi (AS58280.net)
Making NetBSD as a fast(er) booting microvm — Emile Heitor (NetBSD)
The Accidental Release Engineer — Colin Percival (Tarsnap Backup Inc.)
Why fsync() on OpenZFS can’t fail, and what happens when it does — Rob Norris (Klara)
Supporting a development lab with FreeBSD — Chuck Tuffli (FreeBSD)
DJ-BSD: DJing and music production in FreeBSD — Charlie Li
Encouraging and enabling SMEs (small to medium enterprises) to contribute to BSD development — Tom Smyth
A userspace NVMe over Fabrics Implementation — John Baldwin (FreeBSD Project)
Calling the BATMAN: Free Networks on FreeBSD — Aymeric Wibo
Improving Haskell Development Experience on FreeBSD — Daniel Lovasko
How to get started hacking NetBSD — Taylor Campbell (The NetBSD Foundation)
quiz: tiny VMs for kernel development — Rob Norris (Klara)
Contributing to FreeBSD via Github — Warner Losh (Netflix)
Towards a Robust FreeBSD-Based Cloud: Porting OpenStack Components — Chih-Hsin Chang
USB Debug Capability on FreeBSD, Revised — Hiroki Sato (Tokyo Institute of Technology)
Hot cross builds: cross-compilation in pkgsrc — Taylor Campbell (The NetBSD Foundation)
FreeBSD as the backbone of a vaccine/medication refrigerator monitoring system — Phillip Vuchetich (Arxsine Inc.)
FreeBSD at 30 Years: Its Secrets to Success — Marshall Kirk McKusick (McKusick Consultancy)