Designing the application form
El formulario es una herramienta de cribado que se ejecuta antes de que cualquier revisor humano lea nada. Cada campo es un trade-off: mejora tu capacidad de comparar candidaturas o añade fricción que te hace perder buenos envíos. El número correcto de campos es menor del que la mayoría de organizadores cree.
Los campos que consistentemente justifican su lugar:
• Título de la charla y abstract de 100-200 palabras. El mejor predictor único de la calidad de la charla. Si solo tuvieras un campo, sería este.
• Tres a cinco learning outcomes o "qué se llevará la audiencia". Obliga al candidato a articular valor, no solo tema.
• Preferencia de formato (charla, workshop, panel, lightning) y duración.
• Selección de track o tema desde una lista fija.
• Bio del ponente (un párrafo, más versión larga opcional).
• Uno o dos enlaces a charlas anteriores (vídeo preferido, deck o transcripción aceptable).
• Campos logísticos: ubicación, disposición a viajar, necesidades de alojamiento, requisitos de accesibilidad.
Campos a descartar salvo razón específica: deck completo de la charla, guion completo, tres referencias, campos repetitivos que preguntan lo mismo desde ángulos distintos, cajas de texto libre "¿algo más?" que nadie lee. Cada uno aleja una proporción medible de candidatos senior.
Marca los campos opcionales explícitamente. Los ponentes senior rellenan formularios deprisa cuando confían en que el formulario no les va a sorprender a mitad.
Un formulario de solicitud de ponente estructurado en SpeakUp captura los campos anteriores por defecto y enruta las candidaturas a una cola de revisión con prompts por revisor.
Scoring rubrics and panel calibration
Una rúbrica es el documento que tus revisores deberían tener delante mientras leen cada candidatura. Sin una, cada revisor puntúa contra su propio modelo implícito y la reunión final se vuelve un debate sobre qué significa "bueno" en lugar de qué charlas entran en el line-up.
Una rúbrica viable tiene tres a cinco dimensiones, cada una puntuada de 1 a 5, con una frase describiendo cada nivel. Dimensiones comunes:
• Relevancia al track — ¿esta charla pertenece al track al que se presentó?
• Profundidad de expertise — ¿el candidato tiene la autoridad para dar esta charla?
• Novedad — ¿la perspectiva es fresca, o hemos visto versiones de esta charla en tres conferencias este año?
• Claridad de takeaways — ¿se llevará la audiencia algo concreto?
• Speaker craft — ¿el vídeo previo muestra dominio de la sala y el material?
Antes de que el panel revise de forma independiente, calibra. Elige tres candidaturas de muestra (una fuerte, una borderline, una débil) y haz que todos las puntúen en grupo. Discute cualquier puntuación que varíe más de un punto. Veinte minutos de calibración al inicio previenen tres horas de debate después.
Mantén la rúbrica visible junto a cada candidatura durante la revisión. Los revisores deberían poder puntuar y añadir una nota de una línea sin salir de la pantalla.
Reviewing applications efficiently
Con cincuenta candidaturas, tres revisores y la rúbrica anterior, hablamos de unas seis a ocho horas de revisión total repartidas entre el panel — más una reunión final de selección. La estructura que mantiene esto manejable:
• Dos revisores por candidatura como mínimo, tres en casos borderline. Un solo revisor es el asignado; un segundo pase atrapa los casos en que un revisor tuvo una mala tarde.
• Revisa en orden agrupado por track, no por orden de envío. Comparar quince abstracts de sistemas distribuidos seguidos hace la puntuación mucho más consistente que leer uno de sistemas, luego uno de frontend, luego uno de liderazgo.
• Limita las sesiones de revisión a noventa minutos. La calidad cae fuerte después. Tres sesiones de 90 minutos en una semana superan a un maratón de un día.
• Usa una herramienta que permita ver las puntuaciones de los demás solo después de enviar la propia — el sesgo de anclaje está bien documentado.
• Marca, no debatas, durante la fase de revisión. Los revisores añaden una nota corta cuando una candidatura necesita discusión del panel. Guarda el debate para la reunión de calibración con la rúbrica delante.
La diferencia entre un panel que termina la ronda en dos semanas y uno que la arrastra seis está casi enteramente en si las herramientas dejan a la gente centrarse en juzgar en lugar de en logística.
Un software de gestión de ponentes dedicado se encarga de la asignación de revisores, la puntuación ciega, las reuniones de calibración y los workflows de carta de decisión en un solo sitio — mucho menos frágil que una hoja de cálculo compartida.
Communicating decisions
Cómo comunicas las decisiones marca tus relaciones con ponentes para los próximos cinco años. Los ponentes senior recuerdan las cartas de rechazo. Recuerdan especialmente el silencio tras un envío.
Para ponentes aceptados, envía un único email que contenga: confirmación de la franja, próximos pasos, plazos de contenido, contrato o acuerdo de ponente, y un único punto de contacto. No lo dividas en cinco emails. La causa más común de entrega tardía de contenido son plazos enterrados en mensajes dispersos.
Para ponentes rechazados, envía una nota corta y respetuosa dentro de las cuarenta y ocho horas desde la decisión final. Tres frases bastan. Indica la decisión, agradece el envío y — si es cierto — di que les invitarías a una futura edición. No escribas un rationale de rechazo personalizado salvo que tengas tiempo real para hacerlo con cada rechazado. Feedback inconsistente (algunos reciben rationale, la mayoría no) genera más pérdida de goodwill que la brevedad uniforme.
No dejes a nadie en limbo más allá de la fecha de notificación publicada. Si las decisiones se retrasan, envía un email de retención con fecha revisada. El silencio tras la fecha publicada es la forma más rápida de perder tu red de alumni.
Building a reusable application pipeline
La razón por la que la mayoría de organizadores rehacen el proceso CFS desde cero cada año es que no se guarda nada al final de la ronda anterior. La rúbrica vive en el Google Doc de alguien. El formulario vive en un Typeform que alguien duplicó y editó. La lista de revisores está en el grupo de WhatsApp del año pasado.
Al final de cada ronda, archiva: el texto del call, la estructura del formulario, la rúbrica, el historial de puntuación de cada revisor, las cartas de decisión, las listas de aceptados y rechazados con tags ligeros (track, formato, región, seniority) y una retrospectiva de una página sobre qué fue bien y qué cambiar.
La siguiente temporada, la ronda abre con un duplicado de la anterior, ediciones a temas y fechas, y un setup de una semana en lugar de un mes. La base de datos de candidatos compone valor: los rechazados de este año pueden ser invitados proactivamente el siguiente si su abstract sigue encajando. A las tres rondas, dejas de buscar ponentes en frío y empiezas a curar desde un pool que ya mostró intención.