|
People who present at BSDCan often submit again in later years. This
is great--it means we don't have to track them down again. It means
we're doing a good job at running an educational, friendly, fun,
worthwhile event. Repeat attendees and speakers mean you're
doing something right.
The average proposal quality has increased over the years. Proposals
that would have been accepted in previous years based solely on the
speaker's reputation suddenly didn't look so good next to the
others. We expect proposal quality to continue to improve. Here are
some factors that go into our paper evaluations.
When BSDCan started the BSD projects were fairly small. The handful of
us could track what was happening everywhere. Over the last decade the
BSD projects expanded. We needed people who keep up on the innards of
these projects, and who could give perspective on papers from the
project's perspective. The papers committee has folks dedicated to
FreeBSD and OpenBSD and NetBSD.
Another part of each concom member's role is to advocate for projects
and proposals they believe in. We expect the OpenBSD representatives
to stand up for interesting OpenBSD papers. We expect the FreeBSD
folks to support interesting FreeBSD papers. We expect everyone to be
able to rank proposals from their project, so that we can have a
useful give-and-take and reach the best possible combination of
presentations.
But the committee as a whole must evaluate the papers. Here are some
criteria we use, in no particular order.
- We must evaluate proposals as they are given. We want to accept
the best proposals. We know how well our repeat presenters speak, but
we still have to look at what they send us. What are they going to
talk about? What are they going to cover? How technical is this talk?
How much detail is in the proposal? Is this well thought out?
- When we have lots of proposals, one talk per presenter. One of
the reasons people come to BSD cons is to hang out with BSD
developers, experts, and assorted related characters. The more of
those we can get into the con, the better experience people will have.
- We are biased towards bringing new people into BSDCan. The BSD
community is growing, and BSDCan must grow with it.
- Papers committee members can submit, but we recuse ourselves
from voting on our own proposals. To eliminate ourselves would be
foolish--for example, Bob Beck's fantastic LibreSSL
talk would not have happened if concom could not present. But we
let the other committee members decide if we're going to talk. Being
a member of the committee is not a guarantee of acceptance. We reject
committee member proposals as readily as anyone's.
- Tracks. We want some sysadmin, some kernel, some hacking, some "I
don't know what this is but it sounds dang cool."
- Presenter. Why should you be the one to give this talk?
- Originality. Has this talk been presented before? We don't demand
originality, but if a talk has appeared before that's a mark against
it.
- New. Is this new tech? New processes? New software? There's a
difference between "here's my new prototype that nobody but me has
ever seen" and "here's new, but in production in several environments"
software. Your previously-unseen basement prototype had better be
spectacular if you want us to take your talk.
- Draw. BSDCan is a business, albeit a nonprofit one. We break even
or die. Everything costs more than you budget, which means that if you
plan to break even you'll lose money. Having a few "big names" means
that people are more likely to attend, which means more registration
fees and more sponsors.
- Can you speak? We've attended talks that look great on paper but
have an unintelligible speaker. Your reputation will precede you. If
you can't speak clearly and distinctly, we won't ask you back. Learn
to speak in public. If you have this problem, but you've done
something to remediate it--say, Toastmasters, or the Dale Carnegie
public speaking courses, or something--say so.
- Diversity. BSD diversity, human diversity.
What other factors weigh in?
We have two separate sets of events: tutorials and presentations. On
the tutorial side, we've learned the hard way that sysadmin tutorials
attract more attendees than networking talks. The farther you go from
a Unix command line, the fewer BSDCan people are interested. The
attendance only supports 2 days of tutorials. We often get twice that.
If you want to submit a tutorial, a half-day one is much more likely
to be accepted than a full-day one.
So, what's in a good proposal? Here's a couple excellent examples from
2015.
First, here's "Expanding RDMA (Remote Direct Memory Access) capability
over Ethernet in FreeBSD" by Shany Michaely. Ms. Michaely had never
presented at BSDCan before.
RDMA (Remote Direct Memory Access) is growing in popularity in Linux
and Windows systems as a way to transfer large amounts of data with
low latency and minimal involvement from the CPU. However RDMA
InfiniBand drivers in FreeBSD were not updated, requiring users to
create or port their own implementation of RDMA, and RDMA over
Ethernet was not available in FreeBSD. This talk will describe how
RDMA works and review the new addition of RoCE (RDMA over Converged
Ethernet) network drivers in FreeBSD, allowing easier implementation
of rapid data transfers with low CPU utilization over Ethernet and
InfiniBand. This also enables the use of iSCSI over RDMA via the iSER
(iSCSI Extensions for RDMA) protocol.
full description:
One of InfiniBand’s valuable capabilities is its support for RDMA
(Remote Direct Memory Access) operations across a network, which
enable rapid data transfer without involvement of the host CPU in the
data path, and data placement to the responder memory without
requiring its CPU awareness.
RoCE (RDMA over Converged Ethernet) is a standard for RDMA over Ethernet.
It provides true RDMA semantics for Ethernet and allows InfiniBand
transport applications to work over an Ethernet network.
FreeBSD is frequently used for storage purposes and RDMA capability
has a high potential of improving performance in such storage
applications.
A good example for that is iSER (iSCSI Extensions for RDMA), a module
being developed nowadays for FreeBSD, which enables the use of iSCSI
over RoCE.
The main idea of this talk is a short overview of RDMA – Its
principles, key components and its main advantages. Additionally, it
will cover the use of RoCE - implementation architecture, obstacles we
overcame in the development, and a quick browse of RoCE’s different
capabilities and milestones.
So, what's in this?
- This proposal clearly states its BSD connection, including which BSD it uses.
- This proposal discusses implementing a new technology
- This proposal says "we accomplished X. This is how. This went wrong. This is what we learned. Beware of these dragons."
For a second example, here's Matt Ahren's proposal for "New OpenZFS
features supporting remote replication." Mr. Ahrens is a BSD
conference veteran.
OpenZFS send and receive forms the core of remote replication
products, allowing incremental changes between snapshots to be
serialized and transmitted to remote systems. In the past year, we
have implemented several new features and performance enhancements to
ZFS send/receive, which I will describe in this talk.
Full description:
This talk will cover:
- Resumable ZFS send/receive, which allows send/receive to pick up
where it left off after a failed receive (e.g. due to network
outage or machine reboot).
- ZFS receive prefetch, which is especially helpful with objects that
are updated by random writes (e.g. databases or zvols/VMDKs).
- ZFS send “rebase”, which can send changes between arbitrary
snapshots; the incremental source is not restricted to being an
ancestor of the snapshot being sent.
In this talk, I will cover the impact of these changes to users of ZFS
send/receive, including how to integrate them into remote replication
products. I will also give an overview of how zfs send/receive works,
and how these enhancements fit into the ZFS codebase.
What do we have here?
- Detail on what will be discussed and newly implemented
features. Anyone can look at this proposal and say "there is meat on
this bone."
- ZFS is a draw, and will bring people into the con. That helps.
- The proposal includes things like the impact of these changes and
how these new features fit into the software.
Here are some common mistakes we see.
- One-sentence descriptions. We judge the talk's merit based on what
you tell us. Anyone can say "I will talk about foobar."
You're going up against proposals like the two above. Give us
detail. The concom cannot read your mind. I had no idea whatsoever
RDMA over Ethernet was a thing before reading that proposal. Every
fooBSD developer might know your name and work--but I
don't. Once upon a time I knew everyone, but that time is years
past. And I'm rating your proposal.
- Not being BSD-specific. We had a very nice proposal for a talk on
a popular scripting language. The proposal did not mention BSD. If we
have a surplus of talks, cutting non-BSD talks from a BSD con is the
obvious route.
- Not including BSD at all. We had a couple proposals from sysadmins
who work in really interesting environments, where simply keeping
hardware and people alive is a challenge. I truly adore those
talks. But, if your proposal doesn't mention which BSD you use, for
all we know you're running everything on Windows XP. Again, this is a
BSD conference.
- Secrecy. Every few years we get a proposal that says "Here's my
provocative talk title. I'm not telling you anything about the talk."
Uh, no. That gives the concom no basis to make a decision on, and
we're responsible for the content of the conference. (It also gives
attendees no basis to decide if they want to see your talk, which is
less of an issue depending on who the speaker is.)
- Bad spelling and grammar implies you can't present. We accept many
proposals written in very simple language. Simple is fine. Wrong is not.
- Don't submit a proposal that consists of running down other
people's work. We're not interested. You’re better off saying why your
stuff is awesome as opposed to denigrating someone else.
We don't accept BSDCan talks solely on the proposal grade in the CFP
system. If we just declared "Accept the top 40 talks, as rated by the
concom," it would be a very different conference, and many
people would be extremely unhappy with the results. A strong
proposal with a lot of information makes it easy for the concom to
rate your proposal highly. If you're willing to spend hours making
slides for your talk, spend a little time making a solid proposal for
those slides.
|
|