Compare commits

..

3 commits

Author SHA1 Message Date
214314f8c6 Initialisation de la documentation de developpement.
Premiers jets de spécification.

about #24 @2h, #5 @45min
2023-03-29 17:38:57 +02:00
595f29aad5 Modele - compte-rendu.md de reunion
closes #7 @1h
2023-03-29 17:38:57 +02:00
e0fd4ea2b8 Premier jets sur les décisions
Renommage
Modele
Pas de gatsby

Co-Authored-by: grinche

closes #8 @20min, closes #23 @1h40min

_resources/modele-decision.md
2023-03-29 17:38:57 +02:00
7 changed files with 505 additions and 0 deletions

View file

@ -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

View file

@ -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>

View file

@ -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

View file

@ -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

View file

@ -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

View file

@ -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

View file

@ -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>