About selecting CFP ( from a conference geek)

Me in the backstage of djangoday 2012

I had the joy of organizing a couple of conf with my fellows of WebDeBs. After been an attendee in many conferences and a speaker at some of them it has been a very nice and playful experience be in the staff.


This Year I submitted a CFP for the DjangoCon.eu. They had a fancy and democratic way of selecting CFPs:

• Anonymise submissions, to eliminate bias. 
• The first round of voting is yours: we invite Django community to rate anonymised topics on a scientific 3-point scale (“meh”, “yay”, “MUST HAVE”). 
• De-anonymise for the final selection. 

This sounds good. But there is a problem. I know my own submission and have a plenty of friends with a Github account that can pump my paper even if they are not interested in the conf. Although I appreciate the effort of the DjangoCon.eu having a public voting stage in the CFP selection process lead to a bridle situation. In our confs we have a board of staff members selecting the papers. I think that the aim in  public voting is to have the most wanted talks. And this is great. On the other hand it is not granted due to the fact that "friendly" voting could bias the result. This bias, maybe, have little impact in conf that relies on big communities , which is the Django case. I think The very best process would be a closed voting with the early bid ticket buyers and a second round in which are involved staff members and community leaders or experts. This to empower people that is really coming to the conf on topics that matters.

Another point is about how to deal with submitters. Submitting a CFP involve some work and a bit of courage or pride. Even if a talk proposal is discarded the author should be handled kindly, at least, for the interest and the effort in submitting it. Playing dead and then publish the agenda with the "winners" is poor communication and community management.
It happened to me today. I have submitted a talk for FOSDEM 2013 on 17/12/2012.

One pythonic client to bind them all
Description: Unleash the power of python Metaprogramming with some building tricks to maintain a flexible client for third party API (especially web, restful ones). This won't put an end to functional dependency madness, but it will bring some technical sanity.

Today, looking at planet python I discovered that the agenda for the python track was published. It's not a ego problem. The selected talk are "super good" but an email with a simple email to inform a discarded submitter before publishing the agenda would have shown a better understanding about the fact that no one likes to be rejected.

These are my two cents.