Guía de productos Wikimedia / Participación de la comunidad

La Fundación Wikimedia entiende que la participación de la comunidad en el proceso de diseño y desarrollo es primordial para cumplir nuestra misión de proporcionar una infraestructura de base para los [proyectos wiki https://wikimediafoundation.org/our-work/wikimedia-projects/]. Los equipos de producto de la Fundación se proponen colaborar y ser receptivos a los comentarios durante todo el ciclo de vida de un producto.

Comentarios iniciales

Los equipos de Producto de la Fundación deben colaborar y compartir información con las comunidades sobre las distintas funcionalidades de software previstas, tan pronto como sea posible en el calendario del proyecto. La comunicación de propuestas puede incluir objetivos, planes, primeros diseños y otras informaciones.

Los miembros de la comunidad pueden dar su opinión sobre productos y funcionalidades concretas desde sus primeras fases, a través de los canales de comunicación que facilita el proyecto. Lo ideal es que los problemas que puedan bloquear el desarrollo se detecten en esa fase, pero a veces los problemas no surgen hasta la fase de desarrollo.

Un 'bloqueador' es un error, una característica ausente u otro problema que el equipo de desarrollo decide que debe bloquear temporalmente el despliegue en algunas o todas las wikis. Se invita a las comunidades a enviar informes de errores y otras preocupaciones que tengan, para que el equipo de desarrollo pueda determinar si esos problemas deben afectar a los planes de implantación. Un elemento de bloqueo puede influir mucho en un proyecto, aunque su relevancia o legitimidad sean cuestionables. Por lo tanto, para que un elemento de bloqueo propuesto sea considerado susceptible de cambiar el curso de un proyecto de software, debe:

• debe registrarse en el correspondiente proyecto Phabricator de Wikimedia o en la página del proyecto MediaWiki.org, e identificarse explícitamente como una propuesta de bloqueo, para distinguirla de otros errores o peticiones de características.
• ser coherente con el panorama general: la misión, los principios, la estrategia, los planes anuales, las tecnologías de apoyo, etc. de Wikimedia.
• demostrar familiaridad con el plan del proyecto y el uso real de la función cuando esté disponible.
• ser procesables, por ejemplo, "No funciona en este dispositivo" o "Este producto no es compatible con las funciones de supervisión", en lugar de "Simplemente no me gusta" o "Creo que este producto es una pérdida de dinero".
• utilizar argumentos constructivos, datos, alternativas viables y un tono colegiado.
• aportar pruebas de un consenso comunitario cuando hable en nombre de una comunidad.
• tener en cuenta los debates y acuerdos previos. Debe haber muy buenas razones para reabrir un tema zanjado.

Se esperan los mismos criterios de calidad por parte de los desarrolladores u otros colaboradores que no estén de acuerdo con estos puntos de bloqueo propuestos.

En última instancia, la decisión final sobre si cada propuesta de bloqueo debe realmente bloquear el desarrollo o la implantación corresponde al equipo de desarrollo, no a las comunidades.

Despliegue en una wiki determinada

Durante el ciclo de desarrollo, llega un momento en el que las nuevas funcionalidades se ponen a disposición de las personas a las que van dirigidas. Cuando una funcionalidad se lanza a las wikis a través de olas de implementación documentadas públicamente, las comunidades pueden influir a la hora de elegir el mejor momento para la implementación de un producto o una funcionalidad importante en wikis determinadas:

• Las comunidades satisfechas con una nueva funcionalidad o producto pueden solicitar su inclusión en las primeras oleadas, tras demostrar su interés en el canal de discusión de su comunidad.
• Las comunidades satisfechas con una nueva funcionalidad o producto pueden solicitar su inclusión en las primeras oleadas, tras demostrar su interés en el canal de discusión de su comunidad.
• Las comunidades sin opiniones firmes serán programadas por los equipos de desarrollo.

Puede ocurrir que una o sólo unas pocas comunidades sigan retrasando un nuevo producto o funcionalidad, mientras todas las demás se sientan satisfechas con él. Lo más probable es que, o bien el nuevo producto o función siga extendiéndose hasta alcanzar plena cobertura, o bien las preocupaciones de la comunidad acaben convenciendo al equipo de desarrollo para que cambie los planes del producto.

Para retrasar el despliegue de un nuevo producto o funcionalidad en una wiki determinada, la comunidad local debe proporcionar un enlace a una discusión de la comunidad y la lista de errores subsanables, funcionalidades ausentes u otros problemas que les gustaría que el equipo de desarrollo considerara para el estado de "bloqueo". (Lo ideal es que todos aquellos elementos bloqueadores propuestos sean tareas archivadas en Phabricator).

Los equipos de desarrollo participan en el debate sobre los elementos de bloqueo propuestos para determinar si son sensatos, coherentes con el proyecto, procesables, realistas, etc. Si el equipo de desarrollo decide que ninguno de los bloqueos propuestos debe retrasar la implantación, ésta seguirá adelante. Si el equipo de desarrollo decide que algunos o todos los elementos de bloqueo propuestos deben retrasar el lanzamiento, y por tanto aborda esas propuestas, se pedirá a la comunidad una nueva revisión. Si no se encuentran sorpresas, se procederá al lanzamiento.

Algunas implantaciones de software y la mayoría de las eliminaciones de software son obligatorias. Algunas implementaciones, como la propuesta de una nueva API, no pueden gestionarse como oleadas sucesivas de implementaciones a lo largo del tiempo (en su lugar, estas implementaciones se producen en todas las partes a la vez). En esos casos, las comunidades locales no podrán influir en el calendario.

Configuraciones locales

Algunas configuraciones locales sólo pueden establecerse en el servidor, normalmente por los equipos de desarrollo de la Fundación. En algunos casos, pueden establecerse configuraciones distintas para los usuarios registrados y los usuarios anónimos. En términos generales, las personas que forman el núcleo principal de la comunidad pueden representar bien sus propios intereses, mientras que los equipos de desarrollo pueden aportar datos y análisis sobre las personas lectores y otras colaboradoras.

Ante estas circunstancias, las comunidades deberían tener la oportunidad de debatir estas configuraciones locales, en estos términos:

• Las comunidades tienen prioridad para definir la primera configuración que se probará para las características que afectan principalmente a las personas colaboradoras con experiencia.
• Los equipos de la Fundación Wikimedia tienen prioridad para definir la primera configuración que se probará para las funcionalidades que afectan principalmente a las personas lectoras y a los nuevos colaboradores.
• Los objetivos y los datos recopilados deben incluirse en el plan de lanzamiento, y los datos recopilados deben compartirse (a menos que haya problemas de privacidad, que deben explicarse en el plan de lanzamiento).
• Si una configuración inicial no produce los resultados esperados, los equipos de desarrollo pueden probar alternativas antes de decantarse por una configuración estable.
• En última instancia, la responsabilidad de definir las configuraciones de los productos corresponde a la Fundación Wikimedia.

Agradecer a las personas

El tiempo de las personas voluntarias es un recurso escaso y precioso. Agradece a los demás sus comentarios constructivos, aunque al final no estés de acuerdo con sus consejos. Si una persona voluntaria contribuye significativamente a tu proyecto, asegúrate de reconocer sus aportaciones, del mismo modo que reconocerías una contribución similar de cualquier colega que trabajara en otro equipo. El equipo lingüístico lo hace sistemáticamente incluyendo agradecimientos y destacando en negrita las contribuciones de las personas voluntarias en sus informes mensuales (ejemplo).