Initialisation de la documentation de developpement.

Premiers jets de spécification.

about #24 @2h, #5 @45min

data/base-de-connaissances/contribuer/gerer/temps/synchrone/_resources/compte-rendu.md

@@ -0,0 +1,118 @@
+# [UN MARQUEUR 1] UN TITRE 1
+
+## Date & lieu
+
+* 📅 UNE DATE
+  * 🔗 UN LIEN DE SONDAGE
+* 🗺️ UN LIEU
+  * 🔗 UN LIEN DE CARTE OU D'OUTIL DE VISIO
+
+
+## Courte description
+
+UNE COURTE DESCRIPTION 1
+
+
+## Participant⋅es
+
+* ✅ UNE PARTICIPANTE 1
+* ✅ UN PARTICIPANT 2
+
+* 🚫 UN ABSENT 1
+
+
+### Animation / Scribe
+* 🗣️ UNE PARTICIPANTE 1
+* 📝 UN PARTICIPANT 2
+
+
+### Convié⋅es
+* 💺 UNE CONVIEE 1
+* 💺 UN CONVIE 2
+
+
+### Invité⋅es
+* 🤔 UNE INVITEE 1
+* 🤔 UN INVITE 2
+
+
+## Ordre Du Jour (ODJ)
+
+* 👋 Présentation / Tour de table | 🕑 0-10min
+* 📌 UN ODJ Obligatoire 1 | 🕑 UN TEMPS ESTIME 1
+* 🎈 UN ODJ Optionnel 1 | 🕑 UN TEMPS ESTIME 2
+* 👋 Conclusion / Tour de table | 🕑 0-10min
+
+
+## Description
+
+### Annonces
+
+* 📢 UNE ANNONCE 1
+* ⚠️ UNE PRECAUTION 1
+* 🚨 UNE ALERTE 1
+
+* ✅ UNE TACHE OU DECISION VALIDEE 1
+* 🚫 UNE TACHE OU DECISION ANNULEE 1
+
+* ⚖️ UNE DECISION A PRENDRE 1
+* ❓ UNE QUESTION 1
+* 📌 UNE TACHE A FAIRE 1
+* 🚧 UN CHANTIER EN COUR OU A ORGANISER 1
+
+* 🧳 UN DEPLACEMENT 1
+* 📅 UN RDV DE FIXE 1
+
+
+### Feuille de route | ~DATE PROCHAIN RDV
+
+### Tour de table 
+
+#### 👋 UNE PARTICIPANTE 1 
+
+UN TEXTE 1
+
+
+#### 👋 UN PARTICIPANT 2
+
+UN TEXTE 2
+
+
+### 📝 UN SUJET 1
+
+DES NOTES 1
+
+
+### 📝 UN ODJ Obligatoire 1
+
+DES NOTES 2
+
+
+### 📝UN ODJ Optionnel 1
+
+DES NOTES 3
+  
+
+### 📝 UN TRUC PAS PREVU 1
+
+DES NOTES 4
+
+  
+## FAQs
+
+### ❓ UNE QUESTION 1
+  
+UNE REPONSE 1
+
+
+## Versions
+
+### v0.0.2
+_date: 00 janvier 0000 | Auteurice2_
+* Travail 2
+* Travail 3
+
+### v0.0.1
+_date: 00 janvier 0000 | Auteurice1, Auteurice2_
+* Travail 1
+

data/base-de-connaissances/programmer/patrons/architecture/decisions/_resources/modele-decision.md

@@ -0,0 +1,71 @@
+# <UN TITRE ICI>
+
+## Très courte description
+
+<UNE PHRASE ICI>
+
+
+## Courte description
+
+<QUELQUES PHRASES ICI (optionel)>
+
+
+## Description
+
+<QUELQUES PHRASES ICI (optionel)>
+
+
+### Alternatives considérées
+
+* 👀 <ALTERNATIVE 1>
+* 👀 <ALTERNATIVE 2>
+* 👀 <ALTERNATIVE 3>
+
+
+### Élements moteur de la décision
+
+* 🧲 <BESOIN 1>
+* 🧲 <BESOIN 2>
+* 🧲 <BESOIN 3>
+
+
+## Conclusion
+
+* ✅ **<ALTERNATIVE RETENUE 1>**
+* 🤔 **<ALTERNATIVE EVENTUELLE 2 >**
+
+
+### Conséquences
+
+* 👍 <CONSEQUENCE POSITIVE 1>
+* 👍 <CONSEQUENCE POSITIVE 2>
+
+* 👎 <CONSEQUENCE NEGATIVE 1>
+
+
+### Comparaison (Optionel)
+
+#### <ALTERNATIVE 1>
+
+* 👍 <ARGUMENT 1 PRO>
+* 👍 <ARGUMENT 2 PRO>
+* 👎 <ARGUMENT 1 CONTRA>
+
+
+#### <ALTERNATIVE 2>
+
+* 👍 <ARGUMENT 1 PRO>
+* 👍 <ARGUMENT 2 PRO>
+* 👎 <ARGUMENT 1 CONTRA>
+
+
+#### <ALTERNATIVE 3>
+
+* 👍 <ARGUMENT 1 PRO>
+* 👍 <ARGUMENT 2 PRO>
+* 👎 <ARGUMENT 1 CONTRA>
+
+## Aller plus loin
+
+* 🧐 <RESOURCE 1>
+* 🧐 <RESOURCE 2>

data/base-de-connaissances/programmer/patrons/architecture/decisions/prendre-et-documenter-des-decisions.md

@@ -0,0 +1,85 @@
+# Prendre et documenter des décisions
+
+## Très courte description
+
+**Patron de conception** afin de **documenter et justifiés les choix**, par exemple les **choix d'architectures** (**ADR**) dans l'industrie logiciels.
+
+
+## Courte description
+
+Il existe un patron de conception qui s'applique aux décisions architecturales, [ADR](https://adr.github.io/).
+
+Ce patron peut-être **étendu à tout types de décisions**.
+
+
+## Par où commencer ?
+
+Voir le modèle proposé ici [_resources/model-decision.md](./_resources/modele-decision.md)
+
+
+## Description
+
+Les décisions ont besoins d'être **réfléchies** et **documentées**. 
+
+Les resources ci-dessous proposent des guides et exemples d'implémentations.
+
+* [Markdown (ADR)](ADRhttps://adr.github.io/madr/) | _propose des modèles et outils pour maintenir une liste de décisions en Markdown_
+* [Saisie de décision](https://schubmat.github.io/DecisionCapture/) | _encore des modèles_
+
+
+#### Définition
+##### **Architectural decision (AD)** _Décision architecturale_
+
+**Choix justifié qui répond à une exigence** fonctionnelle ou non fonctionnelle **significative** sur le plan architectural.
+
+Les **décisions d'architecture** répondent à des **exigences importantes** ; elles sont perçues comme **difficiles à prendre** et/ou **coûteuses à modifier**.
+
+
+##### Architecturally Significant Requirement (ASR)
+
+Les **exigences architecturallement significatives** sont celles qui ont un effet **mesurable** sur l'architecture. 
+
+Il s'agit d'**un sous-ensemble d'exigences**, le sous-ensemble qui affecte l'architecture d'un système de **manière mesurable** et **identifiable**.
+
+
+## En savoir plus
+
+* **ADR**: https://adr.github.io/
+* **Saisie de Décision**: https://schubmat.github.io/DecisionCapture/
+
+
+### Voir aussi
+
+##### Exemples
+* https://forge.liiib.re/libre.sh/libre.sh/-/tree/develop/docs
+
+
+## License
+
+[CC BY-SA 2.0 FR](https://creativecommons.org/licenses/by-sa/2.0/fr/)
+
+### Autheurices
+* grincheuxx
+* reminec @ acides.org (Tedomum.net)
+
+_Librement traduit depuis adr.github.io_
+
+## Versions
+### v0.1.0
+_Date : 26 mars 2023 | Temps rédaction : 25min_ | reminec
+* Reformatage 
+* Editions
+* Ne concerne plus que les ADR mais toutes les décisions
+
+### v0.0.2
+_Date : 17 mars 2023 | Temps rédaction : 30min_ | reminec
+* Reformatage
+* Editions
+
+### v0.0.1
+_Date : 17 mars 2023 | Temps rédaction : 30min_ | reminec, grincheuxx
+* Introduction à l'ADR par 2 novices sans experts
+
+## Remerciements
+
+* [PierreO.](https://mastodon.indie.host/@pierreozoux) @ [indiehosters.net](https://indiehosters.net) - Pour avoir soufflé ce patron de conception

docs/developpement/cas-usages/contenu/analyse-et-interpretation/001-markdown-tags-et-frontmatter.md

@@ -0,0 +1,65 @@
+# Saisie de contenu texte interprété en Markdown (Tags, FrontMatter)
+
+## Courte Description
+
+Interprétation du contenu au format Markdown, utilisation du FrontMatter, et des tags.
+
+## Description
+
+### Processus
+
+``` mermaid
+flowchart TB
+    Saisie[["Saisied de texte"]] --> |Représenter comme| Arbre("Un arbre noeudal MD")
+    Arbre --> |Parcours les noeuds| ProchainNoeud("Noeud")
+    
+    subgraph Analyse d'un noeud
+    ProchainNoeud -->|Extraction de| Tags("Tags (#FichePratique #OutilsVisio)")
+    ProchainNoeud -->|Extraire les| MetaNoeud("Métadonnées du noeud")
+    ProchainNoeud -->|Extraire le | ContenuNoeud("Contenu")
+    ContenuNoeud -->|Extraction d'autres| MetaNoeud("Métadonnées")
+    Tags-->|Ajout au| MetaNoeud
+    ContenuNoeud --> ContenuFM("ContenuMD et FrontMatter")
+    MetaNoeud --> ContenuFM
+    end
+    subgraph Publication du noeud
+    ContenuFM -->|Interpréter| Objet("Interprétations")
+    Objet -->|Publier| Rendus("Versions")
+    end
+```
+#### Comportements
+
+```gherkin-fr
+
+Fonctionnalité: …
+  Dans le but de pouvoir saisir du contenu texte et de pouvoir le réutiliser  
+  En tant qu'utilisateurice novice ou avancé
+  Je veux pouvoir écrire du Markdown via un éditeur, accéder à la source, le prévisualiser.
+  Je peut aussi avoir la main sur les métadonnées du contenu (ex: FrontMatter).
+  Je peut avoir un usage avancé des Tags (ou Hashtags).
+  Je peut avoir un usage naturel du balisage et des métadonnées
+  Je veux que la plupart de mon contenu saisi puisse être réutilisable
+  Je veux donc que la plupart de mon contenu saisi puisse être analysé, interprété, rendu.
+
+Règle: Saisie de contenu texte interprété en Markdown
+
+Background: ~
+
+Scénario: Saisie d'un contenu texte
+  Étant donné un contenu 'sample.md'
+  Quand le contenu est publié
+  Alors il a été interprété en Markdown
+  
+Règle: Analyse et interprétation des tags
+
+Background: ~  
+
+Scénario: Saisie d'un document texte avec des Tags
+  Étant donné un contenu 'FichePratique-OutilsVisio.md'
+  Et une métadonnée 'tags' qui contient '["DocumentMD", "OutilsVisio", "FichePratique"]'
+  Quand le contenu est publié
+  Alors il a été interprété en Markdown
+  Et on peut le retrouver par son tag '#FichePratique'
+  Et on peut le retrouver par ses tags '#FichePratique #OutilsVisio'
+ ```gherkin
+

docs/developpement/cas-usages/contenu/analyse-et-interpretation/005-emojis.md

@@ -0,0 +1,42 @@
+#  Analysie et Interprétation des émojis
+
+## Courte description
+
+Je veux pouvoir utilisé des Emojis pour qualifier du contenu dans un #Sujet.
+
+
+## Description
+
+
+### Processus
+
+``` mermaid
+flowchart TB
+ 
+    
+```
+
+
+### Comportements
+
+```gherkin-fr
+
+Fonctionnalité: Analyse et interprétation des emojis et des hashtags
+  Dans le but pouvoir qualifier un contenu, par exemple une 'astuce ou 'une alerte'
+  En tant qu'utilisateurice qui saisie du contenu Markdown
+  Je veux que lorsque ma ligne commence par l'emoji '💡 suivi d'un contenu qui contient le #Sujet'
+  Je peut retrouver cette 'astuce' dans la page relative au '#Sujet'.
+  Je veux aussi que mon ou mes sujets puissent être trouvé via le context
+
+Règle: Interprétér l'émoji 💡 en début de ligne comme une astuce.
+
+Background: ~
+
+Scénario: 
+  Étant donné un contenu 'FichePratique-OutilsVisio.md'
+  Et un contenu 'FichePratique-OutilsVisio.md'
+  Quand le contenu est publié
+  Alors il y a une astuce (💡) sur le tags
+
+```gherkin
+

docs/developpement/cas-usages/contenu/analyse-et-interpretation/010-comite-de-redaction.md

@@ -0,0 +1,53 @@
+### Rédacteurice en chef
+
+## Description
+
+
+
+``` mermaid
+flowchart TB
+ 
+    
+#### Configurer différentes vues (Versions) grace aux métadonnées
+
+```gherkin-fr
+
+Fonctionnalité: …
+  Dans le but de pouvoir avoir la main sur la publication du contenus
+  En tant que rédacteurice en chef
+  Je veux pouvoir étendre/creer/modifier/supprimer/forcer des regles sur des inclusions ou références de contenus
+  Je veux pouvoir via ces règles configurer la granularité du contenu inclus et/ou publié (ex: une courte, ou une très courte description ?)
+  Je veux pouvoir via ces règles proposer d'activer/désactiver des vues (aussi appelées, versions). (ex: suggest: 'Désactiver propos sarcastiques ?', version: '@reminec')
+ 
+ 
+Règle: > 
+  
+  Une metadonnée "Pré-requis" peut-être ajoutée à du contenu (via 'prereqs:')
+  Un contenu texte peut référencer des autres contenus
+  On pensera a mettre une regle ici pour definir comment on référence pas comme des porcs
+  On choisi alors si le contenu est Lier/Prévisualiser/Citer/Inclus.
+  On choisi aussi son niveau de granularité 
+
+  On espère pouvoir avoir la main sur l'analyse du contenu
+  On espère avoir la main sur l'extraction de contenu
+  On espère avoir la main sur le reformatage du contenu extrait
+  
+  
+Background: 
+  Étant donné un contenu 'FichePratique-OutilsVisio.md'
+  Et une métadonnée 'tags' qui contient '["DocumentMD", "OutilsVisio", "FichePratique"]'
+
+
+Scénario: Référencer des pré-requis pour une FichePratique et configurer leurs affichage
+  
+  Étant donné un contenu 'FichePratique-Jisty.md'
+  Et une métadonnée 'tags' qui contient le yaml suivant '["DocumentMD", "OutilsVisio", "FichePratique", 'Jitsy']'
+  Et une métadonnée qui contient le yaml suivant '[prereqs: [tags: "#OutilsVisio #FichePratique", widget: "Include", mode: "Extended", default: {collapse: true}]]'
+  Quand le contenu est publié
+  Alors la FichePratique-OutilsVisio.md apparait dans la section pré-requis en widget dépliable
+  Alors le widget pourrait avoir en entête le nombre de minutes (ou secondes) nécessaire à lire le contenu qui peut se déplier
+  Alors le widget pourrait avoir en entête le nombre d'astuces
+  Alors le widget pourrait avoir en entête le nombre de recommandations d'usages
+  Alors le widget devrait avoir en entête l'importance de attention que l'on devrait y consacrer    
+ ```gherkin
+

docs/developpement/decisions/fonctionnalites/avaler-du-contenu/001-utiliser-les-emojis.md

@@ -0,0 +1,71 @@
+# Utiliser les émojis
+
+## Très courte description
+
+Lors d'une saisie de contenu, je veux pouvoir utilisé des Emojis pour qualifier du contenu.
+
+
+## Courte description
+
+Lorsque le premier caractère d'un noeud Markdown est un émoji, qualifier le noeud via son Emoji.
+
+
+## Description
+
+Il faut lister les émojis et leurs correspondances.
+
+
+### Alternatives considérées
+
+* Utiliser des émojis
+
+### Élements moteur de la décision
+
+* 🧲 Le besoin de typer le contenu pour pouvoir le réutiliser ensuite
+* 🧲 Le besoin d'illustrer pour faciliter la lecture en diagonale
+* 🧲 Il doit être instinctif de faire usage du bon émoji
+
+
+## Conclusion
+
+* 📢 <UNE ANNONCE>
+* 👍 <UNE RECOMMANDATION>
+* 🙏 <UNE DEMANDE>
+* 💡 <UNE IDEE>
+
+* 🤔 <UNE REFLEXION>
+* 🧐 <UN INTERET>
+* 🤓 <UNE PASSION>
+* 😎 <UNE SATISFACTION>
+* 👀 <UNE CURIOSITE>
+* 😍 <UN COUP DE COEUR>
+* 🤩 <UN COMPLIMENT>
+
+* 💩 <UN DEGOUT>
+* 🧲 <UN ATTRAIT>
+
+
+
+* ⚠️ <UNE PRECAUTION>
+* 🚨 <UNE ALERTE>
+
+* ✅ <UNE VALIDATION>
+* 🚫 <UN REFUS>
+* ⚖️ <UNE DECISION>
+
+* 📌 <UN PENSE-BETE>
+* 🔗 <UN LIEN AVEC ...>
+
+* 🪚 <UNE TACHE A FAIRE>
+* 🚧 <UN CHANTIER EN COUR OU A ORGANISER>
+
+* 🧳 <UN DEPLACEMENT>
+* 📅 <UN RDV DE FIXE>
+* 🗺️ <UN ENDROIT>
+* 👥 <UNE RENCONTRE>
+
+* 🧪 <UNE EXPERIENCE>
+
+
+
+