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 (blocker) 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. Les communautés sont invitées à soumettre les rapports de bogue ainsi que les autres problèmes qu'elles auraient rencontrés, de sorte à ce que l'équipe de développement puisse déterminer si ces problèmes doivent impacter le planning du développement. 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 bloqueur 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.
- soyez objectif, par exemple dites « Cela ne fonctionne pas sur cet équipement » ou « Ce produit ne prend pas en charge les fonctions de masquage » plutôt que d'annoncer « Je ne l'aime pas du tout » ou « Ce produit, c'est de l'argent jeté par les fenêtres ».
- utilisez des arguments constructifs, fournissez les données, des possibilités d'actions, et adoptez un ton collégial.
- fournissez une preuve du consensus communautaire si vous parlez au nom d'une communauté.
- tenez compte des discussions et des accords antérieurs. Il faut de bonnes raisons pour réouvrir un sujet entériné.
Les mêmes critères de qualité sont attendus des développeurs ou des autres contributeurs qui ne sont pas d'accord avec ces bloqueurs proposés.
La décision finale ultime quant à savoir si chaque bloqueur proposé doit effectivement stopper le développement (ou le déploiement) appartient à l'équipe de développement, et non aux communautés.
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. Lorsqu'une fonctionnalité va être diffusée sur les wikis par le biais de vagues de déploiement publiquement documentées, les communautés peuvent influencer le meilleur moment pour le déploiement d'un produit ou d'une fonction principale sur les wikis individuels :
- 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.
Afin de retarder le déploiement d'un nouveau produit ou d'une fonctionnalité dans un wiki individuel, la communauté locale doit fournir un lien vers une discussion communautaire et la liste des bogues à corriger, des fonctionnalités manquantes ou d'autres problèmes qu'elle souhaite que l'équipe de développement prenne en compte pour le statut blocker. (Idéalement tous les bloqueurs proposés sont des tâches créées dans Phabricator).
Les équipes de développement participent à la discussion sur les éléments bloquants proposés pour déterminer s'ils sont raisonnables, cohérents avec le projet, réalisables, réalistes, etc. Si l'équipe de développement décide qu'aucun des bloqueurs proposés ne peut retarder le déploiement, le déploiement se fera. Si l'équipe de développement décide que certains (ou tous) les bloqueurs proposés doivent retarder le déploiement, et s'attaque ensuite à ces propositions, la communauté sera invitée à un nouveau réexamen. S'il n'y a pas de surprise, le déploiement se poursuivra.
Certains déploiements de logiciels de même que la plupart des suppressions de logiciels, sont obligatoires. Certains déploiements, comme l'offre d'une nouvelle API, ne peuvent pas être gérés par vagues successives de déploiement au fil du temps (au lieu de cela, ces déploiements on lieu simultanément partout). Dans ces cas, les communautés locales ne pourront pas influencer le calendrier.
Configurations locales
Certaines configurations locales ne peuvent être configurées que du côté du serveur, généralement par les équipes de développement de la Fondation. 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).
- Si une configuration initiale ne produit pas les résultats attendus, les équipes de développement peuvent tester des alternatives avant de choisir une configuration stable.
- A la fin, la responsabilité de définir les configurations des produits appartient à la Fondation Wikimedia.
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).