Action 8 - Typologie des articles

Oui c'est aussi une possibilité.

@maieul ça pourrait oui. Ça dépend de ce qu'on dit dans l'autre fil : à la suite de la remarque d'Éric, je me dis qu'on pourrait dire que par défaut tout ce qui n'a pas de typage est une documentation. Ce qui évite de devoir typer de nooooombreuses choses. Et comme ça on devrait que faire le boulot de typer les conceptions et annonces/actus (pour les anciens là dans le rangement, et à vérifier rapidement pour les nouveaux).

je rebondi la dessus, et je reviens. A mon sens un type non defini c'est pas top. J'aurais pluitot tendance à dire : typo retroactivement en utilisation tous les articles, et proposons par défaut comme type d'article "utilisation". Plutot que de dire type vide = utilisation. Je trouve ca plus propre.

On peut typer au maximum. Mais les squelettes devront toujours être souples et savoir quoi faire lorsqu'un article n'a pas de type rempli (et donc le prendre comme étant de l'aide utilisateur), de toute façon.

alors ok dans ce sens. Encore qu'avec champ extra, on peut rendre
obligatoire le typage, donc a priori ces cas ne devraient pas se poser.

Il ne faut jamais dire ça. :p
C'est une bonne pratique de programmation de toujours être strict en sortie (s'assurer que ce qu'on produit est le mieux possible), mais souple en entrée (s'attendre à gérer des cas tordus). Je me rappelais d'un article de Bortzmeyer qui évoquait ça mais je le retrouve plus. :)

il y a du vrai dans ce que tu dit. cela étant ca couterait pas grand
chose de remplir quand même, même si oui souplesse en entrée.

En fait, je me suis reposé la question hier en écrivant le doc parce que je me suis demandé si le typage qu'on propose est bien à utiliser dans tous les secteurs et pas uniquement dans les secteurs-plugin ?

Moi je pense aussi que ce n'est pas partout et que donc dans l'admin on ne doit pas l'imposer. Par exemple je pense que ça n'a aucun sens dans le carnet, c'est un wiki, on peut même créer des pages depuis la partie publique, c'est totalement libre, le wiki n'a pas à être cloisonné comme la partie éditoriale.

C'est bien mon avis aussi. Mais dans ce cas le problématique de l'interprétation de la valeur vide diffère d'un secteur à l'autre non ?

Bah c'est à chaque partie de squelettes de l'interpréter suivant son contexte. Et c'est bien pour ça que là en "entrée" le codage doit être souple. Dans tous les cas dans les parties où ya pas besoin (par ex Carnet), bah c'est sans objet puisque justement on l'utiliserait pas dans cette partie, et dans la partie publique, les squelettes de Gribouille n'en tiennent pas compte du tout de toute façon.

effectivement j'avais oublié cette problématique de multi sectorialité....

Ok, ça doit le faire. On part comme ça.

OK aussi pour la tri-partition de @rastapopoulos (et amha "documentation" mieux que "aide")

OK aussi, ça paraît très bien.

Je crois qu'on est d'accord sur la typologie à 3 valeurs. Le seul truc qui me gêne c'est le terme "documentation" par opposition à "conception". Tout est documentation.
Les alternatives que je vois, en considérant que "conception" et "actualité" conviennent à toute le monde, sont:
- utilisation ou utilisateur (au sens de manuel utilisateur)
- aide (proposition de Rasta)
- exploitation (au sens de doc d'exploitation)
- guide (peut-être trop restrictif)
- mode d'emploi
- tutoriel
- prise en main
- référence

perso "utilisation" me paraît bien :). Tuto/prise en main sont trop spécifiques. De même que référence (ou alors on distingue tuto vs référence). mode d'emploi ca fait IKEA. Aide je trouve ca va pas, parce que tout peu aider. Donc "Utilisation" (plutot qu'utilisateur, qui en plus serait pas épicène) me semble le mieux. Autre solution : "manuel" ?

guide, mode d'emploi, tutoriel, ce sont des types de docs utilisateurs, suivant leur "format", une manière de rédiger (des sous-types quoi), donc trop précis.

Comme je l'ai déjà dit plus haut, oui si on veut "documentation", ça peut vouloir tout dire. Mais dans le langage courant, pour la majorité des utilisateurs, la doc c'est comment utiliser un truc (que ce soit une interface mais aussi une API PHP), c'est la réponse à la question "comment moi je peux l'utiliser". Alors que conception c'est la réponse à "comment c'est fabriqué, comment c'est architecturé". Voilà pourquoi le mot "documentation" continue de me paraitre clair quand même pour la majorité des gens, ya juste 2 ou 3 personnes qui se poseront la question maxi.

Si vraiment on ne l'utilise pas, alors ma préférence va pour "utilisation", car c'est bien ça qu'on veut regrouper dans ce type : la doc d'utilisation, comment utiliser ce projet.

Si conception c'est "comment c'est architecturé", je vois pas en quoi
cela n'aide pas à utiliser... c'est aussi un sous type de doc.

Quid de "manuel"?

Dans l'ingénierie on distingue les documents de conception, d'exécution (as built), de formation et d'exploitation (exploitation et maintenance). En général, on réserve le terme manuel à l'exploitation et la maintenance mais c'est pas une règle intangible.
Franchement au fil de nos échanges je trouve que le meilleur compromis est conception, utilisation et actualité.

Ce compromis me va

Moi ça me va.

(Et non "comment c'est architecturé" ça ne sert pas du tout à l'utiliser, tu n'as pas du tout besoin de savoir ça pour l'utiliser. Tu as besoin de le savoir si tu veux aider au dévelopepement du projet, mais pour l'utiliser tu dois juste savoir soit l'interface, soit les boucles/balises que ça fournit, soit l'API publique PHP que ça fournit, mais pas du tout comment c'est architecturé.)

bon, ben je crois qu'on arrive à un consensu :)
(je crois que le terme "architecturé" a induit de la mecomprhension chez moi)

Ok, je mets ça dans le texte d'accueil.
Je ferme le fil ?

j'ai deja modifié le texte d'accueil. Mais allonsy pour fermer le fil
(et modifier le texte d'accueuil pour dire décison finale)

J'ai modifié un peu le texte d'accueil. Si on ferme on ne va plus voir le fil dans la liste. Je propose que pour l'instant on indique dans le titre que la discussion est close.

Je recopie ici ce que j'ai écrit dans mon GDoc. Est-on d'accord sur cette interprétation ?

La typologie des articles est également mise en place au travers d’un champ additionnel à l’objet Article nommé “type_article” qui contiendra les valeurs suivantes:
- “conception”, pour un article-conception,
- “actualite”, pour un article-actualité,
- “”, pour les autres articles. C’est la valeur par défaut du champ.
Cette valeur est interprété différemment suivant le secteur. Pour un secteur-plugin, cette valeur sera interprétée comme un article-utilisation. Pour le Carnet Wiki ou le secteur “A propos de Contrib” c’est la seule valeur possible. Pour le secteur Galaxie l’interprétation est identique à celle des secteurs plugins.

OK pour moi

Perso je ne suis pas contre (et c'est peut-être mieux) qu'il y ait un vrai type explicite pour l'aide utilisateur. Comme je le disais strict dans ce qu'on produit, mais souple sur ce qu'on reçoit. Mais le type peut-être toujours être vide (et dans une bonne partie du site, le vide serait reconnu comme l'aide utilisateur aussi par défaut).

Si je résume autrement ma proposition c'est en fait le "vide" s'interprète suivant le secteur et on a deux cas particuliers qui sont actualité et conception qui eux ont toujours la même interprétation. Et c'est les squelettes qui gèrent ça (surement avec un filtre bien pensé).

J'ai mis en oeuvre la notion de type d'article et d'article principal. Le type d'article avec un champ extra et l'article principal avec le plugin article d'accueil.
J'ai deux questions :

Pour le type d'article, 3 choix sont possibles, utilisation, conception et actualité. Lors de l'édition d'un article on a toujours ce choix proposé. Ne faudrait-il pas exclure certains choix suivant le secteur ?

Le plugin article d'accueil propose d'emblée la liste des articles de la rubrique quelque soit leur type et leur statut. J'ai fait une modification hier sur le plugin afin que l'on puisse modifier la liste des statuts autorisés et éventuellement ajouter un filtre.
Aussi :
* ne faudrait-il pas réduire les statuts (mais ça voudrait dire qu'on ne pourrait pas choisir l'article au début) ?
* et surtout ne faudrait-il pas réduire la liste des articles à ceux du type "utilisation" uniquement ? On pourrait aussi choisir un article "conception" pour un projet uniquement.

A votre avis ?

Si jamais il est utile de restreindre, ça me semble pas important de le décider tout de suite.

En tout cas j'ai les outils pour le faire facilement par paramétrage avec les modifications que j'ai faites dans le plugin contrib et article_accueil.

Pour le type, je le disais je ne sais plus quand : ça peut être filtré suivant les compositions sûrement. Car les rubriques-catégories vont aussi avoir une composition dédiée sûrement (vu que possiblement présentation dédiée). Ce qui permettrait déjà de pas afficher les types dans le Carnet par exemple.

Pour l'article d'accueil, non, je ne vois pas pourquoi on limiterait quoi que ce soit. C'est de l'éditorial, ya rien à bloquer techniquement. Je peux préparer ma rubrique et déjà savoir lequel des articles sera le principal. Et je peux y mettre n'importe lequel des articles, c'est pas à toi de le dire. Après ya des admins qui relisent, donc suivant une charte éditoriale, mais pas technique bloquée.

Petit up en relation avec ceux des actions 3 et 2:
La typologie des articles est opérationnelle dans le plugin Contrib.
A voir dans le site de démo (cf. actions 2 et 3).