Wikimedia Product Guidance/Community involvement/es

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. Some deployments, such as offering a new API, cannot be handled as successive waves of deployments over time (instead, these deployments happen everywhere at once). In those cases, local communities will not be able to influence the timing.

Local configurations
Some local configurations can only be set server-side, usually by Foundation development teams. In some cases, separate configurations can be set for logged-in users and anonymous users. Generally speaking, core community members can represent their own interests well, while development teams can bring data and analysis about readers and other contributors.

Given these circumstances, communities should have a chance to discuss these local configurations, in these terms:

Ultimately, the responsibility for defining product configurations belongs to the Wikimedia Foundation.
 * Communities have priority for defining the first configuration to be tested for features primarily affecting experienced contributors.
 * Wikimedia Foundation teams have priority for defining the first configuration to be tested for features primarily affecting readers and new contributors.
 * Goals and data gathered need to be included in the release plan, and the data gathered needs to be shared (unless there are privacy concerns, which should be explained in the release plan).
 * If an initial configuration is not producing the expected results, the development teams can test alternatives before they settle on a stable configuration.

Thank people
Volunteer time is a scarce and precious resource. Thank people for constructive feedback, even if you ultimately disagree with their advice. If an individual volunteer contributes significantly to your project, be sure to acknowledge their contributions, just like you would acknowledge a similar contribution from a fellow staff member who worked in another team. The Language team does this consistently by including acknowledgments and highlighting volunteer contributions in bold in their monthly reports (example).