Le breizhcamp a ainsi reçu 120 propositions, soit à peu près 2 fois le nombre de sessions. Le tri est donc assez facile comparé à une conférence comme Devoxx, avec 500 talks "conférence" pour 50 slots à pourvoir, et des notes du coup très serrées.
Car il y a aussi les notes : chaque membre du CfP vote pour les sujets en donnant une note de 1 à 5, selon des critères qui lui sont propres (speaker, sujet, ...) et sans connaître les notes de ses camarades. Il peut aussi bien sur ne pas voter pour les sujets sur lesquels il n'a pas d'avis, faute de connaître le domaine évoqué.
Pour gérer ces votes, nous (enfin, surtout Yan) avons développé une application pile poil pour gérer les votes, ce qui nous a permis de traiter le 120 sujets en quelques heures.
L'étape suivant c'est de dépouiller les résultats. Aussi nous nous sommes retrouvés pour appliquer l'algorithme suivant :
def selection( format: String, talks: List[talk] ) : List[talk] =
check(talks). // relecture des propositions
sort( talk => talk.note ). // tri par note
filter( talk => agree )
agree étant une fonction qui prend en paramètre l'équipe du CfP, passe par une étape de discussion récursive pour donner un résultat booléen.
L'idée est de remplir un tiers du programme en fonction des notes, puis de regarder dans ce qui reste ce qui est redondant, innovant, etc et qui mérite d'être sélectionné tout de même, ou bien de reclasser un sujet dans un autre format en fonction des informations que nous a fournis le speaker.
Nous arrivons ainsi au programme dont une version graphique sera publié dans quelques jours. Les speakers promus ont été notifiés, les autres devront se contenter de venir en spectateur.
Je sais la déception que peut être de ne pas être retenu à un CfP, la frustration d'avoir proposé un bon sujet qui n'est pourtant pas retenu, amis speakers ne nous en voulez pas, la tâche n'est pas facile et il faut bien trancher à un moment donné.
0 commentaires:
Enregistrer un commentaire