Mise à jour de l'organisation des catégories sur Meta

[mcwumbly (Dave McClure)]

Dans le cadre de la mise à jour du thème et de la structure de Meta, nous prévoyons d’apporter des modifications à l’organisation des catégories ici.

Nous avons exploré quelques idées différentes jusqu’à présent, et nous nous attendons à ce que cela fasse encore l’objet de révisions supplémentaires à mesure que nous recevrons les commentaires de la communauté, mais l’idée vers laquelle nous nous dirigeons maintenant est illustrée ci-dessous :

L’idée de base est de regrouper les catégories connexes dans un plus petit nombre de catégories de niveau supérieur, chacune d’entre elles étant visible dans la barre latérale pour les nouveaux utilisateurs par défaut.

• Actualités et événements
• Support
• Succès de la communauté
• Contribuer
• Personnalisation
• Documentation
• Wiki de la communauté
• Marketplace

Nous nous attendons à ce que le Support continue d’être l’une des catégories les plus actives, et nous pensons que regrouper d’autres catégories liées au support en dessous pourrait réduire la paralysie du choix. Il y a probablement d’autres améliorations à apporter à cet égard (SSO doit-il être une catégorie ou une étiquette ? Quelle est la différence en pratique entre Installation et Hébergement ? Ceux-ci devraient-ils être regroupés dans une seule sous-catégorie Auto-hébergement ?) Nous allons résoudre ces questions au fur et à mesure, mais la forme générale est d’avoir tous les sujets de support en un seul endroit.

Community Success (Succès de la communauté) est une catégorie dans laquelle nous aimerions investir davantage, en nous appuyant sur la catégorie Community (Communauté) existante. Nous considérons cela comme un endroit où toutes les personnes impliquées dans l’exécution d’une communauté Discourse réussie peuvent s’entraider, non pas avec un support technique, mais avec les aspects plus délicats de ce qu’il faut pour bâtir une communauté prospère. Nous allons probablement remanier la structure sous-jacente ici aussi, mais pour commencer, nous pensons que les catégories existantes Community et Data and Reporting (Données et Rapports) en sont les piliers principaux.

Contribute (Contribuer) est la catégorie que nous envisageons comme étant le centre de discussion sur la manière d’améliorer le produit lui-même, et cette communauté.

Customization (Personnalisation) serait un endroit pour trouver tous les sujets liés à l’extension de Discourse avec des plugins, des thèmes, des composants et d’autres extensions.

Si vous souhaitez examiner cela de plus près, nous avons cette structure actuellement en place sur un site de staging où vous pouvez regarder autour de vous.

comment accéder au site de staging

1. Visitez https://meta-redesign-2026.discourse.group/
2. Entrez cet utilisateur et ce mot de passe pour l’authentification HTTP de base
   • utilisateur : meta2026bsbx
   • mot de passe : Q0U1ppbVbd2MVttuYOl+M8SYEOUqGLGjzl5sr1C9XwE=
3. Entrez votre email/nom d’utilisateur et votre mot de passe pour meta
   (le site de staging ne prend en charge aucune autre méthode de connexion).

Après avoir eu l’occasion de le faire, veuillez nous faire savoir ce que vous en pensez ici.

[pfaffman (Jay Pfaffman)]

Je pense qu’une catégorie appelée quelque chose comme auto-hébergement pourrait aider à clarifier ce qui y va. Ce n’est toujours pas un excellent nom, mais c’est mieux que Installation, qui implique que Discourse n’a jamais fonctionné ; j’étais assez confus la première fois qu’un de mes sujets y a été déplacé. Peut-être que « back-end » fonctionnerait ?

Si vous accédez à un shell pour provoquer ou constater votre problème, cela va là-bas. Si Discourse « fonctionne » et que cela concerne l’expérience utilisateur ou les thèmes ou toute autre chose, cela va au support.

[mcwumbly (Dave McClure)]

@pfaffman

Je pense qu’avoir une catégorie appelée quelque chose comme auto-hébergement pourrait aider à clarifier ce qui y va. Ce n’est toujours pas un excellent nom, mais c’est mieux que Installation,

Je suis favorable.

J’irais plus loin et je dirais que nous devrions combiner Installation et Installation > Hosting dans cette nouvelle catégorie Auto-hébergement.

Je pense que nous pourrions le faire quelle que soit la manière dont le reste se présente. Si nous allons dans la direction que j’ai esquissée ci-dessus, cette nouvelle catégorie serait une sous-catégorie de Support.

Si nous nous en tenons de plus près au modèle plat actuel, ce serait une catégorie de niveau supérieur.

[mcwumbly (Dave McClure)]

Je viens d’apporter la modification suivante, ce qui a entraîné une nouvelle catégorie de premier niveau Self-hosting support :

• Étiqueté tous les sujets précédemment dans Installation > Hébergement avec hosting
• Fusionné tous les sujets de Installation > Hébergement avec ce qui était auparavant Installation
• Renommé Installation en Self-hosting support

Peut-être que « Auto-hébergement » est meilleur que « Support de l’auto-hébergement » (surtout si nous le déplaçons sous Support), mais comme première étape pour l’instant, j’ai opté pour quelque chose d’un peu plus verbeux, qui contient le mot « support ».

[JammyDodger]

Pour information, j’ai évité « support auto-hébergement » précédemment car cela donnait l’impression que c’était la zone spécifiquement destinée aux auto-hébergeurs pour obtenir tout leur support et je ne voulais pas que ce soit la première impression.

C’est aussi très similaire à la catégorie documentation, et vous ne voulez pas vraiment de duplication si vous cherchez à simplifier.

Configuration a également été écarté car toutes les fonctionnalités/paramètres/plugins/etc nécessitent une « configuration », donc ce n’était pas assez descriptif. Administration système a été considéré comme trop technique (alors que nous voulions minimiser à quel point il faut être technique pour faire fonctionner un site Discourse).

Bien que je sois d’accord sur le fait que installation était ambigu, cela n’a pas causé autant de confusion en pratique. Un meilleur nom existe cependant…

Pour Hébergement, c’était la zone pour discuter des services sous-jacents (Digital Ocean, Mailgun, etc., etc.). Je pense qu’il avait une saveur distincte qui était différente de l’administration de serveur, et avec plus de 500 sujets, il serait viable qu’une conversation soit séparée (si ce n’était pas déjà le cas )

[stephtara (Stephanie Booth)]

Pour moi, voici ce à quoi je m’attendrais :

• hébergement : concernant le choix et la gestion de l’hôte (serveur)
• Installation : arriver à « Discourse existe et je peux me connecter en tant qu’administrateur et faire des choses »
• configuration : tous les détails concernant les divers réglages

Je pense que pour quelqu’un qui débute, la distinction entre le cœur et les « plugins inclus » n’est pas très évidente. Je les inclurais donc dans la configuration — ou du moins avec des indications très claires.

[mcwumbly (Dave McClure)]

@stephtara

Pour moi, voici ce à quoi je m’attendrais :

• hébergement : concerne le choix et la gestion de l’hôte (serveur)
• Installation : arriver à « discourse existe et je peux me connecter en tant qu’administrateur et faire des choses »
• configuration : tous les détails concernant les différents paramètres

Lequel de ceux-ci vous attendriez-vous à voir comme catégories différentes par rapport à des étiquettes différentes ?

Et comment vous attendriez-vous à ce qu’ils se rapportent à la catégorie Support ?

[stephtara (Stephanie Booth)]

@mcwumbly

Lesquels de ceux-ci vous attendriez-vous à ce qu’ils soient des catégories différentes par rapport à des étiquettes différentes ?

Donc, je pense que l’installation et l’hébergement me conviendraient en tant qu’étiquettes. Mais je me demande (pour ma communauté aussi) s’il existe un moyen d’« épingler » ou de « mettre en avant » certaines étiquettes clés dans une catégorie. Elles pourraient aussi être des catégories (si nous pensons dans le sens de « raconter l’histoire »).

Configuration : cela sera-t-il très différent pour les auto-hébergeurs ou les administrateurs hébergés ? J’ai l’impression que cela se chevauchera, donc je ne suis pas sûr de vouloir l’enfermer dans l’auto-hébergement (que je renommerais plutôt que Support auto-hébergement). Peut-être que Support ressemble davantage à un « Support général » ? Parce que presque tout dans Meta est un support d’une certaine manière, n’est-ce pas ?

D’ailleurs : Migration est déroutant pour moi, car en tant que personne qui privilégie les gens, je pense immédiatement « oh, comment gérer la migration dans son ensemble », et quand je regarde la catégorie, il semble que ce soit uniquement de la « migration technique », des scripts et des exportations et tout le reste.

Nous avons récemment eu des discussions sur facebook-migration, qui portent davantage sur la stratégie, les personnes et les défis spécifiques. D’une certaine manière, j’ai l’impression que Migration peut agir comme un aimant maléfique pour les personnes préoccupées par les aspects plus généraux ou humains de la migration. Vous voyez ce que je veux dire ?

[mcwumbly (Dave McClure)]

@stephtara

Je me demande (pour ma communauté aussi) s’il existe un moyen de « épingler » ou de « mettre en avant » certaines balises clés dans une catégorie. Il pourrait également s’agir de catégories (si nous pensons dans le sens de « raconter l’histoire »).

Avoir une plus grande possibilité de le faire dans l’application est quelque chose qui mérite d’être exploré, mais je ne suis pas sûr de la manière dont cela devrait fonctionner.

Actuellement, je pense que cela se produit de manière très organique : une masse critique de certaines balises s’accumule dans une catégorie donnée, et les gens commencent à voir le modèle et encouragent son épanouissement.

Il existe des fonctionnalités intégrées pour restreindre les balises à certaines catégories, ou pour exiger un nombre de balises dans une catégorie donnée, en particulier à partir d’un groupe de balises donné, mais j’ai l’impression qu’elles peuvent souvent être trop contraignantes.

@stephtara

Configuration : est-ce que cela va être très différent pour les auto-hébergeurs ou les administrateurs hébergés ? J’ai l’impression que cela va se chevaucher, donc je ne suis pas sûr de vouloir l’enfermer dans l’auto-hébergement

d’accord. Je considère la configuration comme davantage un « support général » (sauf s’il s’agit de configurer des choses au niveau de l’administrateur système, comme le port sur lequel vous écoutez, etc.).

@stephtara

Auto-hébergement (que je renommerais plutôt que Support de l’auto-hébergement

Oui, c’est ce que j’avais d’abord en tête… Je vais laisser reposer une journée, mais je réexaminerai ce détail demain.

@stephtara

Peut-être que Support ressemble davantage à « Support général » ? Parce que presque tout dans Meta est un support d’une certaine manière, n’est-ce pas ?

C’est le cas, mais je ne suis pas sûr à quel point ce mot supplémentaire aide. Je comprends ce que vous voulez dire, cependant.

@stephtara

Migration me trouble, car en tant que personne « axée sur les gens », je pense immédiatement « oh, comment gérer la migration dans son ensemble », et quand je regarde la catégorie, il semble que ce soit tout sur la « migration technique », les scripts et les exportations et tout le reste.

Oui, il est possible que deux catégories se cachent ici. Si nous examinions cela à travers le prisme de la structure imbriquée proposée, cela pourrait peut-être être divisé en quelque chose de plus proche de support/migration, et quelque chose de plus proche de dev/migration.

Je pourrais imaginer que nous façonnions cela davantage avec le temps, tout en faisant un premier pas plus petit ici.

[stephtara (Stephanie Booth)]

@mcwumbly

En ce moment, je pense que cela se produit de manière très organique – une masse critique de certaines étiquettes s’accumule dans une catégorie donnée, et les gens commencent à voir le modèle et encouragent son épanouissement.

Je vois ce que vous voulez dire – bien que le fait qu’elles soient cachées dans un menu déroulant les rende beaucoup moins visibles que les sous-catégories, que l’on peut afficher bien en évidence.

@mcwumbly

Il existe des fonctionnalités intégrées pour restreindre les étiquettes à certaines catégories, ou exiger un nombre d’étiquettes dans une catégorie donnée, en particulier à partir d’un groupe d’étiquettes donné, mais j’ai l’impression qu’elles sont souvent trop contraignantes.

Je reviendrai vers vous à ce sujet, car c’est une chose que je prévois d’utiliser de manière assez intensive (exiger au moins une étiquette d’un groupe d’étiquettes donné dans une catégorie donnée) pour éviter la multiplication des sous-catégories…

@mcwumbly

Je considère la configuration davantage comme un « support général »

Je pense qu’une partie l’est, mais une autre partie est la continuation de « l’installation », tout le travail de configuration. Maintenant que j’ai installé Discourse, il dispose de toutes ces fonctionnalités incroyablement intéressantes, j’ai le contrôle sur tellement de choses, mais comment puis-je le « modeler » en fonction des besoins de ma communauté ? Cette partie m’a extrêmement découragé il y a quelque temps, car bien que tous les paramètres et autres soient documentés, j’ai eu du mal a) à comprendre par où commencer et b) à comprendre comment traduire ma « vision » pour ma communauté en paramètres et en configuration.

Donc, peut-être que ce que j’envisage est une couche supplémentaire autour du parcours de configuration initiale. Je vois Support (je ne le renommerais pas « Support général », je disais cela pour indiquer comment je le percevais) davantage pour « Je suis opérationnel, ou j’ai un problème spécifique que je dois résoudre » plutôt que « J’ai mon installation standard et maintenant qu’est-ce que je dois faire pour la préparer à une sorte de lancement ».

Tout cela pour dire que je pense en fait que la « configuration » a du sens dans le parcours d’administration et que ce n’est pas exactement la même chose que le « support ».

Un parallèle avec ma communauté – cela me rappelle que je dois donner des nouvelles à ce sujet dans la conversation appropriée – est le suivant : considérons le propriétaire d’un chat diabétique qui vient de recevoir un diagnostic et rejoint notre communauté, comment organisons-nous les catégories ? Ce que j’ai décidé maintenant, c’est d’être très « centré sur le membre » et de commencer par « Je viens d’arriver, quoi faire ? » (un équivalent français plus poli), puis « Je me procure l’équipement dont j’ai besoin », « J’apprends » – et ensuite ils sont prêts pour le « support » proprement dit qui est le cœur de la communauté.

Si je réfléchis dans ce sens avec Discourse, en tant que quelqu’un qui est complètement nouveau dans tout cela comme je l’étais, il y a certainement : 1) déterminer si je vais l’auto-héberger ou non et choisir mon hébergement ; 2) passer par l’installation réelle 3) concevoir ma communauté et traduire cela en configuration Discourse. Et dans ce cas, il y a une distinction à faire entre a) je construis à partir de zéro et b) la communauté existe et je veux la migrer – comme discuté dans mon sujet défis de migration depuis Facebook je pense vraiment que cela change l’approche de la configuration.

Ce qui nous amène à l’endroit où placer les choses relatives à la migration.

@mcwumbly

Oui, il est possible que deux catégories se cachent ici. Si nous examinions cela à travers le prisme de la structure imbriquée proposée, peut-être que cela devrait être divisé en quelque chose de plus proche de support/migration, et quelque chose de plus proche de dev/migration.

Je dirais que là encore, cela dépend de l’histoire que nous voulons raconter. Est-ce que Discourse veut encourager et faciliter la migration des communautés existantes vers Discourse, ou l’accent est-il davantage mis sur les personnes qui vont construire à partir de zéro avec Discourse ?

Pas de surprise, je dirais qu’il est logique de se concentrer sur la migration des clients, car je suis persuadé qu’il existe un énorme marché inexploité dans ce domaine.

Dans ce cas, je voudrais que la « Migration » ne soit pas enfouie trop profondément. Personnellement, je la maintiendrais comme un aspect de la gestion de communauté (et je renommerais la catégorie Communauté actuelle en cela, car « Communauté » seul est ambigu, j’ai d’abord pensé que c’était « pour la communauté Discourse » plutôt que « sur la conception/construction/gestion de communautés »). Étiquette ou sous-catégorie ? Pourrait au moins mériter une sous-catégorie. Les scripts de migration et les aspects techniques liés à la migration iraient-ils dans une catégorie de niveau supérieur différente ?

Ou peut-être que la Migration est une catégorie en soi, qui contient des discussions sur la manière dont on adapte et traduit les aspects existants de la communauté en Discourse, sur la manière d’aborder le processus réel de migration (implémentation), et aussi la « migration des données ».

[pfaffman (Jay Pfaffman)]

Attendez. Et si nous pouvions encourager les utilisateurs à étiqueter les sujets avec #standard-install comme nous le faisons avec unsupported-install ?

Cependant, je ne suis pas sûr de la manière d’y parvenir.

[mcwumbly (Dave McClure)]

@stephtara

Personnellement, je le garderais comme un aspect de la gestion de communauté (et je renommerais la catégorie actuelle « Communauté » en conséquence, car « Communauté » seul est ambigu ; j’ai d’abord pensé que c’était « pour la communauté Discourse » plutôt que « sur la conception/construction/gestion de communautés »).

Dans la proposition actuelle, nous imaginons que « Succès de la communauté » est la catégorie de niveau supérieur avec « Gestion de communauté » comme sous-catégorie de celle-ci – comment cela s’aligne-t-il avec votre réflexion ici ?

@mcwumbly

---

@stephtara

ce à quoi je pense, c’est une couche supplémentaire autour du parcours de configuration initiale. Je vois Support (je ne la renommerais pas « Support général », je disais cela pour indiquer comment je la percevais) davantage pour « Je suis opérationnel, ou j’ai un problème spécifique à résoudre », plutôt que « J’ai mon installation prête à l’emploi et maintenant, que dois-je faire pour la préparer à une sorte de lancement ».

J’aime l’idée d’avoir une certaine signalisation définie autour de notre compréhension des étapes typiques que pourrait prendre le parcours…

[stephtara (Stephanie Booth)]

@mcwumbly

Dans la proposition actuelle, nous imaginons que « Succès de la Communauté » soit la catégorie de niveau supérieur avec « Gestion de la Communauté » comme sous-catégorie de celle-ci – comment cela s’aligne-t-il avec votre réflexion ici ?

Je ne saisis pas la distinction entre les deux. Qu’est-ce qui irait dans Succès de la Communauté qui n’irait pas dans Gestion de la Communauté ? Si je pense aux choses que j’ai publiées jusqu’à présent dans Community ici, dois-je les mettre dans gestion de la communauté ou succès ?

Je devrai y réfléchir demain ou vendredi, mon cerveau est en train de déconnecter pour aujourd’hui, désolé !

[mcwumbly (Dave McClure)]

@stephtara

Qu’est-ce qui irait dans Succès Communautaire et pas dans Gestion Communautaire ?

Eh bien, en plus des sous-catégories que vous voyez dans la maquette, vous avez mentionné deux autres activités ici en plus de gérer les communautés (les concevoir et les construire) :

@stephtara

plutôt que « à propos de la conception/construction/gestion des communautés »

Mais peut-être que tout cela relève toujours de la « gestion » pour la plupart des gens.

[hellekin]

@mcwumbly

comment accéder au site de staging

cliquer pour y aller

staging site en un clic y compris les identifiants

→ Masqué au cas où vous ne voudriez pas que les robots y accèdent.

Voici mon réaménagement des catégories :

• Actualités et événements
  • Annonces
  • Blog
  • Résumés
• Communauté
  • Agora (anciennement : général)
  • Commentaires sur le site
  • Louanges
  • Comparaison
  • Gestion de communauté
  • Marketplace
  • Wiki utilisateur
  • Wiki admin
  • Wiki développeur
  • Wiki administrateur système
• Documentation
  • Utiliser Discourse
  • Gestion du site
  • Intégrations
  • Hébergement Discourse (anciennement : Clients Hébergés)
  • Auto-hébergement
  • Migration vers Discourse
  • Guides du développeur
  • Contribution
• Aide
  • Installation
  • Hébergement
  • Migration
• Intégrer
  • WordPress
  • SSO
• Contribuer
  • Bug
  • Fonctionnalité
  • Dev
  • Traductions
  • UX
• Personnaliser
  • Plugin
  • Extras
  • Thème
  • Composant de thème
  • Données et rapports

Justification :

• #communauté serait l’endroit animé pour les discussions liées à tout ce qui n’est fait nulle part ailleurs, rassemblant la plus grande communauté Discourse, y compris les wikis, la discussion générale (#agora), les commentaires sur le site, les louanges et la comparaison avec d’autres logiciels, mais aussi la discussion sur la gestion de communauté et la marketplace.
• #actualités-événements serait pour la communication normale de CDCK
• #aide serait pour obtenir du support
• #intégrer serait pour discuter des intégrations spécifiques
• Documentation hébergerait la base de connaissances officielle
• #contribuer hébergerait tout le processus de développement
• #personnaliser hébergerait tout ce qui rend chaque instance Discourse une communauté spéciale, y compris les rapports et l’exploration de données.

Lorsqu’un nouvel utilisateur arrive, il se dirigera soit vers la documentation (officielle), soit vers les discussions de la communauté…

Je suggérerais une étiquette #bienvenue pointant vers une poignée de sujets d’introduction pour naviguer facilement et intégrer les nouveaux arrivants, par exemple, pour passer de tl0 à tl1, saisir l’ambiance et les domaines.

Probablement, la documentation devrait avoir un départ proéminent avec les balises du système de documentation : #tutoriel, #explication, #comment-faire, #référence.

La gestion de communauté pourrait être appelée Construction de communauté à la place… Je n’aime pas « Succès de la communauté » pour une raison peu claire.

[manuel (Manuel Kostka)]

@hellekin

Je suggérerais une étiquette #welcome pointant vers une poignée de sujets d’introduction pour naviguer facilement et intégrer les nouveaux arrivants, par exemple, pour passer de tl0 à tl1, saisir l’ambiance et les domaines.

Oui, je l’ai déjà fait sur une communauté et je pense aussi que c’est une manière agréable et flexible d’indiquer un parcours d’intégration, en plus d’utiliser n’importe quelle catégorie. Quelque chose comme

[philh]

J’applaudis cette initiative et j’apprécie que nous soyez impliqués dans le processus.

Ayant suivi le parcours Discourse de @stephtara, il est évident pour moi que Meta a besoin d’un endroit dédié aux nouveaux bâtisseurs de communauté. Je ne sais pas comment l’appeler, mais un endroit chaleureux et accueillant pour ceux qui construisent avec Discourse pour la première fois aiderait à surmonter la surcharge d’options de configuration. Les personnes offrant de l’aide ici sauraient qu’un effort supplémentaire et de la patience pourraient être nécessaires pour répondre avec de l’aide dans ce domaine.

Peut-être que je l’ai manqué, mais une catégorie de documentation sur les options de configuration avec un index qui reflète la zone d’administration « actuelle » serait géniale. Discourse évolue constamment. La documentation devrait faire de même en se tenant à jour.

En plus de cette refonte des catégories/balises, j’espère qu’un « nouveau tri » des sujets existants suivra la réorganisation. La majeure partie de mon temps passé sur Meta à chercher des réponses consiste à essayer de trier les informations qui sont pertinentes pour l’état actuel de Discourse et celles qui sont anciennes et non applicables. J’avoue que mon BBS fait partie du problème, mais de nombreuses documentations sont très difficiles à trier. J’apprécie le travail que le personnel a fait et continue de faire pour améliorer la documentation, mais beaucoup/la plupart semblent en avoir besoin.
À cette fin, je suggère d’étiqueter la plupart des documents ou sujets qui semblent être des documents avec une balise Needs Review (Nécessite un examen). Oui, cela représenterait une quantité énorme de balises, mais une fois que le processus d’examen serait terminé, l’expérience utilisateur serait considérablement améliorée. Moi et peut-être d’autres serions prêts à aider à cet effort. Une séquence d’édition et de balisage pourrait aider à gérer le processus.

J’utilise ceci sur un site :

Résumé

Needs-Review Needs-Text Needs-Citation Needs-Work Ready-to-Publish

Peut-être qu’une balise Out of Date (Obsolète) serait utile.

@mcwumbly Merci encore d’avoir lancé cette réorganisation et de nous avoir inclus dans le processus.

[mcwumbly (Dave McClure)]

Voici mon plan pour les prochaines étapes :

• Semaine du 23 février
  • Mettre à jour l’organisation des catégories ici pour correspondre à ce qui se trouve dans le premier message, en prenant peut-être quelques libertés mineures basées sur les commentaires reçus jusqu’à présent
  • Attendre beaucoup plus de commentaires de discussion ici sur la façon dont cela se passe en pratique
  • Apporter quelques ajustements mineurs basés sur les commentaires
• Semaine du 2 mars
  • Continuer à affiner si les choses semblent généralement bonnes. OU
  • Revenir en arrière si les choses semblent très décalées

[mcwumbly (Dave McClure)]

Je mets cette idée de côté ici :

@stephtara

Personnellement, je pense qu’il serait vraiment agréable d’avoir un espace « par langue », ou au moins une étiquette pour les traductions concernant une langue spécifique.

Cela mérite probablement son propre sujet, mais nous pouvons en discuter davantage ici d’abord dans le cadre de ce remaniement plus large.

[mcwumbly (Dave McClure)]

@mcwumbly

• Semaine du 23 février
  • Mettre à jour l’organisation des catégories ici pour qu’elle corresponde à ce qui se trouve dans le premier message, en prenant peut-être quelques petites libertés en fonction des commentaires reçus jusqu’à présent
  • Attendez-vous à beaucoup plus de commentaires de discussion ici sur ce que cela donne en pratique
  • Apporter quelques petits ajustements en fonction des commentaires

J’ai procédé à une première série de changements ici afin que nous puissions commencer à avoir une idée de ce que cela donne en pratique ensemble.

J’ai également mis à jour les catégories de la barre latérale par défaut, mais je ne les ai pas appliquées à tout le monde. Donc, si vous souhaitez essayer de définir votre barre latérale sur les nouveaux paramètres par défaut, vous pouvez le faire :

1. Cliquez sur le crayon d’édition à côté de « Catégories » dans votre barre latérale
2. Choisissez « Réinitialiser aux paramètres par défaut » dans le coin inférieur droit de la fenêtre modale
3. Ajustez comme vous le souhaitez
4. Cliquez sur « :Enregistrer les modifications »

Veuillez partager tous les commentaires que vous avez ici au cours de la semaine à venir environ :

@mcwumbly

• Semaine du 2 mars
  • Continuer à affiner si les choses se passent généralement bien. OU
  • Revenir en arrière si les choses semblent très décalées