Agradezco que el equipo de Discourse sea abierto a las sugerencias de las personas nuevas, tanto allí como en otros lugares.
He visto que este problema ocurre con frecuencia en Meta a lo largo de los años, pero esto me impulsó a ofrecer también mis ideas en general. También me ha frustrado verlo, pero realmente no sabía cómo plantear el asunto. Así que intentaré escribir sobre ello ahora:
Contexto
A veces, en Meta, he visto una tendencia a acumular sugerencias de personas nuevas para funciones o cambios en Discourse. En lugar de escuchar y comprender la experiencia de las personas más nuevas en el software, cuyas ideas pueden ser útiles incluso para aquellos de nosotros que hemos usado Discourse durante más de 10 años, a veces las personas de la comunidad descartan la idea de forma preventiva.
A menudo, esto se hace si una idea fue rechazada en el pasado por el equipo de Discourse, o si el equipo de Discourse eligió una configuración predeterminada en lugar de otras configuraciones, etc.
Incluso si ese es el caso, me gustaría ofrecer mis ideas sobre por qué no deberíamos descartar preventivamente las ideas o quejas sobre el software, incluso si se han discutido en el pasado.
El equipo de Discourse tiene la última palabra. Han cambiado muchas cosas. Las cosas de entonces pueden no aplicarse ahora.
En primer lugar, nosotros, como miembros de la comunidad, no somos los gerentes de producto de Discourse. Si nos apresuramos a decirle a alguien que su idea ha sido rechazada en el pasado y por qué, esto puede no reflejar necesariamente las decisiones actuales del equipo de producto de Discourse.
A veces, incluso el propio equipo de Discourse puede decidir trabajar en una función que antes se había descartado. Durante mucho tiempo, el chat fue una de esas funciones.
Por lo tanto, nunca hay una garantía del 100% de que las decisiones pasadas serán las mismas que las decisiones presentes.
Incluso las personas del equipo de Discourse pueden tener puntos de vista diferentes entre sí sobre cuál debería ser una prioridad para Discourse.
Por ejemplo, a menudo seguí el blog de @erlend_sh y él discute cómo tenía una visión diferente al resto del equipo sobre cómo debería ser el chat en Discourse: el énfasis en negrita es mío:
La mayoría de los proyectos de código abierto no tienen un foro dedicado, pero los que sí lo tienen casi con certeza también tienen un chat grupal. Mi última experiencia en Discourse fue un intento de fusionar ambos modos, con la introducción de Discourse Chat.
Estoy muy orgulloso de ese MVP (que desde entonces se ha convertido en parte del núcleo), pero la dirección en la que quería ir a partir de ahí era comprensiblemente incompatible con el ADN del proyecto Discourse como un foro tradicional: propuse que el chat fuera el líder de nuestra experiencia comunitaria. La comunidad comienza en las salas de chat, pensé. Discourse no lo pensó así, así que nos separamos amistosamente.
Años después, mi posición se mantiene sin cambios. ‘Chat grupal’ y ‘foro’ deberían significar aproximadamente lo mismo. De hecho, esa es la dirección en la que parecemos dirigirnos, ya que Discord, el rey de nuestras tierras comunitarias, ahora admite una variedad de funciones de hilos y tableros que encajan perfectamente en el paradigma del foro.
Por lo tanto, no nos corresponde a nosotros decidir de antemano qué no debería incluirse en Discourse, ya que eso también puede cambiar con el tiempo.
Aquellos de nosotros de los primeros días de Discourse recordaremos cuando CDCK tenía menos de 10 personas y la gestión de productos a menudo estaba muy impulsada por los cofundadores de Discourse. ¡Pero hoy en día CDCK tiene 100 personas y CDCK tiene un equipo de producto completo!
Discourse en sí tiene una base de usuarios mucho, mucho más grande, cuyas necesidades y uso del software han crecido más allá de los primeros adoptantes iniciales de Discourse. En términos más generales, el panorama de las plataformas sociales ha cambiado (el impulso se ha movido de Facebook a Discord y más, etc.), y las expectativas generales de las personas han cambiado.
Dado que el equipo es mucho más grande que en los primeros días de Discourse, tienen más capacidad para trabajar en otras funciones que pueden haber tenido una prioridad mucho menor durante los primeros días de desarrollo de productos, en el pasado.
Así que la forma en que revisan las solicitudes de funciones ahora probablemente será bastante diferente a como era al principio. El equipo de producto tendrá su propio proceso para la toma de decisiones y para decidir qué se trabaja finalmente y cuándo.
Más puntos de datos son mejores
En segundo lugar, generalmente es útil para el equipo de Discourse escuchar más puntos de datos en lugar de menos.
Había algo popularizado vagamente en Meta como una Regla de 3 (un mínimo de 3 personas que se quejan de algo antes de que se considere esa solicitud de función). Incluso con eso, tienes que dejar que las personas compartan sus experiencias y se quejen, para poder escuchar a 3 personas diferentes encontrar un problema con algo.
Aparte de eso, otra idea popularizada fue el Desarrollo Impulsado por Quejas. Y con esto, también tienes que escuchar las opiniones de la gente:
Lo único que he visto funcionar es sumergirse profundamente en las trincheras con tus usuarios, comunicarte con ellos y cultivar relaciones.
Después de releer eso, también insisto firmemente en que la premisa original detrás de esa “regla de 3” en realidad NO es que tu opinión no importe si nadie más se queja de ella.
El corazón de la cuestión era que (especialmente si eres un equipo con pocos recursos) encontrar las cosas de las que la gente se queja más es una forma eficiente de encontrar los problemas que más molestan a tus usuarios, para poder solucionarlos primero.
Como dice Steve Krug en Don’t Make Me Think:
Siempre encontrarás más problemas de los que tienes recursos para solucionar, por lo que es muy importante que te centres en solucionar los más graves primero. Y tres usuarios probablemente se encontrarán con muchos de los problemas más significativos relacionados con las tareas que estás probando.
Por lo tanto, el hecho de que no muchas otras personas se hayan quejado de lo mismo no significa que no importe. Más puntos de datos siguen siendo útiles para el equipo de Discourse al considerar cuáles son los puntos débiles principales/menores actuales para los usuarios.
Es posible apreciar los comentarios de las personas, incluso si no los implementas
En tercer lugar, todavía es posible agradecer los comentarios de las personas, incluso si no puedes implementar todas sus sugerencias o si has decidido no hacerlo.
Me volví más hábil para manejar los comentarios de esta manera, después de estudiar diseño de juegos, donde dar y recibir comentarios era una parte importante del proceso. En las iteraciones de cada nivel de juego, documento de diseño o cualquier otra cosa, dábamos comentarios sobre el trabajo de al menos otras 3 personas y recibíamos comentarios de al menos otras 3. Solía intentar dar comentarios para 4 o 5 personas para ayudar a compensar la ausencia de otras personas / la entrega tardía de sus tareas, etc.
A menudo, los comentarios de las personas son muy perspicaces y útiles, pero hay más de 10 puntos importantes y en este momento solo tienes tiempo para implementar 1-3 cosas.
Este también fue el caso cuando trabajé profesionalmente como ingeniero de software, interactuando a menudo con la comunidad, como parte de una pequeña startup. Puede haber más de 10 informes de errores importantes, pero en la próxima actualización, tienes tiempo para corregir 1-3 de ellos.
En cualquier caso, todavía me siento muy obligado a agradecer a las personas por sus observaciones, agradecerles por compartir sus ideas, agradecerles por tomarse el tiempo para escribir los pasos para reproducir un error y disculparme por las molestias.
La mayoría de las veces, los usuarios/jugadores no dicen nada a menos que estén realmente molestos. Por lo tanto, la mayoría de los comentarios escritos / solicitudes de funciones / informes de errores provienen de alguien que se tomó el tiempo de compartir sus ideas sobre algo: cosas que muchas otras personas pueden haber pensado pero que aún no han identificado o dicho nada, cosas que probablemente te perdiste, etc.
Por lo tanto, incluso si no puedes implementar todo lo que dice todo el mundo, lo que podría ser el 90% de las veces, no significa que tengas que saltar sobre todos esos comentarios y desestimarlos. Los comentarios siguen siendo importantes, incluso si no tienes los recursos para actuar sobre ellos en este momento o incluso si has decidido no actuar sobre ellos.
De todos modos, por eso creo que vale la pena, para nosotros como miembros de la comunidad, permitir que otras personas más nuevas compartan sus ideas y no saltar inmediatamente a descartar las sugerencias de las personas para Discourse. Esto se debe a que la posición del equipo de Discourse sobre las funciones puede cambiar con el tiempo, y los comentarios siguen siendo útiles como puntos de datos para el equipo de Discourse, incluso si no los implementan en este momento.