Guide des produits Wikimédia/Implication de la communauté

La Fondation Wikimedia comprend que l'implication de la communauté dans le processus d'architecture et de développement est primordial pour remplir sa mission de fournir une infrastructure essentielle pour les projets de wiki. Les équipes Produit de la Fondation s'efforcent d'être collaboratives et réceptives aux commentaires tout au long du cycle de vie du produit.

Premiers commentaires

Les équipes Produits de la Fondation devraient collaborer et partager des informations avec les communautés sur les fonctionnalités logicielles envisagées, le plus tôt possible dans le calendrier du projet. La communication de propositions peut inclure des objectifs, des plans, les premières architectures et autres informations.

Les membres de la communauté peuvent fournir des commentaires sur des produits et des fonctionnalités spécifiques dès le début, par l'intermédiaire des canaux de communication pris en charge par le projet. Idéalement, les problèmes qui pourraient bloquer un développement ultérieur seront identifiés à cette étape, mais parfois ils ne se manifesteront qu'à la phase de développement.

Un élément bloquant peut être un bogue, une fonctionnalité absente, ou tout autre problème que l'équipe de développement juge comme pouvant bloquer temporairement le déploiement sur certains wikis ou tous. Communities are invited to submit bug reports and other concerns that they have, so that the development team can determine whether those problems should affect the deployment plans. Un bloqueur proposé peut avoir de grosses conséquences sur un projet, même si on peut s'interroger sur son importance et sa légitimité. C'est pourquoi pour qu'un blocage proposé soit considéré comme susceptible de modifier le cours d'un projet logiciel, il doit :

• être déclaré dans le projet Wikimedia de Phabricator ou sur la page du projet MediaWiki.org associée, et être explicitement identifié comme un bloqueur proposé, pour le distinguer des autres bogues ou demandes de fonctionnalité.
• être cohérent avec le tableau général : mission de Wikimedia, principes, stratégie, plans annuels, technologies prises en charge, etc.
• démontrer sa familiarité avec le plan du projet et l'utilisation actuelle de la fonctionnalité, quand celle-ci est disponible.
• be actionable, e.g., "It doesn't work on this device" or "This product doesn't support oversight functions", rather than "I just don't like it" or "I think this product is a waste of money".
• use constructive arguments, data, actionable alternatives, and collegial tone.
• provide proof of a community consensus when speaking in the name of a community.
• take prior discussions and agreements into account. There must be very good reasons to re-open a settled topic.

The same quality criteria are expected from the developers or other contributors disagreeing with these proposed blockers.

Ultimately, the final decision about whether each proposed blocker should actually block development or deployment belongs to the development team, not to communities.

Déploiement sur les wikis individuels

Durant le cycle de développement il arrive un moment où les fonctionnalités sont diffusées aux utilisateurs cibles. When a feature is being released to the wikis through publicly documented deployment waves, communities can influence the best timing for the deployment of a product or major feature in individual wikis:

• Les communautés satisfaites d'un nouveau produit ou d'une fonctionnalité peuvent demander à être incluses dans les premières vagues, après avoir montré leur intérêt dans leur canal de discussion communautaire.
• Les communautés ayant des préoccupations spécifiques ou suite à une discussion interne, peuvent demander que le déploiement de leurs wikis soit retardé à une vague ultérieure en suivant le processus décrit ci-dessous.
• Les équipes de développement programment les communautés qui n'ont pas de opinions particulièrement fortes.

Il se peut qu'une ou que quelques communautés continuent à repousser un nouveau produit ou une nouvelle fonctionnalité, alors que toutes les autres sont satisfaites. Les scénarios probables sont que soit le nouveau produit ou fonctionnalité continuera de se propager jusqu'à atteindre une couverture complète, soit les préoccupations de la communauté persuaderont finalement l'équipe de développement de changer les plans du produit.

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.

Certains déploiements de logiciels de même que la plupart des suppressions de logiciels, sont obligatoires. 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.

Configurations locales

Some local configurations can only be set server-side, usually by Foundation development teams. Dans certains cas, des configurations distinctes peuvent être créées pour les utilisateurs connectés et les utilisateurs anonymes. En général, les membres de la communauté du noyau peuvent bien représenter leurs propres intérêts, alors que les équipes du développement peuvent apporter des données et des analyses sur les utilisateurs et autres contributeurs.

Compte tenu de ces circonstances, les communautés doivent avoir la possibilité de discuter des configurations locales dans les termes suivants :

• Les communautés ont la priorité de définir la première configuration à être testée pour les caractéristiques qui affectent en priorité les contributeurs expérimentés.
• Les équipes de la Fondation Wikimedia ont la priorité de définir la première configuration à être testée pour les fonctionnalités qui affectent principalement les lecteurs et les nouveaux contributeurs.
• Les objectifs et les données recueillies doivent être inclus dans le plan de diffusion et les données collectées doivent être partagées (sauf si elles concernent la vie privée, ce qui devrait être expliqué dans le plan).
• If an initial configuration is not producing the expected results, the development teams can test alternatives before they settle on a stable configuration.
• Ultimately, the responsibility for defining product configurations belongs to the Wikimedia Foundation.

Merci à vous

Le temps des bénévoles est une ressource rare et précieuse. Merci aux personnes pour leurs commentaires constructifs, même si vous ne partagez pas leur avis. Si un bénévole contribue de manière significative à votre projet, assurez-vous de reconnaître sa contribution, tout comme vous reconnaîtrez une contribution similaire d'un collègue de travail qui a travaillé dans une autre équipe. L'équipe Language fait cela de manière cohérente en incluant des remerciements et en mettant en avant les contributions des bénévoles en gras dans son rapport mensuel (exemple).