Le point soulevé n'était pas sur le projet du mois, mais sur la
nécessité d'une communication *bienveillante*.
Même si les intentions sont bonnes (c'est souvent le cas), les *demandes
expéditives sont usantes* : une personne bénévole n'est pas un robot
sans âme soumis à bons de commandes. De la même manière qu'on ne peut
pas attendre d'OSM une qualité irréprochable des données sur l'ensemble
de la planète, on ne peut pas attendre une garantie de service 100% ou
une actualisation des briques logicielles en sprints agiles toutes les 4
semaines. On souhaite tous faire avancer le bien commun, faisons-le dans
une ambiance bienveillante et accueillante. À quoi ça sert de défendre
un modèle d'ouverture sur les logiciels et données si c'est pour
communiquer comme le N+1 d'une multinationale qui n'a aucun respect pour
son équipe.
Une communication bienveillante ne veut pas dire qu'on ne peut pas
améliorer la disponibilité ou la rapidité de mise à jour des logiciels,
mais dans ce cas il faut :
- Soit *mettre la main à la pâte* (on n'est jamais mieux servi que par
soi-même) et travailler à plusieurs sur les outils critiques (assurer
une continuité de maintenance)
- Soit trouver un *budget* (donc émettre un _vrai_ bon de commande) pour
que les personnes qui maintiennent actuellement les services y
consacrent du temps salarié.
Et si on a ni le temps ni l'argent, *revoir ses priorités* ou comprendre
qu'une personne bénévole ait des priorités différentes (travail,
famille, besoin de s'aérer...). Même si c'est dommage que tel service
soit indisponible, ça arrive, c'est la vie. On est tous bénévoles dans
ce projet, n'infligeons pas à autrui ce que l'on n'aimerait pas qu'on
nous fasse. Le sujet de l'accueil des nouveaux est récurrent, n'oublions
pas que si la communauté doit se renouveler, c'est aussi à cause de*la
fatigue des personnes présentes de longue date*. Alors évitons de leur
rajouter une couche de fatigue inutile.
Quand je remonte un problème, soit j'ai la capacité d'aider donc j'aide,
soit je n'ai pas la capacité et dans ce cas le problème est remonté en
mode "*bouteille à la mer*". Un guide de bonnes pratiques :
- Commencer par du *positif* : merci pour cet outil/base/... qui est
d'un grand service. Les français sont les champions du monde pour râler,
mais très peu iront vous remercier d'un service utile.
- *Détailler* le problème : je rencontre tel problème, dans tel contexte
technique, à telle adresse... Plus la demande est détaillée, plus le
problème sera simple à identifier
- *Proposer* une ou des solutions si on peut les envisager, ne pas
hésiter à illustrer avec maquettes, captures d'écran...
- Et enfin *remercier* pour le temps qui pourra être consacré à cette
demande, tout en n'attendant pas une réponse immédiate ni une résolution
rapide.
Du point de vue extérieur, ça semble idiot de faire des ronds de jambe.
Pourtant à l'usage ça réduit largement la charge mentale des personnes
qui maintiennent ces services. Chacun a suffisamment de stress dans sa
vie pour ne pas vouloir s'en rajouter avec des projets bénévoles. Donc
évitons de *dégoûter* à tout jamais les personnes suffisamment motivées
pour consacrer du temps au bien commun en communiquant avec elles comme
à des sous-traitants pour lesquels on aurait aucun respect. C'était une
des tendances lors des présentations du Sotm monde en ligne : la vraie
valeur d'OSM n'est pas dans ses données, mais dans sa *communauté*.
En résumé, ne disons pas à Vincent "/BANO est mort, c'est con quand
même/", mais disons lui "/Merci pour avoir contribué toutes ces années à
BANO et merci pour ton engagement régulier. Si nous pouvons t'aider,
nous le ferons volontiers. Si nous ne pouvons pas, sache que ce service
nous est bien utile dans notre contribution, et que nous serons contents
de pouvoir le retrouver le moment venu./".
Cordialement,
Adrien P.
Le 28/08/2020 à 23:25, Philippe Verdy a écrit :
Allez, juste un peu de lecture pour finir sur des paroles sages et
bienveillantes :
https://github.com/vdct/ProjetDuMois/issues/22#issuecomment-678981742
Je ne vois pas le rapport: là tu reviens sur un autre projet du mois,
les DAE (qui n'ont pourtant aucun rendu sauf le rendu OSM.FR
<http://OSM.FR> qui n' pas la capacité de supporter l'usage voulu par
le grand public au sens large pour les DAE, et ne sont pas non plus
pour l'instant dans les priorité internationales d'OSM).
Il n'y a rien concernant BANO pourtant fondamental (même pour
faciliter l'intégration des DAE et de toutes sortes d'autres "projets
du mois").
Le projet BANO mérite un peu plus d'attention, et il s'est endormi sur
ses lauriers passés et n'évolue presque plus, alors que la BAN elle
continue bien plus vite.
Avec la conséquence directe: l'IGN recommence à prendre du poids pour
les usages via des licences privées (ou bien les solutions payantes
comme Mapbox et même Google), et le "switch 2 OSM" semble un peu oublié.
Les besoins de localisation d'adresses sont fondamentaux pour OSM, et
permanents, independamment des autrers sous-projets qui eux dépendent
énormement de l'intégration des voies (pratiquement fait et
opérationnel avec Nominatim qui pourtant continue de progresser pour
régler divers problèmes) et sinon les adresses.
A coté de ça le rendu OSM est un peu à la traine avec ses
tuiles bitmap couteuses à calculer, mal distribuées. La Fondation le
dit déjà, il faut passer au vectoriel le plus vite possible, même si
en attendant on doit maitnenir les tuiles bitmap fonctionnelles (et
pour cela il faut encore consacrer de grosses ressources de calcul qui
sont de plus en plus difficiles à maintenir et offrir au plus grand
nombre: problème d'échelonnabilité majeur d'OSM qui permet à Google,
Bing, Apple, Facebook et d'autres de continuer à avancer plus vite et
vendre leurs solutions propriétaires et décider ce qu'on a le droit de
trouver sur les cartes, et dont ensuite monter les prix une fois
qu'ils ont installé une dépendance à leurs services).
Bref c'est une question de gestion des priorités: plus les moyens sont
limités plus il faut établir ces priorités et s'y tenir (sauf décision
communautaire d'abandon quand les ressources ne peuvent plus suivre,
car là il faudra bien arbitrer et faire des choix cruels).
_______________________________________________
Talk-fr mailing list
[email protected]
https://lists.openstreetmap.org/listinfo/talk-fr
_______________________________________________
Talk-fr mailing list
[email protected]
https://lists.openstreetmap.org/listinfo/talk-fr
