Community Wishlist/Lista de deseos de la comunidad 2027

Futuro de la Lista de deseos de la comunidad

Hola, soy Sonja y dirijo algunos de los equipos de la Fundación Wikimedia que se encargarán de seleccionar las propuestas de la comunidad en el marco del nuevo proceso de la lista de deseos. Como quizá sepáis, la Lista de Deseos de la Comunidad comenzó como un proceso anual a través del cual quienes colaboran con los proyectos Wikimedia envían y votan las mejoras técnicas en las que les gustaría que trabajara la Fundación Wikimedia. El objetivo principal es, y siempre ha sido, mejorar la experiencia de edición mediante la implementación de los cambios y las funciones que la comunidad solicita específicamente. En los últimos años, el proceso que rige la lista de deseos ha cambiado, y muchos de vosotros nos habéis comentado que ya no satisface las necesidades de gran parte de la comunidad. Por ello, la Fundación está diseñando ahora un nuevo proceso junto con la comunidad para mejorar la forma en que se clasifican, se votan y se priorizan las propuestas, de manera que sea un procedimiento transparente, equilibrado entre las distintas familias de proyectos y versiones lingüísticas, y tenga en cuenta la capacidad de la WMF. Por ello, me gustaría recabar la opinión de la comunidad específicamente sobre estas tres etapas del proceso de la Lista de deseos:

• La «fase de selección», es decir, cómo se concretan, organizan y filtran las propuestas antes de la votación
• La «fase de votación», que incluye quién puede votar y cómo se estructuran los votos
• La «fase posterior a la votación», que incluye cómo garantizar la equidad a la hora de priorizar las tareas

A medida que leas las ideas propuestas a continuación, no dudes en dar tu opinión sobre si crees que funcionarán bien o si hay formas de mejorarlas. Este primer ciclo de votación pretende ser un primer paso para probar un nuevo proceso, y habrá más oportunidades para aportar comentarios a lo largo del camino, de modo que podamos determinar junto a ti cuál es el mejor proceso para los próximos años.

Fase 1: Evaluación inicial

Aunque la lista de deseos permanecerá abierta durante todo el año para la presentación de nuevos deseos, se realizará una convocatoria ampliamente difundida para la presentación de deseos durante las dos últimas semanas del plazo de presentación, en octubre/noviembre. Una vez cerrado el plazo de presentación de deseos, se reunirá un grupo de trabajo para evaluar los deseos presentados. El grupo de trabajo estará formado por personas de la comunidad familiarizadas con el proceso de la lista de deseos y con el código fuente de MediaWiki, junto con personal de la Fundación Wikimedia:

• Personas de la comunidad (unas cuatro o cinco personas), que idealmente incluyan:
  • Alguien de las Wikipedias pequeñas y medianas
  • Alguien de las Wikipedias grandes
  • Alguien de los proyectos hermanos (por ejemplo, Wikcionario, Wikisource, Commons, Wikidata, etc.)
• Personal de la Fundación Wikimedia que forme parte de los equipos que trabajarán en las propuestas:
  • Product Managers e ingenieros/as de los equipos de producto y técnicos pertinentes, como Edición, Herramientas de moderación, PSI, Readers & Apps, y Transformación de contenidos.
  • Comunicaciones del Movimiento

Actividades de triaje

El grupo de trabajo se reunirá una vez al año, en noviembre, durante un periodo de entre 2 y 4 semanas, desde el momento en que se presenten las propuestas hasta que se sometan a votación. Se centrará en:

• '“'Deduplicación”: Se identificarán y fusionarán los deseos que sean sustancialmente similares, conservándose ambas solicitudes originales como referencia.
• Estimación preliminar del esfuerzo: El grupo de trabajo asignará una estimación de tamaño relativo a cada petición (por ejemplo, XS, S, M, L, XL). La clasificación por tamaños es relativa, no absoluta: refleja el nivel de trabajo necesario, es decir, cómo se compara una petición con otras en cuanto al esfuerzo que requiere, y no supone un compromiso con un plazo concreto.
• Aclaración y refinamiento: Las propuestas se vincularán a tickets de Phabricator relacionados, trabajos previos o propuestas ya existentes. Los miembros del grupo de trabajo plantearán preguntas aclaratorias a quienes hayan creado las propuestas. Cuando sea pertinente, el grupo de trabajo añadirá información sobre los motivos por los que una propuesta no se ha abordado anteriormente. Asegurarnos de que comprendemos el impacto deseado de la propuesta también forma parte del proceso de aclaración y refinamiento.
• Agrupación y fusión / grandes inversiones: Cuando varias peticiones aborden la misma necesidad subyacente, el grupo de trabajo podrá agruparlas o fusionarlas e identificar las grandes necesidades subyacentes en las peticiones (por ejemplo, «estas peticiones concretas solicitan, en esencia, un sistema de revisión de ediciones»). Todas las peticiones que las componen seguirán siendo visibles y se mantendrá su atribución, y, siempre que sea posible, se eliminarán los duplicados.
• Las propuestas no se acumulan: En los años inmediatamente anteriores a que la lista de propuestas estuviera abierta todo el año, las propuestas en las que no se había trabajado no se incluían en las nuevas encuestas de propuestas. Esto se hacía para mantener la lista de propuestas pendientes en un tamaño manejable y para garantizar que se trabajara en las propuestas más relevantes para ese año en concreto. Recomendamos volver a esta estructura, lo que significa que, de ahora en adelante, solo las propuestas enviadas por primera vez en el ciclo actual se incluirán en la clasificación y la votación. Los deseos de años anteriores que aún no se hayan completado tendrían que volver a enviarse si siguen siendo relevantes para la comunidad. Los recuentos de votos anteriores no se mantendrán. Sin embargo, en el «primer» periodo de votación que tendrá lugar el próximo mes de enero, incluiríamos los deseos pendientes de la lista de deseos existente para asegurarnos de incluir los deseos enviados durante los meses en los que nos encontramos ahora.
• Evaluación del impacto potencial: Si llevar a cabo esta propuesta supone dejar de lado otras tareas que la comunidad necesita, dejaremos clara esa disyuntiva en la propuesta. Y si se dispone de datos para determinar el impacto potencial de una propuesta (como el número de usuarios que la verían), el grupo de trabajo añadirá esta información a la propuesta para que la comunidad pueda tenerla en cuenta a la hora de votar.
  • Ejemplo: Solo el equipo de Site Reliability podría llevar a cabo la propuesta, pero si lo hiciera, se pospondría una tarea crucial de detección de bots, lo que supondría un riesgo significativo para el rendimiento. Esta información se añadiría a la propuesta para que se tuviera en cuenta durante la votación.
• '“'Eliminación de deseos:” Un deseo se eliminará si cumple los siguientes criterios:
  • Deseos que estén prohibidos por ley o que puedan poner en peligro al personal de la Fundación Wikimedia, a las personas que colaboran con las wikis o a quienes las leen.
  • Deseos que anulan el trabajo realizado anteriormente o que van en contra de otros proyectos previstos. Sin embargo, estos deseos pueden ser el punto de partida para conversaciones importantes con la comunidad.
    • Ejemplo: Una propuesta solicita que se actualice el asistente para crear artículos de la Wikipedia en inglés con el fin de que resulte más accesible para quienes empiezan a editar, pero parte de la sugerencia consiste en mantener la naturaleza abierta de la edición dentro del asistente. Al mismo tiempo, estamos trabajando en un nuevo proceso, mucho más guiado, para ayudar a las personas novatas a crear artículos nuevos. Estos dos enfoques son contradictorios entre sí y requerirían un debate más profundo.
    • Ejemplo: Una propuesta solicita que se desactive el Editor Visual. Rechazaríamos dicha propuesta por varias razones: aunque muchas personas voluntarias podrían votar «a favor» de ella, hay muchas más que «no» querrían que esto ocurriera; además, gran parte del trabajo que estamos realizando actualmente requiere el Editor Visual (por ejemplo, las comprobaciones de edición), por lo que desactivarlo anularía muchos de los esfuerzos realizados en el pasado, actuales y previstos.
  • Sugerencias que proponen funcionalidades o cambios que requerirían, en primer lugar, un consenso significativo por parte de la comunidad; es decir, sugerencias que cuentan con el apoyo de muchas personas, pero a las que probablemente se opondrían otras muchas.
  • Aunque tengan un impacto positivo para una wiki determinada o un grupo de usuarios/as, hay propuestas que tienen un impacto negativo para otra wiki o otro grupo de usuarios/as; por ejemplo, una propuesta que supone una mejora para quienes ya tienen mucha experiencia en la edición, pero un gran inconveniente para quienes están empezando a editar.
  • Deseos que tengan como objetivo trolear, que sean spam o que versen sobre temas que no sean de carácter técnico.

Sin embargo, no rechazaríamos una propuesta solo por su gran envergadura o porque el equipo correspondiente de la Fundación Wikimedia ya tenga otros planes. En esos casos, es importante conocer el recuento de votos antes de determinar si la propuesta podría incluirse en una hoja de ruta y, en caso afirmativo, en qué parte de la misma.

Para cada sugerencia, un miembro del grupo de trabajo expondrá públicamente el motivo por el que se rechaza. El objetivo de este ejercicio sería identificar que una sugerencia, tal y como se ha presentado, no va a ser viable, e intentar hablar con la persona que la ha enviado para encontrar una vía factible que permita llevarla a cabo. Si no existe dicha vía, entonces la sugerencia podría ser rechazada. Es importante que se eliminen todos aquellos deseos de los que sabemos con certeza que no va a ser posible llevarlos a cabo antes de que las personas voluntarias los voten, para que el voto tenga el mayor peso posible a la hora de determinar cómo se deben priorizar los deseos.

Discuss

Status labels

I'm also interested in hearing people's thoughts about status labels that would be used during the triage process, and their definitions. Here is what we're thinking about for English (translations would have to follow later, likely in collaboration with the community):

• Needs clarification: This wish requires additional clarification and context from the community.
• Declined: The wish cannot be actioned by WMF and is not recommended for a volunteer.
• Patch welcome: Wishes that have not been prioritized by the WMF due to vote count, but are specifically well suited for the community to pick up.
• Prioritized by WMF: The wish has been prioritized by WMF for the current or upcoming fiscal year as a result of the wishlist vote, but work has not yet started. The description on the talk page should indicate when it’s prioritized for, i.e. which quarter or fiscal year.
• In progress: Work is in progress on the wish, or current work is inspired by needs articulated in the wish. Wishes that get done by the community or affiliates should also get this status once they are in progress.
• Done: Wish has been fulfilled explicitly, or aspects of it are sufficiently addressed by alternative solutions. Details about how the wish was completed should be included in the custom response on the wish page, including if the wish was completed by a volunteer or an affiliate and whether the wish was completed as part of a larger effort.
• (NO STATUS): Everything else. All wishes come in with no status. Following triage, this status will again be used for all wishes that have not been prioritized or declined and are not well suited for community patches.

Discuss

Fase 2: Votación

Tras la selección, habrá un periodo de votación abierto, que se anunciará mediante banners en todos los proyectos de Wikimedia. La votación se regirá por las siguientes normas (que son, a grandes rasgos, las mismas que se aplicaban al principio de la lista de deseos):

• Los votos se emiten sobre deseos individuales, no sobre grupos o categorías de deseos.
• Todas las personas que hayan iniciado sesión con su cuenta en Wikimedia pueden votar, incluidos quienes ya tengan una lista de deseos propia en su wiki de origen (como las comunidades a las que presta servicio Wikimedia Deutschland). La participación en un proceso de lista de deseos local no impide participar también en la lista de deseos global. Quedan excluidas las cuentas temporales.
• No hay límite en el número de votos por cuenta, pero cada persona solo puede votar una vez por cada deseo.

Discuss

Fase 3: Tras la votación

La priorización debe estar en manos de la comunidad a través de los votos, lo que significa que son los votos los que determinan el orden de prioridad de las peticiones. Tras clasificar las peticiones según el número de votos, la Fundación Wikimedia revisará la lista para determinar el conjunto específico de peticiones en las que tenemos previsto trabajar.

Queremos asegurarnos de que los proyectos más pequeños y los proyectos hermanos también reciban atención, por lo que cada propuesta se clasificaría en una de estas tres familias de proyectos:

• Wikipedias grandes o que abarcan todas las wikis
• Wikipedias pequeñas y medianas
• Proyectos hermanos

Una vez clasificados por familia de proyectos, analizaríamos las propuestas más votadas de cada familia para ver si alguna de las propuestas con muchos votos de proyectos más pequeños debería incluirse junto con las propuestas más votadas de wikis más grandes.

Otras razones que podrían llevarnos a no seguir al pie de la letra el recuento de votos son, por ejemplo:

• Varios deseos con más votos requieren los conocimientos especializados del mismo equipo. Por ejemplo, si dos de los deseos con más votos son proyectos de gran envergadura que requieren la intervención del equipo de edición, es posible que no se puedan llevar a cabo ambos.
• Decidir si se lleva a cabo un conjunto más reducido de deseos de gran envergadura o un conjunto más amplio de deseos de menor envergadura.

Para que quede claro, sabemos y esperamos que este proceso dé lugar a tareas que no teníamos previsto realizar y que obligarán a los equipos a modificar sus planes; por lo tanto, no rechazaremos propuestas simplemente por esas razones. En cuanto a cualquier cambio que realicemos en el orden de la lista, como dar prioridad a una propuesta con menos votos procedente de un proyecto más pequeño, la Fundación Wikimedia proporcionará una justificación transparente antes de su implementación. A continuación, se pedirá a la comunidad que aporte sus comentarios sobre la lista definitiva antes de que comencemos con el trabajo.

Discuss

Fase 4: Implementación

• La implementación de las propuestas y la iteración del proceso, basadas en los comentarios de este ciclo, se coordinarán a través del Programa de la Lista de Deseos, dirigido por el/la Lead Program Manager que estamos contratando actualmente y ejecutado por los distintos equipos de la Fundación con la experiencia necesaria en la materia.
• El nuevo plazo de presentación de propuestas para el siguiente ciclo de votación comienza una vez que se hayan priorizado las propuestas del ciclo actual. Las nuevas propuestas pueden presentarse durante todo el año hasta que tenga lugar el siguiente periodo de votación.
• Si las propuestas más votadas están dirigidas a un público amplio que no suele participar en la lista de deseos (como lectores/as o las personas novatas en la edición), la WMF podría llevar a cabo estudios y pruebas conceptuales de la idea antes de decidir seguir adelante con su desarrollo. Se trata del mismo criterio que se aplica internamente a nuestras propias ideas de funcionalidades para estos públicos. Es posible que, al realizar la investigación y las pruebas, descubramos que la propuesta no tendrá un impacto positivo. En ese caso, hablaríamos con las personas que la redactaron y votaron sobre esos resultados y sobre los pasos a seguir.

Discuss

Posible calendario

Para el ciclo de este año, tenemos previsto que el plazo de presentación de deseos sea a finales de octubre o principios de noviembre y que el proceso de selección concluya a finales de noviembre. Para respetar el periodo vacacional de fin de año, la votación tendría lugar entre principios y mediados de enero. Antes de dar por definitiva la lista de deseos, se publicará en Meta a principios de febrero para recabar las opiniones de la comunidad. El objetivo es tener lista la lista de deseos para nuestro proceso de planificación anual, que comienza en febrero de 2027, con el fin de orientar nuestros planes para el ejercicio fiscal 2027/28 (de julio de 2027 a junio de 2028). También queremos que esta primera votación establezca las prioridades de trabajo relacionadas con los deseos para los últimos meses del ejercicio fiscal actual (es decir, hasta junio de 2027), de modo que dicho trabajo pueda reflejar las prioridades de la comunidad lo antes posible.

Discuss

Preguntas para la comunidad

Nos interesa especialmente recibir opiniones sobre las siguientes preguntas en la página de discusión, aunque, por supuesto, también son bienvenidos los comentarios sobre otros aspectos de la propuesta.

• ¿Es la división en tres grupos según la familia de proyectos (Wikipedias grandes / Wikipedias pequeñas y medianas / proyectos hermanos) la forma adecuada de garantizar que las distintas comunidades estén representadas de manera equitativa? ¿O tenéis otras sugerencias sobre cómo garantizar la equidad entre los proyectos y las ediciones lingüísticas?
  Discuss
• Este borrador de propuesta intenta encontrar un equilibrio entre dos aspectos que presentan cierta tensión inherente: garantizar que la Fundación Wikimedia atienda los deseos más votados —incluso modificando los planes actuales de los equipos según sea necesario— y la realidad de que existen «algunos» límites en cuanto a lo que podemos ofrecer desde el punto de vista técnico o realista. ¿Logran los planes relativos a la «eliminación de deseos» y a la «fase posterior a la votación» alcanzar el equilibrio adecuado?
  Discuss
• Sabemos que el requisito de volver a enviar las peticiones de años anteriores supone una carga adicional para la comunidad, pero las ediciones anteriores de la lista de deseos han demostrado que, si no se establece un límite en este sentido, pueden producirse atrasos insostenibles. ¿Se te ocurre algún mecanismo que pueda reducir la carga que esto supone para la comunidad?
  Discuss