I’ve been invited by Benjamin Cabe to be part of the Program Committee (PC) for EclipseCon France. Benjamin told me it wouldn’t take too much time and I thought it would be something interesting. Benjamin was partly right (it does not take too much time, but it definitely takes some time), and I was totally right to think it would be a good experience.
Here are some additional thoughts and explanation about how a Program Committee works
So many (good) proposals! So few slots!
I guess that’s always the problem when it comes to setting up a conference program. There are always more good talks than the program contains slots. For EclipseCon France, here are the numbers: 130 submissions for 33 slots. So it means that 97 submissions were rejected, including a lot of great ones. That is very frustrating at the beginning when you see so many good proposals being declined, but there’s no way to change that, so PC has to deal with it…
So much diversity! So much consistency!
Although I’ve been involved in the Eclipse community for some time now, I’ve been impressed by the diversity of concerns in the Eclipse community and eco-system while reviewing submissions: Machine-2-Machine, Diagrams & DSLs, Requirements, ALM (ie. Testing, Code Quality, Development Productivity…), JVM languages, other languages, Mobile/Web/Cloud, Product management… among others. That’s awesome because all the specific concerns of a topic also apply (with different priority) to other topics. I think that’s what makes Eclipse and the Eclipse conferences great places for innovation: you can learn and understand from people who do very different things than you, because we share this Eclipse thing.
There are so many topics in the Eclipse community that 3 conferences a year are not too much to cover them all ;)
How does a PC work?
I find it interesting to tell you how talks are selected because I have submitted so many talks and got so many declined in the past that it’s good to know how to turn them “sexier” for a next conference and improve their chances of getting accepted.
Each PC member may grade the proposals (from 0 to 5). So every PC member reads all submissions and grades them. After it’s done, our dedicated PC chair (Benjamin) sends us a summary of the talks sorted out according to average grade, and then starts the time to negotiate: some PC members have very high interest in some talks and may try to convince other PC members to increase their grades on a submission so it gets to the top of the list. Some of these negotiations do work and change the list of accepted talks. At the same time, we try to get some talks to merge to avoid redundant talks and to increase the amount of topics covered. For instance, that’s how we could merge some IWG or Requirements-Oriented talks, so we are sure these topics are well covered by the program but leave some free slots for other talks. We did another round of negotiations, and we finally got the list of selected talks.
Advices for future submissions
Now that you know how selection systems work, you can understand that the grades for your submissions will highly depend on the people in the Program Committee. For EclipseCon France, we have an “industry-oriented” program committee, so it’s easier to get a good average grade if you speak about industry, because it speaks to the majority of the PC. To the contrary, I was the only one showing a big interest in Mobile/Web/Cloud stuff (since that’s our business at JBoss), so it appeared that most Web-oriented submissions did not get enough interest from other PC members to get into the program.
Based on that experience, here are a few tangible pieces of advice for your future submissions:
- Make your title and abstract very clear and explicit: PC members review a lot of submissions, and read those submissions quickly. So write your title and abstract in a very efficient way to ensure PC won’t miss the point. I admit there are some talks I did read too quickly to understand how good they were, and I changed my mind when negotiating with other PC members to increase the grade I gave. It can happen to any PC member. Try to make you submission clear enough to compensate a potential PC failure.
- Highlight the added-value of your presentation: What makes a good talk is a talk that brings value (re-usable knowledge) to attendees. So it’s interesting to make what your talk will bring to the attendees clear: when selecting a talk, PC members (at least me) are not that interested in what will be presented in the talk but they care about How will the attendee be able to take advantage of the content of this presentation? It’s also interesting to say whether what you’d like to present contributed to a success-story and could be repeated by attendees to create some more success-stories.
- Open-up: Eclipse is a big community, you’re probably about to present a small subset of what’s happening in this community. So try to make your presentation useful to other areas in the community. Could your presentation open to other related technologies/fields?…
Whatever is the topic, a clear submission that shows how you used a technology to solve a usual or trendy use-case and how this solution can apply to other use-cases has very big chances of being accepted.