Format des fiches

[hrenaud]

Les fiches de https://github.com/cnumr/best-practices/ ont ce format :

## Titre

### Identifiants

| GreenIT |  V2  |  V3  |  V4  |
|:-------:|:----:|:----:|:----:|
|      |   |   |      |

### Catégories

| Cycle de vie |  Tiers  |  Responsable  |
|:---------:|:----:|:----:|
|  |  |  |

### Indications

| Degré de priorité |      Mise en oeuvre       |  Impact écologique    | 
|-------------------|:-------------------------:|:---------------------:|
|        |                  |                   | 

|Ressources Economisées                                      |
|:----------------------------------------------------------:|
|Processeur / Mémoire vive / Stockage / Réseau / Requêtes    |

### Description

...

### Exemple

(facultatif) ...

### Solution alternative

(facultatif) ...

### Principe de validation

| Le nombre ... |     est inférieur ou égal à   |  
|-------------------|:-------------------------:|
| de ...    |  ... |

Les nôtres ont ce format :

---
title: <NUM de la fiche>. <NOM de la fiche>
people: <Noms des particpants>
family: <Famille de la fiche>
state_validation: <Status le création de la fiche>
targeted_people: <Liste des cible(s) visé(s), Personnas concernée(s)>
design_phase: <Phase de "conception" concernée>
complexity_implementation: <Niveau de difficulté de mise en œuvre>
priority_implementation: <Priorité de mise en œuvre>
environmental_impact: <Niveau de l'impact écologique>
saved_resources: <liste des ressources économisées>
---

# Titre

## Description

...

## Exemple

...

## Principe de validation

| Le nombre ...                                                                                           | est inférieur ou égal à |
| ------------------------------------------------------------------------------------------------------- | :---------------------: |
| de ... |           ...           |

La partie initiale de nos fiches utilisent des metadatas au standard frontmatter, cela permettra facilement de les utiliser, en l'état, pour faire un site en ligne et l'affichage est optimisé par GitHub, puisqu'il utilise lui aussi ce standard.
Ceci est redondant avec la première partie du template venant des fiches de CNUMR, que j'ai ajouté pour vous montrer comment était faites.

La discussion porte donc sur :

1. Quel format garde-t-on ?
   a. Frontmatter
   b. CNUMR
2. Gardons nous les deux ?

[Christophe-Cl]

Selon moi, les fiches WP différent du format CNUMR, qui lui est en lien avec les 115 BP en version 4, concernant :

• les Identifiants, il n'y a pas d'antériorité de versioning sur ce projet
• les Catégories, évidemment différentes pour ce projet (du moins aujourd'hui)
• les Principes de validation, qui porte souvent sur des seuils ou des valeurs dans les 115 BP v4.

J'apprécie beaucoup les critères Indications qui aident à bien comprendre et de façon pédagogique les BP. Cette idée pourrait être ajoutée et réfléchie consensuellement aux fiches WP.

[hrenaud]

@Christophe-Cl Les indactions sont reprises par ces médatas je pense :

• design_phase: <Phase de "conception" concernée>
• complexity_implementation: <Niveau de difficulté de mise en œuvre>
• priority_implementation: <Priorité de mise en œuvre>
• environmental_impact: <Niveau de l'impact écologique>
• saved_resources: <liste des ressources économisées>

[hrenaud]

tu en penses quoi @dNicolle ?

[dNicolle]

Effectivement certains attributs sont redondants.
Je trouve plus facile à lire la version CNUMR (plus aérées)
Le tableau généré en mode page est long et indigèste je trouve.
Il faut de toute façon ajouter les personnas concernés.
(je ne suis pas sure de vous aider là :))

[hrenaud]

Moi je vois l'utilisation des fiches pour plus tard pour créer un site, ce n'est peut-être pas pertinent à ce stade, ça demandera de retravailler ce point plus tard si l'on va dans cette direction.
Côté lisibilité du tableau horizontal, je n'ai pas d'avis, j'ai l'habitude maintenant 🤷‍♂️ a contrario, je trouve peu lisible ceux en place dans les fiches CNUMR, les tableaux markdown/GitHub sont relativement moche...

En faisant abstraction de ces points et du temps que j'ai passé à le faire, il est pertinent d'utiliser le format CNUMR, pour être cohérent.

Nous avons la notion des personnas qui peut passer dans la case Responsable, non ?

Ce serait bien que tout le monde donne son avis afin de statuer rapidement.
@Christophe-Cl @florinesueur @dNicolle @iosancti

Donc moi je vote, à contre-cœur, pour aller vers le format CNUMR

[Christophe-Cl]

Peu importe le markdone, comme exprimé plus haut, selon moi le format structurel des BP CNUMR est différent de celui actuel des fiches WP. Je propose une version adaptée (ce qui m'évite de voter à contre cœur :)) ) :

• sans Identifiants
• avec Catégories différentes
  Je retiens l'idée de @dNicolle sur les personas à ajouter aux fiches WP, cela pourrait remplacer les "Catégories" des BP CNUMR, ou s'y ajouter si on adapte les Catégories BP CNUMR.

[florinesueur]

Si nous avons vocation à nous adresser aussi bien à un professionnel qu'à un non professionnel, il me semblait que le repos github avait pour vocation d'être généré en site statique pour plus d'accessibilité. Si c'est le cas, Frontmatter.

Aussi si la publication est envisgée, il me semble que garder la mise en page des 115BP est un élément qui sera potentiellement voulu par l'éditeur seulement pour l'impression, donc pas forcément nécessaire sur le repo.

Du coup, je récapitule pour m'y retrouver dans les données :)

title: .
targeted_people: <Liste des cible(s) visé(s), Personnas concernée(s)> ==> Responsable, mot que je trouve plus impactant.
design_phase: <Phase de "conception" concernée> ==> Cycle de vie
complexity_implementation: <Niveau de difficulté de mise en œuvre> ==> Mise en Oeuvre
priority_implementation: <Priorité de mise en œuvre> ==> Degré de priorité
environmental_impact: <Niveau de l'impact écologique> ==> Impact écologique
saved_resources: <liste des ressources économisées> ==> Ressources économisée

Il manque juste le tiers : Datacenter ou réseau ou utilisateur/terminal.
Aussi, est ce que pour la difficulté, la priorité et l'impact faut-il se baser sur le calcul des 115BP ? Nous sommes passés d'une évaluation sur 3 à 5.

[dNicolle]

Je rejoins Florine sur l'envie (et la nécéssité) d'en fait un "site" accessible au plus grand nombre : c'est la finalité la plus plausible.
L'edition pourrait ne jamais voir le jour, alors que le site oui.

Désolé @hrenaud pour le temps que tu y as passé, mais je penche pour le format Frontmatter qui sera le plus pérenne de ce point de vue.

@florinesueur Dans ta phrase "Il manque juste le tiers : Datacenter ou réseau ou utilisateur/terminal.", c'est à ajouté dans "saved_ressouces"?
Aussi, je pense pertinent de passer d'une évaliation de 3 à 5.

Je me pose la question de la différence entre nos "familly" et les "catégories" de CNUMR.
Est-ce que les catégories de CNUMR (appuyé sur une norme) sont assez compréhensibles de nos "familles" non tech ?

[hrenaud]

hahaha, ne soit pas désolé @dNicolle , je suis pour utiliser Frontmatter, car je pousse vers la finalité d'une publication en ligne en conservant une source au format Markdown.

Pour moi, si l'on part sur Frontmatter, il y a deux points sur lesquels nous devons statuer :

• Doit-on maintenir deux affichages de ces metasdatas/référentiels, sachant que sur la version site, ces metas peuvent être affichées de multiples manières. Donc, la question se pose uniquement pour l'affichage "temporaire" dans GitHub.
  • Si l'on maintient ces deux manières d'afficher, sans oublier la page de liste, il faudrait en conséquence les saisir et les actualiser 3 fois (liste, Frontmatter et petits tableaux), c'est bcp et sources d'erreurs, je pense.
  • Si l'on se borne à Frontmatter, il faut alors accepter d'avoir cet affichage d'un tableau avec scroll horizontal dans les fiches.
• Si les noms des metadatas ne vous convient pas, de même que leurs valeurs, mettons-nous d'accord rapidement et changeons/je changerai partout (le "masterise" le chercher/remplacer 😉 ).

Inévitablement, il va falloir changer un point. J'ai mis All lorsqu'une fiche concerne tous les personnas, ça ne me parait pas pertinent, il faut mettre toutes les personnas au format array + lien vers la personna.

Je peux regarder pour faire vite fait un site pour afficher nos fiches et l'héberger dans les pages de ce repo.

[dNicolle]

ok pour moi de ne pas dupliquer les informations à l'interieur de la fiche.
Si tu as du temps pour tester, ça serait chouette de pouvoir visualiser ça oui.

[florinesueur]

+1 pour ne pas faire de doublon
+1 pour array personna avec lien

[florinesueur]

Pour moi, saved_ressource est la ressource préservée genre le CPU, le réseau ... qui est plus à mon sens matériel. Les tiers ce sont plutôt chez qui se retrouve le plus gros impact.

Je trouve les familles intéressantes pour se retrouver plus facilement en ajoutant un filtre au site cependant, le mot famille ne me convient pas trop. Je propose plutôt périmètre (scope) ou d'une façon générale catégorie.

Au sujet, des autres dénominations :

• Au lieu de personna concerné, je trouve plus impactant responsable ou maître d'oeuvre (peut-être un peu trop)
• design_phase, donc phase de conception ne convient pas avec le cycle de vie, car il y a maintenance et la fin de vie. Je resterais sur cycle de vie.

Pour le site, est ce qu'on utilise Jekyll ?

[hrenaud]

Bon, je récap avant de faire :

Les metas Frontmatter deviennent (ou ne change pas)

• title: . ne change pas.
• people: ne change pas.
• family: <Famille/Catégorie de la fiche> devient scope.
• state_validation: <Status le création de la fiche> ne change pas.
• targeted_people: <Liste des cible(s) visé(s), Personnas concernée(s)> devient responsible (et ce sera une liste).
• design_phase: <Phase de "conception" concernée> devient lifecycle.
• complexity_implementation: <Niveau de difficulté de mise en œuvre> ne change pas.
• priority_implementation: <Priorité de mise en œuvre> ne change pas.
• environmental_impact: <Niveau de l'impact écologique> ne change pas.
• saved_resources: <liste des ressources économisées> ne change pas.

Les valeurs de complexity_implementation

Passent de 3 à 5 (il va falloir re travailler les émojis).

Perso, je trouve que ça rajoute de la complexité et perds en cohérence alors que le reste est sur notation de 3.

Mais, le vrai souci de cette notation (c'était déjà le cas avec une note de 3), c'est qu'elle va être très compliquée à affecter chez nous, car nous avons de personna hétérogène. Changer une valeur dans le fichier wp-config.php est d'une complexité null pour un dev, alors qu'elle peut être quasi-impossible pour Mme/Monsieur tout le monde (Créer un compte FTP/SFTP, utiliser un logiciel FTP, éditer...).

C'est un point qui m'a souvent été remonté et c'est d'ailleurs pour ça que nous avons initié ces personnas, les fiches sont trop ciblées et rédigées par et pour des devs.

Création d'un site

Je ne connais pas Jekill, je pensais partir en Gatsby que j'ai l'habitude d'utiliser.

Je créerai bientôt une branche pour travailler ce point sans vous embêter immédiatement avec le code spécifique au site.

Liens interne.

Il y a des liens cassés, regardez vos fiches pour les corriger. Utilisez les liens relatifs plutôt qu'absolus.

[dNicolle]

L'idée du niveau de technicité est interessante.

@hrenaud dans responsible (sera une liste), cela veut dire qu'ils peuvent être multiple ?

[hrenaud]

responsible pourra être une liste en effet. Tous peuvent être un array, j'ai prévu le code pour cela, même si le code n'est pas le moteur de choix, il devra s'adapter à nos choix de "définitions" de fiches.

La complexity_implementation est un des métas venant des 115 ( dans les versions précédentes et encore présent dans la V4), donc peut-on le supprimer ?

Si l'on veut partir dans une complexity_implementation corrélée à la notion de responsible, il faudrait faire une matrice.

• responsible : no-code / complexity : ∞
• responsible : dev / complexity : 1

C'est pertinent et précis, mais est-ce lisible ?

Pour le moment, le code ne permet pas de faire cela... Et est-ce qu'une version papier le pourrait ?

---

Donc pour revenir à la proposition de @florinesueur , on peut supprimer la complexité et mettre un 'how-to' adapté au responsible, mais je vais prendre un cas précis, faire des vignettes d'images qui est à réaliser par tout le monde.

• En tant que dev, j'ai un bout de code à ajouter et à adapter dans un fichier ;
• En tant que (tout le reste), il existe des plugins.

Effet de bords de cette deuxième méthode

• On doit lister des plugins (il faudra maintenir cette liste) ;
• Le plugin répond au besoin, mais peut embarquer plusieurs fonctionnalités non désirées. Ça alourdi le code du site et ça va un peu à l'encontre de ce que l'on indique ailleurs...

Bref, je ne sais pas résoudre ce point. Je vais donc m'arrêter sur les arguments qui ne font pas avancer et vous laisser prendre une décision :)

[florinesueur]

Hello @hrenaud,

Je comprends tout à fait.

1. Bonne pratique (ou solution code) : J'ai un bout de code à ajouter et à adapter dans un fichier. Peut-être un tuto me permettra de le faire sans pour autant être dev.
2. Alternative (ou solution no code) : plugins en indiquant les effets de bord pour ceux qui ne se sentent pas de toucher aux codes

Donc en effet, ma proposition n'est pas pertinente.

Je ne sais pas si nous pouvons enlever complexity_implementation par rapport aux 115BP. Elle est vu comme le niveau d'expertise nécessaire (responsible) et/ou les effets de bord ou la nécessité de refondre le projet (impact sur le projet). De mémoire, on avait indiqué les métriques dans un tableau et le résultat est la moyenne des différentes participants sachant qu'il y avait essentiellement que des devs.

Au niveau de la matrice, en print, le plus simple reste un tableau cependant ce n'est pas forcément lisible et assez lourd pour chaque BP.

[dNicolle]

Il semble qu'il soit compliqué de garder le complexity_implementation.
Peut-on imaginer que responsible remplace complexity_implementation ?
Cela premettrait de résoudre deux inconnues :

• la place dans le livre
• indicateur de complexité par le personnas

Dites moi si on valide cette proposition pour récapituler le tout et passer à la suite.

Bonne soirée.
Dominique

[hrenaud]

Je pense que l'on n'a pas réellement d'alternative, en effet, donc ok pour moi de supprimer la notion de complexité.

[hrenaud]

Un avant-gout du rendu https://cnumr-wordpress-best-practices.netlify.app/fiches/28.%20Type%20d'images%20%C3%A0%20utiliser%20suivant%20le%20contexte%20d'utilisation/

Je ne peux pas activer les pages github de ce repo puisqu'il est private, donc pour le moment, il est ailleurs...

J'ai un problème avec les images, je n'arrive pas à les afficher 🤷‍♂️

[hrenaud]

Problème d'images fixé.

[dNicolle]

c'est pas mal du tout ;)

[hrenaud]

Hello,

Je vais mettre en stand-by là la création du site en attendant que l'on se mette d'accord sur les metas données des fiches.

Le site est fonctionnel et répond au besoin (je pense)

• Affichage des fiches et personnas en utilisant les documents en .md que nous éditons dans Github.
• La navigation présente dans le header permet d'aller consulter les fiches, les personnas et de faire une recherche par mot clé sur celles-ci. Un lien vers ce Github devra être ajouté.
• Le site est responsive, statique et allégé, réalisé sous Gatsbyjs.
• Le Seo est alimenté et utilise les données des fiches. Sur les pages de liste, home ou de recherche, il est activé, mais surement améliorable. Il manque néanmoins une image pour les partages RS, mais ce n'est pas bien grave à ce stade.
• Chaque page (fiche ou personnas) utilisent les metas de frontmatter et les affiches de manière lisible. Une navigation interne permet d'aller consulter les chapitres de manière rapide.
• Le problème d'image est résolu. J'ai modifié le template qui explique comment rédiger une fiche et l'arborescence des dossiers pour faire cela.
• Dans la page de liste des fiches, j'ai ajouté un filtre sur la famille. Il peut aussi être ajouté à la home.
• La recherche est réalisée sans service externe en utilisant un index local.
• Le style actuellement appliqué est très simple et peut-être améliore suite à vos retours.

J'ai adapté pour pour mes tests que mes fiches (je sais, c'est pas sympa), les autres n'ont pas les métas complètes, d'où des familles manquandes et des données valorisées à TBD

• Mise en place des metas frontmatter conforme à nos premiers échanges (mise en place des arrays)
• J'ai supprimé le titre de la fiche (avec un #) car redondant avec celui des metas
• J'ai ajouté une metas path pour bien encadrer la création des fiches dans leurs sous-dossiers (fiches ou personnas), ça je l'ai fait partout, car mandatory.

Pour le moment, tout est fait dans une branch de ce Github site-static-v2 quand je vais la merger dans la branche principale main tous les fichiers Gatsby seront ajoutés et il faudra fusionner les fiches si vous les avez faites évoluées. Ce merge sera fait une fois les metas définies et stables.

Remarque :
Regardez bien comment sont structurées les fiches et le markdown pour être cohérents avec les autres.

Bon dimanche

Renaud

[dNicolle]

super boulot, merci.

[hrenaud]

@florinesueur @dNicolle @Christophe-Cl @iosancti

hello, est-ce qu'on valide définitivment ces metadonnées :

• title: 28. Type d'images à utiliser suivant le contexte d'utilisation
• people: Renaud H.
• scope: Images
• state_validation: DONE
• responsible:
  • Code(use·ur) → Développeu·se·r
  • Designeu(se·r)
  • Low-code → Freelance et développeur Front-End d'agences
  • No-code → Madame et Monsieur tout le monde
• lifecycle:
  • 2 - Conception / Design
  • 3 - Développement
• priority_implementation: Fort 👍👍👍
• environmental_impact: Fort 🌱🌱🌱
• saved_resources:
  • Processeur
  • Mémoire vive
  • Stockage
  • Réseau
• path: /fiches/28. Type d'images à utiliser suivant le contexte d'utilisation

Et pour ne pas faire doublon, on supprime et conserve que ces niveaux de titre dans la page

• h2 : ## Sujet
• h2 : ## GreenIT vous conseille
• h2 : ## Exemple
• h2 : ## Principe de validation
• h2 : ## Source

Le H1 étant le title des métas, il n'est plus nécessaire.

[hrenaud]

Merci de voter via les smileys ou en mettant un commentaire :)

[dNicolle]

@hrenaud j'ai fait un PR : 6f3405b
Tu pourras merge si ça correspond bien au récap ci-dessus ?

[dNicolle]

Si c'est ok, je repasserais dans mes autres fiches pour les remettres au format