Introduction: ce texte, traitant des problèmes surgissant à propos du logiciel, de l´éditeur ID, et la recherche de solutions, ainsi qu´une demande de commentaires, est une traduction de l´original en anglais édité par le président du conseil d’administration de Open Street Map Foundation.
Le conseil d’administration de la Fondation OpenStreetMap cherche à résoudre les controverses qui ont périodiquement surgi autour des mises à jour et des améliorations de l’éditeur iD. On s’attend à ce que cette demande de commentaires mène à l’adoption de structures communautaires qui ne répondront pas nécessairement au opinions des membres du conseil d’administration. Elles ne seront pas influencées par le conseil d’administration, conformément à la philosophie de l’OSM selon laquelle le conseil d’administration soutient l’OSM mais ne dit à personne quoi cartographier ou comment cartographier. . Nous demandons que des commentaires soient faits sur la liste de diffusion OSM-talk (inscrivez-vous à OSM-talk) ou -si vous êtes membre de l’OSMF- à la discussion de la liste de diffusion OSMF-talk (inscrivez-vous sur OSMF-talk).
Offres et recommandations de l’OSMF pour la gouvernance des iD.
ID est l’éditeur Web par défaut, simple et convivial d’OpenStreetMap, un logiciel central pour le projet. Il y a beaucoup de passion pour son développement, et cela semble parfois devenir un problème.
Le conseil d’administration de l’OSMF a récemment convoqué une petite réunion pour discuter des moyens d’améliorer l’environnement de développement pour iD. S’il y a certainement eu des moments où des décisions majeures et mineures en matière de ID ont déclenché un conflit, la grande majorité des discussions sur le développement sont au contraire non polarisantes et productives. La réunion s’est concentrée sur les domaines clés où des problèmes surgissent (le plus souvent, mais pas seulement, le balisage, étiquetage, marquere), et les moyens de permettre qu´un désaccord trouve une résolution constructifs, sans qu’ils ne se détériorent en conflits qui nuisent au projet.
Essentiellement, les mainteneurs d’ID ont besoin d’un espace productive pour effectuer leur travail; les contributeurs, les utilisateurs et toutes autres parties intéressées doivent être entendus; le processus décisionnel doit être compris et respecté; et les différends ont besoin d’un moyen de s’intensifier la discussion mais à la fin d´aboutir à une solution équitable.
Il n’y a pas de solution technique à ce genre de situation. Ce qu’il faut, ce sont des procédures et organisation. À cette fin, vous trouverez ci-dessous plusieurs offres et recommandations du conseil de l’OSMF que le projet ID pourrait envisager de soutenir et d’adopter. Nous espérons que le projet ID trouvera ces suggestions utiles et attend avec intérêt de discuter de ce qui semble réalisable et de ce qui ne fonctionne pas.
L’OSMF établira une procédure d’appel.
L’OSMF envisage sérieusement de créer ou d’indiquer un organisme pour statuer sur différents types de litiges technologiques, capable de s’appuyer sur une expertise ad hoc pour déterminer la meilleure voie à suivre pour la communauté. Les projets logiciels pourraient accepter d’utiliser ce processus d’appel; ce ne serait pas nécessaire. Ce processus d’appel peut simplement impliquer l’arbitrage du désaccord entre les différentes parties ou projets et aider à trouver un accord entre elles; ou pourrait impliquer de prendre ou d’annuler des décisions. Ce mécanisme est en cours de discussion, mais reste à définir.
Si les décisions contestées ne peuvent pas être résolues directement dans le projet ID par ses responsables et parties prenantes, le problème peut être renvoyé à ce processus d’appel.
Le rôle de ce groupe ne serait certainement pas de forcer les développeurs à ajouter certaines fonctionnalités. Cependant, si les problèmes sont transmis au groupe, il pourrait vérifier que les fonctionnalités nouvellement ajoutées (par exemple, les préréglages, les règles de validation ou l’inclusion de services externes) sont conformes à une vue consensuelle.
Si cela semble potentiellement utile à ce stade, l’OSMF demande à ID de partager les commentaires et les attentes pour rendre le processus plus efficace.
OSMF soutiendra le développement de meilleurs systèmes pour les décisions de marquage; ID documente le statu quo et la séparation des préoccupations.
Abréviation technique:
- PR : ” proposition de révision” , demande de révision de code de programmation.
La seule façon d’évaluer les «bonnes» balises est une “évaluation baroque” des différentes sources de documentation OSM – le wiki, la liste de diffusion des balises, info des balisages. Cela laisse les outils d’édition et de consommation en mesure de «décider» des balises appropriées ou non pour OpenStreetMap. Lorsque cela devient litigieux, au mieux, c’est une distraction importune; et au pire, le développement peut être bloqué. À cette fin, l’OSMF se félicite du développement d’une meilleure documentation, d’une prise de décision et d’un processus de conservation des étiquettes. Le cas échéant, l’OSMF est prêt à soutenir ces efforts avec des infrastructures et d’autres soutiens. Cela fournirait un plus grand degré de clarté aux développeurs d’outils. Si une action prise sur des préréglages dans ID est contestée, le problème pourrait être renvoyé au processus d’appel décrit ci-dessus.
Pour sa part, alors que les travaux sur les systèmes de marquage sont en cours, nous recommandons maintenant d’ajouter des détails sur l’approche du statu quo qu’ID adopte pour les décisions de marquage dans CONTRIBUTING.md. Il est clair que ID aspire à s’abstenir de prendre des décisions sur les balises appropriées pour OpenStreetMap; iD vise plutôt à représenter l’opinion consensuelle sur les balises dans les préréglages. Le «consensus» est actuellement subjectif, et le projet ID soutient fortement (nous pensons, s’il vous plaît, dites-le sinon) les efforts d’OSM pour clarifier la façon dont les balises sont développées.
Des préréglages peuvent être demandés dans les numéros et dans les PRs, ainsi qu’une discussion dans le numéro / PR. Le responsable de ID se réserve le droit d’inclure ou d’exclure certaines balises / préréglages pour des raisons techniques ou d’utilisation, bien que l’objectif soit d’éviter de conserver les balises et de prendre des décisions sur le bien-fondé des balises en général. S’il semble y avoir un consensus, basé sur l’évaluation de la documentation source, et s’il répond à un besoin pour d’autres utilisateurs, les préréglages, les préconfigurations seront acceptés. S’il n’y a pas de consensus clair, le préréglage (ou la règle de validation, etc.) ne sera pas accepté.
Organisation de réunions de planification trimestrielles et publier une synchronisation et des notes bihebdomadaires.
L‘OSMF recommande à ID de tenir une réunion vidéo trimestrielle (ou presque) avec les parties prenantes d’ID. Cette réunion est l’occasion de sortir du travail quotidien d’ID et de s’assurer que le travail est sur la bonne voie. L’ordre du jour évaluerait le développement au cours du dernier trimestre, discuterait des exigences et des besoins prioritaires et ferait des plans pour le prochain trimestre et au-delà. De plus, si des décisions ou des sujets se sont révélés difficiles ou contestés au cours du dernier trimestre, c’est le moment de discuter directement. Des notes seront prises et distribuées.
De plus, ID publie une synchronisation bihebdomadaire, mais ceci n’est pas bien connue. ID pourrait faire connaître la synchronisation bihebdomadaire en l’annonçant sur des canaux supplémentaires, y compris https://ideditor.blog/; et s´assurer que les notes de la synchronisation sont visibles et accessibles.
iD peut améliorer la clarté de la prise de décision et de la communication
Nous recommandons que dans CONTRIBUTING.md les mainteneurs d´ID ajoutent une nouvelle section qui explique comment les décisions sont prises dans ID. Certains points soulevés ici dépendent de l’adoption, d’autres de recommandations. La nouvelle section expliquerait ce qui suit.
- Il existe de nombreux endroits pour discuter et apporter des contributions sur le développement d´ ID – les problèmes et les relations publiques GitHub, les synchronisations mensuelles, la réunion de planification trimestrielle et en réponse aux annonces sur https://ideditor.blog/.
- Les développeurs d’ID se sont engagés à être réactifs et transparents. Par défaut, les responsables d ´ID déterminent la séquence et le calendrier des correctifs, des modifications et des améliorations afin d’optimiser le travail technique.
- Invitez les parties prenantes à participer à un processus de «test d’acceptation», dans lequel la rétroaction sur les versions est sollicitée et gérée pendant une période de temps limitée.
- La décision ultime d’accepter les PR est prise par le responsable d’iD, Quincy Morgan.
- S’il y a un différend sur une décision, il sera renvoyé à la réunion de planification trimestrielle et / ou à un processus d’appel géré au sein de la Fondation OSM.
De plus, nous recommandons à ID de publier une feuille de route et de mettre à jour régulièrement l’état des principales versions d’iD. Les plans iD3 ont été partagés pour la dernière fois au SotM US (État de la carte EU). L’approche a changé, avec une plus grande concentration sur l’interface utilisateur mise à jour et des efforts plus itératifs sur la mise en composants. Il serait bon d’avoir une idée claire de l’endroit où les choses se trouvent, et où elles vont (autant que c’est clair maintenant), et surtout où l’aide est nécessaire afin de donner une impulsion à cet effort important.
Documenter la façon dont le code de conduite est géré
ID a un code de conduite, mais il manque de détails sur la façon de signaler un incident nuisible dans l’environnement de développement ID, et comment ces rapports sont jugés. Auparavant, les plaintes relatives au code de conduite étaient traitées ouvertement en ouvrant un problème sur GitHub, mais les responsables ont ensuite dirigé les personnes vers le comité OSMUS privé. La clarté du processus est tout aussi importante, sinon plus, pour qu’un CdC soit utile au projet. Si ce processus n’est pas bien défini, une réflexion s’impose, peut-être au cours de la réunion de planification trimestrielle. Notre recommandation est d’ajouter une section sur le processus de changement de code de conduite.
Allan Mustard
Président des directeur de OSMF
La Fondation OpenStreetMap est une organisation à but non lucratif, formée au Royaume-Uni, pour soutenir le projet OpenStreetMap. Il est dédié à encourager la croissance, le développement et la distribution de données géospatiales gratuites pour que quiconque puisse les utiliser et les partager. La Fondation OpenStreetMap possède et maintient l’infrastructure du projet OpenStreetMap et vous pouvez le soutenir en devenant membre. Le comité d’organisation de l’état de la carte est l’un de nos groupes de travail bénévoles.
OpenStreetMap a été fondé en 2004 et est un projet international pour créer une carte-monde gratuite. Pour ce faire, nous, des milliers de bénévoles, collectons des données sur les routes, les voies ferrées, les rivières, les forêts, les bâtiments et bien plus dans le monde. Nos données cartographiques peuvent être téléchargées gratuitement par tout le monde et utilisées à toutes fins – y compris à des fins commerciales. Il est possible de produire vos propres cartes qui mettent en évidence certaines fonctionnalités, de calculer des itinéraires, etc. OpenStreetMap est de plus en plus utilisé lorsque l’on a besoin de cartes qui peuvent être mises à jour très rapidement ou facilement.
Ce document est disponible en anglais, néerlandais, polonais
Les couches dont nous disposons actuellement le sont :
