Skip to content

Instantly share code, notes, and snippets.

@ccoloma
Last active January 24, 2019 22:26
Show Gist options
  • Save ccoloma/7adff7ea25f0ed6cc09bbfb4b1a16825 to your computer and use it in GitHub Desktop.
Save ccoloma/7adff7ea25f0ed6cc09bbfb4b1a16825 to your computer and use it in GitHub Desktop.
Tenemos que hablar sobre herramientas de feedback

Tenemos que hablar sobre herramientas de feedback

Hace unas semanas hemos compartido puntos de vista variados sobre la forma de producir y canalizar feedback. Este tema es subjetivo y puede afectar a cada persona de manera diferente, por lo que desde Koliseo creemos que necesitamos tener una conversación sobre esto.

Nuestros ponentes son los que aportan valor a nuestros eventos, y queremos proteger eso. Hemos llegado hasta aquí confiando en la buena voluntad y las directrices de nuestras comunidades, pero (subjetivo o no) es cuestión de tiempo hasta que alguien decida ignorar nuestra lista de buenas intenciones. Necesitamos herramientas que nos permitan crear la comunidad que queremos ser, canalizando nuestra libertad de expresión de forma constructiva.

Hemos creado este gist para abrir una conversación que nos permita entender qué podemos hacer para mejorar. No creemos que sea posible llegar a una solución satisfactoria para todos, pero queremos contemplar más puntos de vista que la perspectiva limitada de los que hacemos Koliseo.

Actores

El modelo de feedback de Koliseo contempla tres actores:

  • Organizador del evento: puede usar el feedback para entender qué sesiones y ponentes han funcionado mejor, y aprender a evitar los típicos errores en descripciones de charlas. En nuestra experiencia, el feedback negativo es frecuente que sea consecuencia de una descripción que no se ajusta al contenido.

  • Asistente que no ha podido asistir: pueden utilizar estas valoraciones para priorizar las sesiones que quieren ver de la agenda, y descubrir contenidos que sólo con el título normalmente dejarían pasar.

  • Ponente: puede entender qué cosas funcionan mejor o peor en sus presentaciones, compararse con otras charlas de contenido similar, y ganar visibilidad para ponentes que están empezando.

Si es posible, queremos buscar soluciones que nos permitan proteger mejor a nuestros ponentes, minimizando el impacto sobre los otros dos actores.

Podríamos hacer que todos los comentarios sean privados por defecto

Pros:

  • El ponente tiene máximo control sobre la visibilidad de los comentarios, aunque la valoración (en términos de estrellas) sigue siendo visible.

Contras:

  • En nuestra experiencia, el comentario es mucho menos civilizado cuando es privado. En público, y teniendo que firmar con nombre y apellidos, hay tendencia a ser más constructivo.
  • Aun siendo privado el ponente sigue expuesto a este contenido, con lo que el impacto moral es igual.
  • A menudo el comentario es tan importante como la valoración. No es lo mismo un ponente que no conoce bien el tema, que otro a quien le ha fallado una demo.

Sólo feedback en positivo (similar a los aplausos de medium)

Pros:

  • Sólo hay feedback positivo, no hay negativo. La fuerza de esta señal (el número de votos positivos) indica la calidad del contenido.

Contras:

  • Este modelo funciona bien en una plataforma como Medium donde cada artículo está expuesto a una audiencia comparativamente similar. Sin embargo, en eventos como Commit hay charlas que están expuestas a 450 personas y otras a 100, sólo por el tamaño de la sala. Sin entrar en buena o mala fe, el tamaño diferente de la audiencia introduce un sesgo hacia salas con mayor audiencia.

  • Este modelo es más difícil de controlar el hacking social, dado que una misma persona podría introducir aplausos manualmente para tratar de ganar publicidad. Medium puede utilizar sus propios algoritmos para decidir los contenidos a mostrar en portada (automáticamente midiendo la heterogeneidad en los votos, o más probablemente, de forma manual). En Koliseo este tipo de esfuerzo es mayor de lo que podemos asignar a esta funcionalidad.

Mecanismo de censura: un botón para marcar un comentario ofensivo

Si este flag viene del organizador del evento o del speaker, el contenido se considera automáticamente ofensivo. Si viene de los asistentes al evento, habría que decidir qué algoritmo emplear para clasificarlo (porcentaje de asistentes, porcentaje de visualizaciones, etc).

El contenido marcado como ofensivo se ocultaría a posteriores visitantes, pero todo el mundo puede manualmente hacer click para verlo (de forma similar a como funciona Hacker News). Falta discutir si se va a permitir editar el comentario en este caso (que no cambiaría este flag)

Pros:

  • Se crea presión social para revisar el comentario. Cuando tu texto es accesible al público pero se encuentra oculto por defecto, queda claro que algo de lo que se dijo no cayó bien. Todo el mundo puede ver eso, y es información para la persona que deja el comentario que no tenemos actualmente.

  • Es el mecanismo usado por Stack Overflow y Hacker News, que no son comunidades perfectas, pero tienen un grado de éxito razonable en lo concerniente a community governance.

Contras:

  • Es susceptible de ser abusado por terceros.

Requerir comentario positivo y negativo

En la actualidad, el comentario es opcional para cinco estrellas, recomendado para tres o cuatro, y obligatorio para una o dos estrellas. Con esto se intenta dar información al ponente, dado que en las primeras versiones nos quedó claro que un feedback de una estrella sin comentario no sirve para mejorar.

Estamos valorando separar el campo comentario en dos campos: qué ha ido bien y qué es necesario mejorar, ambos obligatorios para 1-2 estrellas.

Pros:

  • Fuerza a equilibrar el feedback positivo y negativo.

Contras:

  • Es mayor superficie de fricción para dejar feedback, duplicando el trabajo. Cuando se quiere dejar feedback en todas las charlas que se han visto de una agenda, es posible que más gente deje la tarea a mitad por ser demasiado costosa.

Karma

No queda claro en qué forma podría ayudar un sistema de control de karma como el de Hacker News, Stack Overflow o Slashdot.

Nos gustaría conocer tu opinión

Esta conversación puede enriquecerse con la aportación de todos. Por favor, añade tu opinión como comentario en este gist. Gracias!

@javiercoloma
Copy link

hola! ... dos aportaciones:

  1. En la parte de mecanismo de censura podríais valorar que cuando un usuario externo marque un comentario como ofensivo el speaker o el organizador deban aprobar o no dicha marca. No se debe descartar alegremente un comentario y menos una aportación de alguien ajeno indicando si podria ser ofensivo.

  2. Feedback positivo y negativo: Creo que requerir ambos comentarios, como bien adelantáis en el post, aumentaría el esfuerzo de dar feedback y reduciría mucho el resultado. Como está no me parece mal. En eventos como Commit con tantas charlas se hace bastante complicado poder dar ese feedback

Aprovecho para dar otra aportacion: En el caso de Commit cuando accedes a la agenda puedes marcar cuales tienes interes. resultaria interesante poder filtrar en cuales has mostrado interes para poder ir eligiendo a que charla vas el dia del evento cuando te coinciden varias. Te permitiría tener "tu agenda" de ese evento.

un saludo

@icoloma
Copy link

icoloma commented Jan 17, 2019

Tiene pinta a que el "botón para marcar un comentario ofensivo" sería la medida más urgente, y pueden verse resultados a partir de ahí. El karma podría resultar útil para identificar usuarios sistemáticamente tóxicos y bloquearlos o bien automáticamente censurar sus comentarios.
El gist no menciona ghost shadowing, pero siendo realista parece demasiado esfuerzo para el momento actual.

@icoloma
Copy link

icoloma commented Jan 19, 2019

Hay una opción mencionada por @miguepiscy que consiste en dar feedback por separado de diferentes aspectos de la charla: conocimiento, slides, etc. En ese sentido, el Android Market hace algo parecido.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment