Après le succès de la 3ème édition de la conférence Devoxx France en avril dernier, je prends le temps maintenant de blogger… et cela fait du bien. Au programme aujourd’hui, un peu de technique, d’architecture et un retour chiffré sur le développement du Call for Paper pour la conférence Devoxx France. Le CFP de Devoxx France est hébergé sur cfp.devoxx.fr. Une nouvelle version sera prochainement utilisé pour la conférence Devoxx Belgique, qui a lieu fin 2014.
Voici les différents articles que je vous propose :
- Qu’est-ce que le CFP ? Quelques chiffres
- L’architecture technique et l‘hébergement
- Zoom sur le système d’autorisation/authentification avec Play2
- Comment modéliser un modèle avec Redis ?
- … et d’autres articles selon l’inspiration
Qu’est-ce qu’un CFP ?
Un CFP (Call for paper, appel aux conférenciers) est un site qui permet de proposer des sujets de présentations pour une conférence. Le système permet aussi de trier, de voter et de sélectionner les sujets, afin de construire le programme. Concernant Devoxx France, le CFP ne fait pas « que » cela. En effet, j’ai aussi codé de quoi faire le programme papier, le site internet du programme, une API REST, un Tweetwall et enfin notre générateur de QRCode pour les badges.
Sur le CFP de Devoxx France (cfp.devoxx.fr), voici quelques chiffres pour vous donner une idée de ce qui s’est passé en 2014 :
- 560 personnes se sont inscrites
- 494 ont proposé au moins un sujet, certains ont proposé 2 ou 3 sujets.
- 292 orateurs ont été refusés
- 202 speakers acceptés (avec les speakers keynotes, les invités, etc)
- 678 propositions ont été reçues par le CFP
- cela a entrainé 7696 revues, par 16 bénévoles pendant plus de 2 mois
- pour sélectionner 163 propositions au final seulement (or keynote et événements spéciaux)
Voilà pour les chiffres.
Le cahier des charges est relativement simple pour ce qui est du côté orateur :
- un orateur doit pouvoir proposer un ou plusieurs sujets, via une interface en FR et EN, en étant guidé pour saisir son sujet
- il doit pouvoir s’authentifier via OAuth pour que le CFP importe et créé sa bio automatiquement, avec Github et Google+
- il est possible d’échanger avec les membres du comité, de discuter et de répondre simplement aux échanges durant la phase de sélection
- il doit pouvoir accepter/décliner les sujets approuvés par le comité
- il peut inviter d’autres speakers enregistrés à co-présenter son sujet tant que le programme n’est pas publié
Dans le rôle du membre du comité de sélection, il y a un peu plus de choses à faire :
- sa page d’accueil lui montre l’ensemble des sujets qu’il n’a pas encore revu
- il peut voir la répartition des sujets par track, par thème, par langue, etc
- il peut discuter sur un sujet précis avec les autres membres du comité, directement sur le site. Cela provoque aussi des envois d’emails pour suivre les discussions
- il peut voter de 1 à 10, 10 étant la meilleure note. Il peut aussi voter 0 s’il ne souhaite pas s’exprimer, ou s’il n’a pas d’avis sur la question.
- enfin il ne peut voir les votes en cours sur un sujet, que si, et seulement si, il a déjà voté. Ceci évite qu’il soit influencé par les votes déjà exprimés.
- chaque fiche résume les votants avec la note, la moyenne, l’écart-type et le nombre de votant.
- enfin, pour le côté gamification, il peut voir son classement, calculé selon le nombre de sujets qu’il a revu, la moyenne de ses notes, afin de se motiver… 678 sujets à revoir, en passant 2mn par sujet en moyenne… ça prend du temps
Enfin en tant qu’administrateur, nous avions aussi d’autres outils :
- un administrateur peut ajouter/retirer un membre du comité
- un admin peut accepter/refuser les propositions selon les votes. C’est lui qui a donc la possibilité d’accepter, selon les votes.
- un admin déclenche l’envoi du mail d’annonce du refus, ou de l’acceptation, par speaker. Ainsi, le speaker ne reçoit qu’un seul email (et pas un email pour chaque sujet)
- il peut construire l’agenda et effectuer la plannification par type de conférence
- il peut exporter la liste des speakers au format CSV, avec les bios, les photos, pour pouvoir l’importer dans Adobe InDesign pour le programme papier
- il peut éditer les QRCodes des badges pour les speakers et les attendees.
- il a accès à Kibana, avec ElasticSearch, pour avoir toutes les statistiques sur les sujets, les notes, etc
- il peut ouvrir/fermer le CFP
- il a la possibilité d’ajouter un sujet « en tant que » speaker, pour les boulets qui n’arrivent pas à saisir un sujet (genre les sponsors)
Voilà pour une petite couverture fonctionnelle.
Passons à l’architecture technique maintenant.
