Reversim 2015 — How did we select the sessions?

Reversim Summit is a free yearly conference for the Israeli software developer community. The conference is organized by developers and is not for profit.

This is the third time the conference takes place and over the years it had gotten rather popular, this popularity is articulated by the impressive number (160!) of sessions submitted during the rather short one week in which Call For Papers was published. Of these, just 45 got selected.

Following some valid queries that were raised during the aftermath of the decision phase, we felt it would be beneficial and inline with the conference spirit to publish the process we went through.

In addition to that, we urge everyone who have suggestion on how to improve in the future to reply back to the team with any such comments, we know there is room for an improvement and year over year, we plan to eventually get it right ☺

So, who are “the team” ?

By mid Jan/2015, Ran assembled the team. These are people Ran and Ori know from past positions, current position, podcasts, friends and past conference attendees who’d volunteered. There was no “team selection” anyone who wanted to become a team member was welcomed. The bio of the team members is available.

The team is all technical, with many years of experience each, working in tiny startups and full size enterprises. Working with diverse technologies spanning all the way from C++ to iOS, Python and Ruby.

It’s a team of highly talented developers bringing to table both knowledge and experience in addition to passion to what we all do.

Unlike 2013 and 2014, the 2015 timeline was extremely tight, mainly because of the venue restrictions and availability.

Track Categorizations and initial selection phase

Once the one week of CFP was over, a team member went over all sessions, tagged and classified them to try and come up with a number of specific track titles. We intentionally attempted to do so after the submission phase, so that the submissions themselves will create the tracks instead of the other way around.

Once classification was completed, A moderator has volunteered to each of the tracks with the task of diving into further details for each of the sessions, asking for whatever more information is needed from the submitter, and selecting 4–6 of the best as potential candidates for acceptance.

This was by far the hardest part of the process, there are very few, if any, bad submissions. A moderator of a full-length track will now have to choose 1 session for every 6 she is going to reject, and even this 1 might eventually not get in because we realized we only have room for 3 sessions out of each track.

The tracks we came up with were: Backend and Scaling (Haim), Programming languages (Itay), Management, quality and culture (Yoav), Ops and automation (Victor), Frontend web dev and mobile (Ori) and all the rest of the cool stuff (Lital). Two additional (non-full-length) tracks were Ignites (Tal) and OSS (Dotan)

How is that done ?

The moderator assigned to the track is an experienced developer and his personal taste is an important factor, however, as a team, we came up with detailed guidelines to help in this selection phase, this are soft rules, but act as a good starting point.

Pros:

  • Innovative — A complete new take on a known problem, Something that screams out-of-the-box
  • Mind Blowing — A sufficiently complex + interesting subject that when described verbally provides an added value as oppose to reading on paper.
  • Inspiring — A code project or HR+Code related project that is of a nature we should promote for good.
  • In-depth personal experience — An item that the speaker had deep dived into for practical use, and not for the sake of the session, and can provide meaningful inputs.
  • Hebrew — we prefer hebrew speakers, but that’s not a must.
  • If it’s on the wishlist and has many votes.

Cons:

  • Intro to X — Defiantly so if a google search will provide Ms of results + Videos.
  • Sufficiently battled subject — “Why Should I TDD” kind of sessions.
  • Extremely esoteric
  • Pure Academic — We should probably promote practicality
  • Way Too Broad — “Comparison of JVM based Languages”
  • Try not to have too many sessions from the same speaker. Preferably — just one session from each speaker.

Asking for more info from speakers

In many cases (but not all) we asked submitters to provide additional details for their sessions, in some cases we asked for a bulleted list of topics and in other cases we asked for a draft or a skeleton of the slides.

The purpose of this was to better understand the topic and/or the level of experience of the speaker and how well he/she is versed in the topic.

Final Vote

Each moderator also had super powers, e.g. veto-in one session and veto-out one session (which btw, were not used even once this year).

Once votes are calculated and the actual agenda starts to form, cases of particularly long or short sessions, how many sessions we have selected, when do we want to start and when we want to end each day, everything is now playing into the mix to create the finalized agenda.

Closing tune

Since we concluded that in majority of the cases, a submission will not get in not because of a problem with it, but because other sessions just scored better, we used a mail template for the Accepted and Not Accepted notification to each speaker.

The entire process of selection was scheduled to about 10 days after which we started sending accept/reject emails (we slipped this schedule by 1 day).

Tell us what do you think!

We are working hard on making the conference better year over year by learning from mistakes and getting feedback from the community. There are already several mistakes we’ve made and lessons we’ve learned already. Getting your feedback will help us improving the process even further.

We are very much open to any feedback, please let us know what can we do better next year !

One clap, two clap, three clap, forty?

By clapping more or less, you can signal to us which stories really stand out.