Cinq façons de contribuer
- Signaler un écart : un menu, une icône ou un texte qui ne correspond pas au vrai système. Une capture du système réel, avec sa version, vaut toutes les descriptions.
- Proposer un système ou une version qui manque, en expliquant à qui il servirait (une association, une école, un public précis).
- Tester un parcours en atelier ou en classe et nous dire où les apprenants bloquent. Ce retour de terrain oriente nos priorités.
- Écrire un parcours pédagogique : une suite de missions courtes jouées dans le bureau simulé, sur le modèle des parcours existants.
- Contribuer au code : reproduire un écran, corriger un comportement, améliorer l'accessibilité, en suivant la doctrine de code.
Pour commencer, écrivez-nous en précisant ce que vous souhaitez faire : nous vous indiquons comment accéder au dépôt et par où commencer.
À ne pas confondre avec l'offre « Contributeur » du site, qui est un soutien financier donnant accès à la simulation libre. Contribuer au projet lui-même est ouvert à tous.
Les cinq règles qui ne se discutent pas
- Rien d'inventé, rien d'emprunté : une icône, un fond d'écran ou une police viennent du vrai système reproduit, jamais d'un autre. Un élément manquant reste un manque visible et documenté.
- Les pages des bureaux sont générées : on modifie la source, puis on relance la régénération des vues. Une page générée modifiée à la main serait écrasée sans prévenir.
- On indexe ses fichiers un par un : plusieurs contributeurs travaillent en même temps sur le même arbre, et un ajout en masse emporterait leur travail en cours.
- Pas de publication sans validation : les contrôles automatiques doivent passer avant qu'une modification rejoigne la branche principale.
- JavaScript strict, sans modules ni syntaxe récente non prise en charge partout (pas d'import/export, ni de chaînage optionnel) : le site doit fonctionner sur des navigateurs anciens et depuis un simple dossier.
Ces règles ne sont pas seulement écrites : la plupart sont vérifiées par des scripts qui refusent une modification non conforme. Le détail et les raisons sont dans la doctrine de code.
Le cycle d'une contribution
| Étape | Ce que l'on fait |
|---|---|
| 1. Comprendre | Identifier le système visé et la couche concernée : noyau commun, famille d'OS, environnement de bureau ou peau d'une distribution. |
| 2. Vérifier l'état | Lancer les contrôles du périmètre : on ne construit pas sur un état en échec. |
| 3. Relever avant de coder | Consulter l'inventaire du vrai système (captures, textes, icônes). Sans relevé, pas de modification de l'apparence. |
| 4. Modifier au minimum | Écrire dans la bonne couche : un comportement partagé par deux systèmes va dans le code commun, jamais copié deux fois. |
| 5. Régénérer | Reconstruire les pages des bureaux et les versions hors ligne. |
| 6. Valider | Faire passer les contrôles, mesurer la fidélité si l'apparence a changé, puis proposer la modification. |
Ce qu'il faut pour travailler
- Un éditeur de texte et un navigateur récent : il n'y a ni framework, ni étape de compilation obligatoire.
- Node.js pour les outils de génération et de contrôle (ils ne sont jamais chargés par le navigateur).
- Un petit serveur web local pour tester en conditions réelles, ou l'ouverture directe des fichiers pour le mode hors ligne.
Dites-nous ce que vous aimeriez apporter : signalement, système, parcours ou code.Nous écrire