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 wikis individuales
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 individuales:


 * 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. The likely scenarios are that either the new product or feature will keep spreading until reaching full coverage, or the community's concerns will ultimately persuade the development team to change the product plans.

In order to delay the deployment of a new product or feature in an individual wiki, the local community must provide a link to a community discussion and the list of actionable bugs, missing features, or other problems that they would like the development team to consider for "blocker" status. (Ideally, all proposed blockers are tasks filed in Phabricator.)

Development teams participate in the discussion about the proposed blockers to determine whether they are sensible, consistent with the project, actionable, realistic, etc. If the development team decides that none of the proposed blockers should delay deployment, then the deployment will proceed. If the development team decides that some or all the proposed blockers should delay deployment, and then addresses those proposals, the community will be asked for a new review. If no surprises are found, the deployment will proceed.

Some software deployments and most software removals are mandatory. 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).