Ce site est optimisé pour être consulté depuis un navigateur moderne dans lequel JavaScript est activé.

DEBAT: Défauts de la documentation actuelle et idées d'amélioration

mydjey

L'idée c'est que ne pas être une référence n'interdit pas d'avoir un avis raisonnable mais être raisonnable interdit d'étaler son avis comme référence.
Donc discuter avant de modifier un article à sans doute un intérêt.

Je rejoins l' avis de Tomzz.
Discuter avant d' apporter quelques modifications pourrais être pratique.
Si j'ai envie d'apporter une petite modif et que je ne suis pas très sûr de moi, cela permet de discuter avant d' appliquer la modif, la qualité en sera que meilleur.

C'est vrai que l' enchainement des versions complique énormément la mise à jour du wiki.
Comment gérer la mise à jour du wiki facilement et avec efficacité, à chaque nouvelle version ?
Grande question.

Le wiki est très complet,dans la plupart des cas je trouve réponse à mes questions.
Je n'ai jamais retrouvé cela sur un autre site.
A mon avis c'est la plus grande force d'Ubuntu: La qualité (et exhaustivité) de la doc.
Certains tuto sont vraiment très bien écrit.
C'est vraiment agréable de trouvé réponse à la plupart des questions, en restant sur une site.
Et c'est vrai qu'il ne faut pas la laisser vieillir.
Vu le rythme des versions ce n'est pas évident, le problème se situe surtout à ce niveau.

draco31.fr

ljere a écritc'est ce que j'ai fait merci pour l'adresse
mais mon message est refusé

C'est embêtant ça, parce que j'envoi tout mes mails à cette adresse !
Par contre, essai d'envoyer un mail par trop gros (sans pièce jointe) et de préférence au format texte brute (pas de HTML).

@ djètux
Je pense que la solution des nouvelles versions réside dans la création de session "MAJ de la Doc" à l'image des bugs party.
En gros, il faudrait convenir d'une soirée/un week-end, ou autre, pour que les contributeurs relisent la doc par lot, et ajoute le tag si nécessaire. Bien évidemment, certaines pages techniques ne pourront pas être taggée à la va vite, mais d'autres (Totem, VLC ...) ont peu de risque !

Pour ce qui est de discuter avant d'agir, je dis oui et non !
Oui dans l'idée, c'est très bien ...
Mais encore faut-il que des personnes répondent aux questions/propositions.
Trop souvent, des propositions sont faites sur la ML sans qu'il n'y ait d'écho.
Que faut-il en penser : Oui on fait, Non on fait pas, on attend ?
Bref, la force de la doc c'est aussi qu'il n'y a pas à attendre une quelconque validation pour la faire évoluer.
Le revers de la médaille, c'est qu'elle n'est pas homogène.

Il me semble que le plus dur, c'est de trouver les gens qui ont la connaissance et de les mettre en relation avec les gens qui sont pédagogues.
Quand les 2 qualités sont réunies dans la même personne, on a de très belle page, mais l'un sans l'autre, on a des page technique mais incompréhensible (ou "introuvable") pour le lecteur, ou à l'inverse, des pages qui n'apportent pas de "plus" à la doc.

mydjey

Il me semble que le plus dur,[........]ou à l'inverse, des pages qui n'apportent pas de "plus" à la doc.

Oui, oui je partage cette idée, les gens qui ont de grosses compétences technique, ne savent pas forcement mettre en forme ou expliquer de manières claire, quelquefois il zappent des choses qui pour eux son évidentes, mais qui ne le sont pas forcement pour tout le monde.
Ca me fait penser à certains profs 😃, qui avaient de grandes connaissances mais qui ne savaient pas les transmettrent, et qui n'arrivais pas à intéresser l'élève à leurs cours.

Ca serais intéressant de pouvoir travailler en coolaboration : D' un côté des gens prêt à rédiger des tutos de manière clair et didactique.Et de l'autre d'avoir des gourous en system Linux pour apporter les technicité.
Même un débutant sous Ubuntu peux dans ce cas là apporter son aide, si c'est quelqu'un qui est pédagogue.
J'imagine bien qu'un certain nombre de docs on déjà été écrit de cette manière.

Sinon sur le fait de pouvoir discuter avant de modifier le wiki c'est sur que si il n'y a pas de retour, ça limite les choses.

Les "Docs party" bonne idée.

poupoul2

Salut à tous

Suite à une petite discussion sur la ML, une idée simple à ajouter dans les pages applications : Un cartouche de résumé en tête de page. Ça pourrait donner ça. Les icônes sont faites à l'arrache, mais c'est pour l'idée. Les icônes sont cliquables. Ce cartouche serait à ajouter sur toutes les pages applications et permettraient de présenter rapidement s'il s'agit d'un logiciel libre ou non, la licence de logiciel et un accès direct à sa homepage.

YannUbuntu

ca me parait utile et réalisable 🙂 Il faudrait creer un exemple pour voir ce que ca donne , et lister les icones qui seraient disponibles.

Mpok

Je plussoie Brunod (cf. plus haut) pour le "problème" des versions..
Quoique dans la doc, un effort est déjà réalisé sur beaucoup de pages (mais pas toutes) pour contrer au maximum ce souci.
En revanche, pour ce qui est de la recherche dans le forum, là, RIEN n'est fait. :/
Et quand on fait une recherche sur le forum, y'a rien de plus énervant que de se retrouver (à cause des "subtilités" de l'algo Google) avec une tripotée de pages très anciennes qui le plus souvent ne sont d'aucune aide.
Un système de "tags" (au moins par année, sans vouloir forcément aller jusqu'à la version Ubuntu) serait à mon avis utile.

poupoul2

YannUbuntu a écritca me parait utile et réalisable 🙂 Il faudrait creer un exemple pour voir ce que ca donne , et lister les icones qui seraient disponibles.

J'ai pris exemple sur la page d'Abiword.

Pour les icônes, il serait intéressant d'avoir
- des icônes pour les principales licences libres (GPL + version, AGPL, BSD...). Une fois un modèle d'icône déterminé, créer les icônes pour chaque licence est rapide.
- Des icônes pour chaque environnement de bureau (Gnome / Kde / XFCE...). Je n'ai pas fouillé dans les images déjà disponibles, mais à mon avis elles sont toutes déjà là.
- 2 icônes Oui / Non pour la cas logiciel libre (c'en est ou pas, il n'y a pas de peut-être 😉 )

Des trucs à discuter :
Si le logiciel est disponible sous plusieurs licences, que présente-t-on ? On peut imaginer présenter une seule licence, libre si possible, au choix du rédacteur. Je serai plutôt partisan d'avoir une icône pour les licences multiples, avec un lien vers la page licences du logiciel concerné.
Pour les environnements, j'ai présenté Gnome puisqu'Abiword fait partie de Gnome Office (facile dans ce cas). Pour les applications disponibles sous plusieurs environnements (Firefox ou OpenOffice.org par exemple), il serait sans doute intéressant de disposer d'une icône pour le multi environnement.
Pour les liens, autant que faire se peut, les liens devraient pointer vers des pages de la doc, avant de pointer vers des pages externes. En revanche, on ne crée pas de page spécifique si elles n'existent pas, sauf s'il y a une autre justification à la création d'une page.
Les icônes devraient être disponibles dans le répertoire des images. Il faut trouver un moyen de faciliter l'accès au code correspondant pour les contributeurs de la doc, par exemple en rédigeant une page présentant toutes les icônes disponibles et le code associé. Il n 'y aurait alors plus qu'à faire du copier / coller. Sauf si on est capable de créer un plugin doku qui permette d'insérer directement le code, à partir de la barre de menu.

Peut être d'autres éléments à ajouter dans le cartouche ? L'idée est de faire quelque chose de plutôt visuel, donc graphique, donc avec le moins de texte possible, le texte étant déjà disponible dans le reste de la page.

rmy

Excellente idée. On pourrait y ajouter (dans le cartouche ? séparément ?) une icône représentative de la "validité" de la page, pour avoir un retour qualité... Cela pourrait donner en un coup d'oeil une info sur le fait que la page soit d'actualité/obsolète, validée ou non par l'équipe qui gère le wiki etc...

YoBoY

Salut,

Vous avez pu voir cet été que ça bouge sur le wiki, on arrive même à corriger des bugs maintenant 😛

Pour pas que vous vous inquiétez et pour savoir où on se dirige je vais faire le point sur mes futures priorités.

1- corriger le bug le l'IP de Lisa
2- étudier la possibilité de mettre ou pas le plugin boxes
3- mettre en place le "force preview" pour vous embêter un peu
4- masquer la colonne de gauche (c'est déjà en cours cela dit, merci à Olive)
5- développer des plugins propres à notre utilisation de dokuwiki.

C'est sur le point 5 que tout va se jouer. En vrac et suite à la lecture des différentes demandes/propositions/autre de chacuns, il faut en fait que nous développions des outils pour nous permettre de maintenir simplement et rapidement les pages de documentation (validation simplifié avec ajout d'un tag de version pour les passage de nouvelle version par exemple), améliorer la visibilité des informations courantes (cartouche de résumé, blocs relatifs aux versions), automatiser les informations en utilisant ce qui est disponible ailleurs (lien avec les dépôts, création de liens auto vers sites officiels, docs, plateforme de bugs, ...)

Bref beaucoup d'idées, et peu de moyens comme d'habitude pour les réaliser, donc ça peut prendre un peu de temps.

Cela dit parallèlement à ça, on a toujours en vue le changement de la page d'accueil et du design dans nos objectifs à court et moyen terme.

Bonne continuation à tous et au plaisir de lire vos contributions

zebulonT

Bonjour, 🙂

poupoul2 a écritSi le logiciel est disponible sous plusieurs licences, que présente-t-on ? On peut imaginer présenter une seule licence, libre si possible, au choix du rédacteur. Je serai plutôt partisan d'avoir une icône pour les licences multiples, avec un lien vers la page licences du logiciel concerné.

Je pense aussi qu'il est préférable présenter toutes les licences dans le cas de licences multiples... Sur quel critère objectif faire le choix d'une seule licence dans le cas contraire ?

poupoul2 a écritPour les environnements, j'ai présenté Gnome puisqu'Abiword fait partie de Gnome Office (facile dans ce cas). Pour les applications disponibles sous plusieurs environnements (Firefox ou OpenOffice.org par exemple), il serait sans doute intéressant de disposer d'une icône pour le multi environnement.

Je dirais même que dans bien des cas, une application fonctionnera très bien sous différents environnements de bureau et qu'il est un peu "réducteur" de la classer dans un environnement particulier même si certaines applications ont effectivement une filiation bien marquée avec un environnement de bureau...
Personnellement je fonctionne avec LXDE et j'utilise indifféremment des applications originaires de Gnome, KDE, XFCE, ou encore indépendantes...
Dans le cas d'Abiword justement, sauf erreur de ma part, il est aussi installé par défaut avec Xubuntu. 😉

Je ne dis pas que l'icône du bureau n'est pas très pertinente mais qu'il convient toutefois de nuancer la valeur de cette information afin de ne pas laisser croire aux nouveaux venus et néophytes qu'une application serait "exclusivement" destinée à un environnement de bureau particulier...

poupoul2 a écritLes icônes devraient être disponibles dans le répertoire des images. Il faut trouver un moyen de faciliter l'accès au code correspondant pour les contributeurs de la doc, par exemple en rédigeant une page présentant toutes les icônes disponibles et le code associé. Il n 'y aurait alors plus qu'à faire du copier / coller. Sauf si on est capable de créer un plugin doku qui permette d'insérer directement le code, à partir de la barre de menu.

Avoir une page avec les exemples de codes qu'il suffit de copier/coller est très certainement une bonne chose.
Il existe également le très bon plugin snippets pour dokuwiki qui permet d'insérer du code à partir d'une liste de templates. Mais dans le cas présent, cela obligerait au moins à faire un template pour tous les cas de figures les plus fréquents...

poupoul2 a écritPeut être d'autres éléments à ajouter dans le cartouche ? L'idée est de faire quelque chose de plutôt visuel, donc graphique, donc avec le moins de texte possible, le texte étant déjà disponible dans le reste de la page.

L'idée que ce soit essentiellement visuel est intéressante mais limite un peu le type d'informations que l'on peut donner via ce cartouche...
Il me semble que mettre une case sur la langue du logiciel ne pose pas trop de problème avec l'utilisation de petits drapeaux. Ou alors, tout comme pour la "case à cocher" (Oui/Non) du logiciel libre, on met une case à cocher avec un drapeau français (dans le titre de la colonne) qui indique que le logiciel est correctement francisé.

Une autre information que je trouve intéressante de donner dans ce cartouche est la taille de l'application une fois installée... C'est utile pour les petites configurations et très ancienne machines. 🙂

Mais je conçois que seule la taille totale occupée sur le disque après installation est pertinente. Et dans le cas de paquets multiples et/ou nombreuses dépendances, cela suppose de faire une analyse du disque avant et après installation afin de pouvoir donner une info correcte... Ce que tout les contributeurs ne font pas forcément.

L'autre information intéressante à mettre dans ce cartouche est la date et le numéro de la dernière version. Cela permet de se faire une idée de la "vitalité" du projet. Certaines applications sont intéressantes mais leur développement semble à l'arrêt depuis quelques années... Ce qui ne les empêchent pas d'être très utiles pour la qualité des services qu'elles rendent encore.

Voila ma petite contribution à la réflexion sur le sujet. Et inutile de préciser que je trouve l'idée de ce "Cartouche de résumé" très pertinente ! 😉

Bien cordialement.

draco31.fr

zebulonT a écrit
poupoul2 a écritPour les environnements, j'ai présenté Gnome puisqu'Abiword fait partie de Gnome Office (facile dans ce cas). Pour les applications disponibles sous plusieurs environnements (Firefox ou OpenOffice.org par exemple), il serait sans doute intéressant de disposer d'une icône pour le multi environnement.
Je dirais même que dans bien des cas, une application fonctionnera très bien sous différents environnements de bureau et qu'il est un peu "réducteur" de la classer dans un environnement particulier même si certaines applications ont effectivement une filiation bien marquée avec un environnement de bureau...
Personnellement je fonctionne avec LXDE et j'utilise indifféremment des applications originaires de Gnome, KDE, XFCE, ou encore indépendantes...
Dans le cas d'Abiword justement, sauf erreur de ma part, il est aussi installé par défaut avec Xubuntu. 😉

Je ne dis pas que l'icône du bureau n'est pas très pertinente mais qu'il convient toutefois de nuancer la valeur de cette information afin de ne pas laisser croire aux nouveaux venus et néophytes qu'une application serait "exclusivement" destinée à un environnement de bureau particulier...

Tout d'abord, c'est une très bonne idée.
Mais il faut prendre en compte plusieurs paramètres :
1. Le wiki est accessibles au utilisateurs d'Ubuntu au sens large (Ubuntu, Kubuntu, Xubuntu), il faut donc que les informations soient valables dans tout les environnements.
2. Plus il y a d'informations dans le cartouche, plus il y aura de suivi/maintenance à réaliser

Ainsi pour le point 1., ton exemple me fait remarquer que :
- Abiword n'est pas installé par défaut sur Ubuntu, pourtant basé sur Gnome
- Abiword est installé par défaut sur Xubuntu, pourtant basé sur Xfce
Je pense donc qu'il est préférable de présenter le langage et les librairies graphiques utilisées (C, python, QT, GTK2 ...) plutôt que de cibler un environnement !
Ner0lph a déjà créé un exemple dans le même genre http://doc.ubuntu-fr.org/ner0lph/laurux
De la même manière, la taille de l'application ne me semble pas un critère pertinent.
Sous Ubuntu, une application en QT3 entrainera l'installation de nombreuses dépendances ce qui fera grandir la taille finale occupée sur disque, alors que sous Kubuntu, toutes les librairies seront pré-installées.

Pour le point 2., j'ai peur que toute information redondante avec le contenu de la page entraine une maintenance plus grande, notamment lors du changement de version Ubuntu.
Nous avons déjà le système de tag pour cela, et de plus, les dépôts n'intègrent pas toujours les dernières versions.
Par exemple, MPlayer est toujours en version 1.0 rc2 alors que la rc3 est disponible depuis longtemps, et que le projet vit beaucoup, notamment via le SVN (même s'il n'y a pas de publication de nouvelle version majeure).

Ce que je trouve pertinent, et plutôt stable :
- La licence (ce qui inclus l'information libre/non libre)
- Le langage et les librairies (ça revient à indiquer la compatibilité avec un environnement de bureau)
- Le site web du projet
- Le mode de distribution : afficher toutes les possibilités : dépôt (officiel/non officiel), paquets deb, sources tar.gz ...

Ce que je trouve optionnel (le plus souvents des tags existent déjà) :
- La distribution où l'application est installée par défaut : Ubuntu, Kubuntu, Xubuntu, Ubuntu Studio ...
- L'univers pour le support canonical (main, univers, multiverse, restricted)
- La section à laquelle appartient le logiciel (accessoires, infographie, internet, jeux ...)

Autre remarque, sur l'utilisation d'icône, et la position du cartouche (avant le titre ou après).
C'est effectivement plus beau avec des icônes, mais en revanche, ça ne "montre" pas de texte.
Ainsi, si on utilise une balise {topic>} pour lister des pages suivant un tag, on peut afficher le début de la page.
généralement, ce sont les phrases d'intro, mais sans mise en forme dokuwiki.
Il serait intéressant de pouvoir visualiser le contenu du cartouche dans ce cas.
Seulement, les balises pour les images/liens rendraient le tout peu lisible.
A peser le pour et le contre, sachant que l'utilisation du "topic" est fortement remise en question.

zebulonT

draco31.fr a écritJe pense donc qu'il est préférable de présenter le langage et les librairies graphiques utilisées (C, python, QT, GTK2 ...) plutôt que de cibler un environnement !

Je pense aussi que c'est la meilleure façon de procéder. 🙂

draco31.fr a écritNer0lph a déjà créé un exemple dans le même genre http://doc.ubuntu-fr.org/ner0lph/laurux

Personnellement j'aime assez une solution "simple" tel que celle de l'exemple de Ner0lph (tableau avec texte) mais je dois reconnaître que l'utilisation d'icônes donne une lecture "graphique" non dénuée d'intérêt.

draco31.fr a écritSous Ubuntu, une application en QT3 entrainera l'installation de nombreuses dépendances ce qui fera grandir la taille finale occupée sur disque, alors que sous Kubuntu, toutes les librairies seront pré-installées.

C'est généralement vrai pour l'installation d'une première application en QT3... Lors de l'installation de la 2ème application en QT3, il y déjà de fortes chances pour qu'une partie importantes des dépendances requises aient été installées avec l'application précédente.
Mais je suis d'accord avec toi pour dire que la taille n'est pas une information "prioritaire" à donner dans ce cartouche.

🙂

poupoul2

J'ai revu le cartouche pour prendre en compte vos remarques. La seule information non présente actuellement est le mode de distribution.

Autre remarque, sur l'utilisation d'icône, et la position du cartouche (avant le titre ou après).
C'est effectivement plus beau avec des icônes, mais en revanche, ça ne "montre" pas de texte.
Ainsi, si on utilise une balise {topic>} pour lister des pages suivant un tag, on peut afficher le début de la page.
généralement, ce sont les phrases d'intro, mais sans mise en forme dokuwiki.
Il serait intéressant de pouvoir visualiser le contenu du cartouche dans ce cas.
Seulement, les balises pour les images/liens rendraient le tout peu lisible.
A peser le pour et le contre, sachant que l'utilisation du "topic" est fortement remise en question.

Je suis plutôt contre le fait de mettre du texte dans le cartouche. Les pages sont déjà pleines de textes, et l'objectif du cartouche est de donner une information rapidement assimilable par le lecteur. On peut en revanche associer aux cartouches une page d'explications (sur l'icône point d'interrogation), donnant le sens de chacune des icônes, certaines étant peu lisibles au premier coup d'oeil, notamment celles des librairies/langage.

Pour les icônes, en voici un ensemble (sans doute à compléter). Le fichier source (non publié pour le moment) est en svg.

C'est toujours sur la même page de test. J'ai laissé le précédent cartouche pour comparaison.

draco31.fr

Pour la source, tu peux utiliser l'icône APT, vu que Abiword est dans les dépôts.
Pour la licence, il me semble important de préciser la "version", je crois que la GPLv1, v2 et v3 ne sont pas équivalentes...

Pour GTK, j'aurai plutôt penché pour une icône plus "parlante" comme : http://upload.wikimedia.org/wikipedia/commons/thumb/2/2d/GTK.svg/260px-GTK.svg.png
Dans ce cas, l'absence de texte n'aide pas beaucoup si on ne connais pas l'icône et que rien n'est écrit dessus !

Par ailleurs, pourrais-tu expliquer les significations du carré rouge et des carrés vert, rouge, noir empilés ?

poupoul2

draco31.fr a écritPour GTK, j'aurai plutôt penché pour une icône plus "parlante" comme : http://upload.wikimedia.org/wikipedia/commons/thumb/2/2d/GTK.svg/260px-GTK.svg.png.
Dans ce cas, l'absence de texte n'aide pas beaucoup si on ne connais pas l'icône et que rien n'est écrit dessus !

En l'occurrence, j'ai utilisé l'icône officielle. Je ne suis pas convaincu du tout que GTK ou Qt parlent à un débutant, ni que ce soit la meilleure information à présenter. Ce problème existerait également avec l'environnement de bureau, mais sans doute dans une moindre mesure. Ceci étant dit, je n'ai pour l'instant pas d'alternative à proposer sur ce sujet :/ .

draco31.fr a écritPar ailleurs, pourrais-tu expliquer les significations du carré rouge et des carrés vert, rouge, noir empilés ?

Vert, c'est libre; rouge, ça ne l'est pas; coloris multiples, le logiciel est distribué sous licences multiples, pouvant intégrer aussi bien du libre que du non-libre (Virtualbox par exemple).

YannUbuntu

bonne idée ce cartouche 🙂 quelques remarques pour faire avancer le schmilblik :

http://doc.ubuntu-fr.org/ner0lph/laurux
- Développeur : info difficile a maintenir. le site officiel suffit a mon avis.
- je prefere la presentation par icones

http://doc.ubuntu-fr.org/utilisateurs/poupoul2/cartouche#abiword
-Environnement/librairies graphiques: l'important pour un utilisateur debutant est de savoir si l'application s'integre bien dans son environnement. L'utilisateur avancé souhaitera savoir si c'est du QT3 ou QT4 par exemple. (Le langage ca va un peu loin a mon avis, mais avec le debat sur mono pourquoi pas...). On peut presenter ces 2 infos separement, ou bien les regrouper dans une seule icone: pour cela on peut imaginer une icone GTK sur fond d'icone U/X/Edubuntu, une icone QT4 sur fond d'icone Kubuntu etc.
- on peut definir des url aux images de facon a ce qu'un clic sur une icone redirige vers une page d'explications: un lien wikipedia par ex, ou une page de la Doc plus specifique ("les appli GTK s'integrent bien dans Ubuntu/Xubuntu/Edubuntu etc.")
-Logiciel libre/Licence/commercial: on peut regrouper ces 3 infos en une seule icone (prendre les icones de http://doc.ubuntu-fr.org/jeu et y ajouter via Gimp le nom des licences). D'ailleurs les 4 icones "licence" de la page jeu indiquent en meme temps si l'appli est native linux ou si l'on passe par wine.
- toujours sur le modele de la page Jeu, il serait intéressant d'indiquer la Facilité d'installation. (AMHA beaucoup plus utile pour un debutant que de savoir le langage de l'appli 😉 )

draco31.fr

Je pense à une autre info.
Il serait intéressant de donner la version du logiciel dans les dépôts des 3/4 dernières versions d'Ubuntu (actuellement Hardy, Intrepid, Jaunty, Karmic).
Cette information peut également être trouvée via packages.ubuntu.com
D'ailleurs, un lien vers l'url adéquate pourrait faire l'affaire et éviter de la maintenance.

jahwork

Salut à tous,

Pour faire avancer le schmilblick du cartouche:

1. La page exemple de ner0lph a été déplacé ici:
http://doc.ubuntu-fr.org/utilisateurs/ner0lph/laurux

2. Je trouve l'idée très bonne => qu'est-ce qu'on attend pour le mettre en place ?? 😉
C'est bien de discuter/échanger pour mettre en forme l'idée.
Le risque c'est de trop discuter et de ne jamais le faire.

Je pense qu'on peut partir sur l'exemple de poupoul2 (http://doc.ubuntu-fr.org/utilisateurs/poupoul2/cartouche)
puisque globalement il convient.

En fait ce qui me frustre c'est de surfer sur la doc et me dire :
"Tiens il est sous quel licence ce soft..."
voir cette discussion à ce propos : https://eshu.ubuntu-eu.org/pipermail/ubuntu_wiki-fr/2009-April/032546.html
ou
"Eh mais il me semble qu'on a parlé d'un cartouche sur la liste... qu'en est-il"
et
"Je mettrais bien le cartouche, mais qu'a-t-il été décidé"

Mon avis:
- on commence à le mettre sur les pages
- le mettre sur la page modèle
- on pourra toujours le faire évoluer
- mais si on ne commence pas...

Qu'en dites vous ? Les admins ?

my 2 cents

Matthias

ps: et merci à Poupoul2 d'avoir lancé l'idée !

YannUbuntu

Merci de relancer l'idee, que je trouve tres bonne aussi. Avant de partir tête baissée, je pense qu'il faudrait faire une page avec différents exemples de cartouches possibles.
Pour cela, le plus simple est de piocher dans les jeux qui propose une bonne diversité de licences, environnements etc.
Tu peux nous faire ca sur ta page utilisateur stp ? (ICI par exemple)

jahwork

En fait j'ai aussi relancé le thread sur la ML (ça m'etonnerais que tu ne l'aies pas vu 😉 )

YoBoy disait qu'il fallait attendre l'étude du plugin data pour voir ce que ça pourrait donner.
Après cette étude je pourrais bien sur faire des exemples au besoin.

Ner0lph a confirmé.
2 admins ont parlé, j'attends sagement :cool:
(oui je m'économise 😛)

voila, voilaaaa 🙂

« Page précédente Page suivante »