15 liens privés
Beaucoup d'éléments intéressants dans cette démarche d'Elio Jaillet:
Cette réflexion a été pensée pour le contexte d’une retraite de conseil paroissial centrée autour de la constitution d’une responsabilité communautaire à l’égard des faits de violence, la prévention d’abus, les outils et les ressources possibles pour répondre communautairement aux faits de violence.
Sans surprise, elle résonne avec ce qui m'intéresse dans les communautés du web. À titre d'exemple, les codes de conduite:
- https://www.writethedocs.org/code-of-conduct/
- https://beyondtellerrand.com/code-of-conduct
- https://smashingconf.com/codeofconduct
- https://www.11ty.dev/docs/code-of-conduct/
On en français: https://www.paris-web.fr/code-de-conduite.php
Pour réfléchir aux codes de conduite: https://www.ashedryden.com/blog/codes-of-conduct-101-faq
Je continue mes recherches sur la documentation technique et je vois plein de parallèles possibles avec les institutions. Quelques notes formulées à ma sauce pour mémoire:
-
La documentation du code n'est pas suffisante. Ce n'est qu'une petite partie de ce qu'est la documentation. Elle ne dit pas pourquoi un logiciel change le monde, comment s'impliquer dans la communauté, quelles sont ses valeurs, etc.
-
Votre pire problème, c'est le «moi d'il y a 6 mois». Si je ne documente pas ce que je fais, je ne comprends même plus les choses quelques mois plus tard. Comment imaginer impliquer d'autres personnes, transmettre quelque chose, etc. si je ne m'y retrouve pas?
-
L'ingénieur (développeur) a de grandes connaissances, mais ne veut pas faire l'effort de les transmettre (à l'audience). Dans le modèle traditionnel, les personnes ne sont pas au même niveau et il faut des connecteurs.
-
Dans le monde open source, les développeurs sont souvent aussi l'audience. L'enjeu, ce sont les débutants, comment éviter le jargon, comment être inclusif, etc.?
-
Je le ferai plus tard signifie au fond: cela ne sera jamais fait!
-
Il y avait beaucoup d'utilisateurs (d'un logiciel), mais pas de communauté! Intéressante distinction. Qu'en faire en institution (ecclésiale): qui sont les utilisatrices et utilisateurs, qu'est-ce que la communauté?
-
Un ensemble de compétences au service de la clientèle. C'est la spécificité de Write the Docs dans le monde de la documentation technique. Faire des pauses durant les conférences, c'est aussi le moyen de faire se rencontrer toutes ces personnes.
Très grande richesse dans cette intervention de Lana Brindley. Elle dépasse amplement la question de la documentation et de l’architecture d’information.
Distinction intéressante entre lire et consulter.
Ou aussi, remarques sur:
- ce que l’on pense que les gens veulent
- ce que les gens nous disent qu’ils veulent
- ce que les gens veulent vraiment
As technical writers, we already know that choosing the right words is important, and we also know that the style and layout of our pages matters. The third leg of the stool is information architecture: getting the right content, in the right place, at the right time.
S'inspirer des notices de jeu pour rédiger des documentations de qualité. Bien envie d'en parler avec les gens d'Open Source Church ou Holygames.
Imagine writing guidance for a product that exists solely in the mind of the customer. That is the plight of the tabletop game designer. Yes, games come with boards and cards and dice and counters, but those are but the UI, so to speak. The essence of a tabletop game is the set of algorithms that govern play, as specified by the instructions. In that sense, a rulebook is both software and documentation, rolled into one.
Je continue mes recherches sur l'adaptation de outils et concepts de documentation technique à d'autres domaines (non techniques). Il y a souvent plein de bonnes idées.
L'outil phare de l'irremplaçable Daniele Procida!
The Diátaxis framework aims to solve the problem of structure in technical documentation. It adopts a systematic approach to understanding the needs of documentation users in their cycle of interaction with a product.
Je continue mes recherches sur l'adaptation de outils et concepts de documentation technique à d'autres domaines (non techniques). Il y a souvent plein de bonnes idées.
Ici, une excellente conférence de Daniele Procida.
Facing a project large enough not to be completable in one go, and that won't have much value until it's actually complete, we often feel we don't know how to begin. Complex projects lure us into creating frighteningly complex plans, that we draw all the way to our envisaged finish-lines. The next thing we know we are staring at a mountain of our own making.
Je continue mes recherches sur l'adaptation de outils et concepts de documentation technique à d'autres domaines (non techniques). Il y a souvent plein de bonnes idées.
Tom Johnson s'inspire des principes universels du design pour concevoir une navigation ;)
Although users typically arrive at doc websites in a confused and impatient state, not sure of where to find what they're looking for, good navigation can guide them to the right answer. Good navigation anticipates users' needs, provides links in commonly viewed places, and brings the right topic into the foreground amid hundreds of other topics.