Nous avons un grand nombre de guides. Parfois, @dax ou @jomaxro partage un guide howto dont je ne savais même pas l’existence, et je suis bluffé !
J’ai constaté que c’était aussi le cas pour beaucoup de nouveaux utilisateurs et de gestionnaires de communauté sur Discourse ici sur Meta. Pour résoudre ce problème, @justin a eu une idée géniale : regrouper nos guides howto et offrir à tous un meilleur point de départ, avec l’espoir d’aboutir à quelque chose de similaire à https://support.teams.discourse.com/docs
Haha oui, il y en a ! Idéalement, si nous pouvions avoir entre 6 et 12 tutoriels par catégorie, ce serait parfait. Nous ne cherchons pas à les catégoriser tous, mais seulement les meilleurs que les gens pourraient rechercher.
@osioke – une approche possible consiste à identifier les tutoriels les plus consultés qui correspondent à ces catégories et à sélectionner les 6 à 12 les plus populaires pour les étiqueter en conséquence. Ce serait un point de départ simple, combiné aux suggestions de @Benjamin_D ici !
L’avantage des étiquettes, c’est que nous pouvons facilement les modifier au fur et à mesure.
Merci de partager cela @Benjamin_D ! L’un des points avec lesquels je luttais était la façon de présenter et de concevoir la structure ; votre tableau ici aide énormément.
Je cherche maintenant à étendre le regroupement de 3 à 6 :
Premiers pas
Configuration
Configuration avancée
Contribution
Paramétrage
Paramétrage avancé
Et comme l’a partagé @justin, en examinant les plus consultés, voici les 20 premiers :
Hmm, les articles sur la configuration de la connexion pourraient probablement constituer une catégorie à part entière. Ils font partie de la section « Premiers pas », car c’est l’une des premières choses à faire sur un nouveau site, si l’on souhaite le faire.
Je ne suis pas sûr que la mention du multisite soit nécessaire ici ou peut-être que le groupe de configuration avancée pourrait inclure un avertissement, recherchez les métadonnées ! Par exemple, ce post est très utile pros-and-cons-of-a-multisite-installation.
Je pense que je placerais Set up Reply via Email Support dans le groupe de configuration avancée (puisque je ne l’ai toujours pas fait ) et straightforward-direct-delivery-incoming-mail mérite probablement d’être mentionné, mais peut-être dans le groupe de configuration avancée, parce que… eh bien… les e-mails .
C’est vrai, la liste est basée sur les 20 articles les plus consultés, et je l’ai partagée pour illustrer ma réflexion sur l’organisation. Elle n’est en aucun cas la version finale ; j’aurais dû être un peu plus clair
J’aimerais voir « Administration » ou « Opérations » comme catégorie pour les activités d’administration et de modération continues. Cela ne correspond pas à la configuration/paramétrage et ne relève pas du développement/Documentation (contribution).
Je suppose que le site de documentation Discourse for Teams utilise Discourse pour toutes les documentations. Le problème avec cela pour un site de tutoriels sur Discourse où n’importe qui de la communauté peut participer, c’est la gestion des versions et le suivi de tout. Je suis sûr que l’utilisation de Discourse pour cela serait la méthode préférée, mais puis-je suggérer peut-être un site Hugo ou un site Jekyll et avoir les documents sous forme de fichiers dans un dépôt GitHub où n’importe qui peut soumettre des PR. Si aucun de ces deux ne vous convient, il existe de nombreux autres systèmes de documentation pour dépôts GitHub disponibles dans diverses variantes.
Oh, la gestion des versions fonctionne plutôt bien sur Discourse, même très bien. Et si vous combinez cela avec la sécurité d’accès par catégorie, vous obtenez quelque chose dont nous sommes fiers d’utiliser
À titre indicatif, je travaille progressivement à la mise en ordre de #howto:sysadmin, en vérifiant que chaque article est à jour et pertinent, puis en les faisant basculer vers auto-delete-posts-after. Il semble que la plupart d’entre eux aient été catégorisés ici sous « configuration avancée ».
Tout à fait d’accord. Le multisite est une configuration super super avancée et ce n’est pas quelque chose que nous prenons beaucoup en charge sur Meta.
C’est exact. Discourse + le plugin Docs + quelques personnalisations supplémentaires. Utiliser Discourse est notre préférence pour cela, mais je vois aussi les avantages d’utiliser un wiki ou un site SSG.
Ce serait formidable si les sujets « moins pris en charge » pouvaient être regroupés dans une catégorie clairement identifiée.
Il semble y avoir une mentalité actuelle selon laquelle, si quelque chose est écrit ici, un certain niveau de support est dû.
Cela faciliterait également la promotion du test préalable à la mise à niveau par les utilisateurs, car ces fonctionnalités sont généralement plus fragiles ou moins largement testées entre les versions.
Je pense que le multisite est assez bien « pris en charge », mais il est attendu que si vous vous engagez dans cette voie, vous sachiez que cela exige davantage de votre part (par exemple, vous devez réfléchir à ce que signifie rebuild app dans différents contextes). Je dirais que c’est « avancé », mais pas « super super avancé ».
Je suis d’accord pour dire que les catégories tertiaires et les sous-dossiers sont « super super avancés ».
Peut-être que je pense davantage aux sites multiples avec Let’s Encrypt, qui a répétitivement échoué au fil des ans, et dont la documentation mise à jour a parfois mis des semaines ou des mois à paraître.
Ah, oui. Je pense que c’est probablement assez stable maintenant (je crois que le dernier changement concernait la façon dont les redirections étaient gérées dans nginx), et j’ai un article sur Multisite Configuration with Let's Encrypt and no reverse proxy - Documentation - Literate Computing Support que je compte publier ici Très Prochainement (je l’ai écrit et testé pour la dernière fois le 2 décembre 2020). Cependant, le multisite est définitivement du « débrouillez-vous seul ». Je ne pense pas que cela ait même un sens, sauf si vous avez au moins 3 (peut-être 10 ?) sites, car il semble que la plupart des gens qui pensent en avoir besoin essaient de fonctionner sur un seul droplet de 1 Go.
Ce qui me serait le plus utile, c’est que vous ne consacreriez pas plus d’efforts à structurer la catégorie (tutoriels) en tant que telle, mais plutôt à offrir une meilleure structure à la Documentation.
J’apprécie vraiment que le forum reste fluide pour que les utilisateurs puissent poster. Je pense que pour cela, il est essentiel d’avoir de bonnes catégories de premier niveau et que les utilisateurs publient dans la bonne. Mais lorsque les sous-catégories deviennent complexes, lorsque les utilisateurs doivent impérativement poster dans la bonne sous-catégorie ou savoir dans quelle sous-catégorie chercher des informations, je trouve cela quelque peu perturbateur.
Actuellement, vous faites pratiquement un simple miroir de la configuration du forum dans la documentation :
Pourquoi ne pas permettre au personnel d’utiliser des balises réservées au personnel pour organiser et structurer la documentation, comme ‘docs-getting-started’, ‘docs-setup’, en intégrant du contenu provenant de n’importe où sur le forum ? Ainsi, vous pourriez créer une page Documentation qui soit plus qu’un simple reflet du forum, avec une table des matières correctement organisée, par exemple :
Documentation
+Prise en main
+Installation
+Installation avancée
+Contribution
+Configuration
+Configuration avancée
C’est exactement l’idée ici, @manuel ! Nous prévoyons de mettre en place des moyens simples pour filtrer facilement ces types de tutoriels, tout en conservant les filtres déjà présents dans le plugin Docs. Organiser ces tutoriels avec des balises spécifiques est le premier pas à franchir.
ou peut-être que le groupe de configuration avancée pourrait inclure un avertissement, recherchez les métadonnées ! Par exemple, ce post est très utile 
) et 
.
