Aggiornamento su come sono organizzate le categorie su Meta

Come parte dell’aggiornamento del tema e della struttura di Meta, stiamo pianificando di apportare alcune modifiche all’organizzazione delle categorie qui.

Abbiamo esplorato alcune idee diverse finora e prevediamo che questo subirà ulteriori revisioni man mano che riceveremo feedback dalla comunità, ma l’idea verso cui siamo più orientati ora è illustrata di seguito:

L’idea di base è raggruppare le categorie correlate in un numero inferiore di categorie di primo livello, ognuna delle quali sarà presente nella barra laterale per i nuovi utenti per impostazione predefinita.

  • Notizie ed Eventi
  • Supporto
  • Successo della Comunità
  • Contribuisci
  • Personalizzazione
  • Documentazione
  • Wiki della Comunità
  • Marketplace

Prevediamo che Supporto continuerà ad essere una delle categorie più attive e pensiamo che raggruppare altre categorie relative al supporto sotto di essa possa ridurre la paralisi decisionale. Ci sono probabilmente ulteriori perfezionamenti da apportare qui (SSO dovrebbe essere una categoria o un tag? qual è la differenza in pratica tra Installazione e Hosting? dovrebbero essere compressi in un’unica sottocategoria Self Hosting?) Lavoreremo su queste domande man mano, ma la forma generale è avere tutti gli argomenti di supporto in un unico posto.

Successo della Comunità è una categoria in cui vorremmo investire di più, basandoci sulla categoria Comunità esistente. La vediamo come un luogo in cui tutti coloro che sono coinvolti nella gestione di una comunità Discourse di successo possono supportarsi a vicenda, non con supporto tecnico, ma con le cose più difficili e sfumate necessarie per costruire una comunità di successo. Probabilmente rimodelleremo anche la struttura sottostante qui, ma per cominciare, pensiamo che le categorie Comunità e Dati e Reporting esistenti siano i pilastri principali qui.

Contribuisci è la categoria che immaginiamo essere il centro di discussione su come migliorare il prodotto stesso e questa comunità.

Personalizzazione sarebbe un luogo dove trovare tutti gli argomenti relativi all’estensione di Discourse con plugin, temi, componenti e altre estensioni.

Se desideri dare un’occhiata più da vicino, abbiamo questa struttura attualmente implementata su un sito di staging dove puoi dare un’occhiata.

come accedere al sito di staging
  1. Visita https://meta-redesign-2026.discourse.group/
  2. Inserisci questo utente e password per l’autenticazione HTTP di base
    • utente: meta2026bsbx
    • password: Q0U1ppbVbd2MVttuYOl+M8SYEOUqGLGjzl5sr1C9XwE=
  3. Inserisci la tua email/nome utente e password per meta
    (il sito di staging non supporta altri metodi di accesso).

Dopo aver avuto la possibilità di farlo, fateci sapere cosa ne pensate qui.

5 Mi Piace

Penso che avere una categoria chiamata qualcosa come self-hosting potrebbe aiutare a chiarire cosa ci va. Non è ancora un nome eccezionale, ma è meglio di Installation, che implica che discourse non abbia mai funzionato; ero piuttosto confuso la prima volta che uno dei miei argomenti è stato spostato lì. Forse “back-end” potrebbe funzionare?

Se si accede a una shell per causare o assistere al proprio problema, va lì. Se discourse “funziona” e riguarda ux o temi o qualsiasi altra cosa, va su supporto.

7 Mi Piace

Sono favorevole.

Andrei oltre e direi che dovremmo combinare Installation e Installation > Hosting in questa nuova categoria Self-Hosting.

Penso che potremmo farlo indipendentemente da come si svilupperà il resto. Se andiamo nella direzione che ho delineato sopra, questa nuova categoria sarebbe una sottocategoria di Support.

Se ci atteniamo più da vicino al modello piatto attuale, sarebbe una categoria di primo livello.

4 Mi Piace

Ho appena apportato la seguente modifica, che ha portato a una nuova categoria di primo livello #self-hosting-support (supporto all’auto-ospitazione):

  • Tutti gli argomenti precedentemente in Installation > Hosting sono stati contrassegnati con hosting
  • Tutti gli argomenti da Installation > Hosting sono stati uniti a quello che era Installation
  • Installation è stato rinominato in Self-hosting support

Forse “Self-hosting” (Auto-ospitazione) è meglio di “Self-hosting support” (Supporto all’auto-ospitazione) (specialmente se lo spostiamo sotto Support), ma come primo passo per ora, ho optato per qualcosa di un po’ più verboso, che contenga la parola “support”.

3 Mi Piace

Per quanto ne so, in precedenza evitavo “supporto self-hosting” perché dava l’impressione che fosse l’area specifica per gli utenti self-hoster per ottenere tutto il loro supporto e non volevo che fosse la prima impressione.

È anche molto simile alla categoria documentazione e non si vuole una duplicazione se si cerca di semplificare.

Anche configurazione è stata scartata poiché tutte le funzionalità/impostazioni/plugin/ecc. necessitano di essere “configurate”, quindi non era abbastanza descrittiva. Amministrazione di sistema è stata considerata troppo tecnica (quando volevamo minimizzare quanto fosse tecnico essere per gestire un sito Discourse).

Anche se sono d’accordo che installazione fosse ambigua, non ha causato molta confusione nella pratica. Tuttavia, esiste un nome migliore… :slight_smile:

Per Hosting, quella era l’area per discutere i servizi sottostanti (Digital Ocean, Mailgun, ecc., ecc.). Penso che avesse un sapore distinto che era diverso dall’amministrazione del server, e con oltre 500 argomenti sarebbe stato fattibile dividere una conversazione (se non fosse già esistita :slight_smile:)

8 Mi Piace

Per me, questo è ciò che mi aspetterei:

  • hosting: riguarda la scelta e la gestione dell’host (server)
  • Installazione: arrivare a «Discourse esiste e posso accedere come amministratore e fare cose»
  • configurazione: tutti i dettagli riguardanti le varie impostazioni

Penso che per chi è alle prime armi, la distinzione tra il core e i «plugin inclusi» non sia molto ovvia. Quindi li includerei nella configurazione, o almeno fornirei indicazioni molto chiare.

3 Mi Piace

Quali di questi ti aspetteresti che siano categorie diverse rispetto a tag diversi?

E come ti aspetteresti che si relazionino alla categoria Support?

2 Mi Piace

Quindi, penso che sarei d’accordo con l’installazione e l’hosting come tag. Ma mi chiedo (anche per la mia community) se ci sia un modo per “fissare” o “proporre” alcuni tag chiave in una categoria. Potrebbero anche essere categorie (se pensiamo alla linea di “raccontare la storia”).

Configurazione: questo sarà molto diverso per chi usa l’auto-hosting o per gli amministratori che usano l’hosting? Ho l’impressione che si sovrapporrà, quindi non sono sicuro di volerlo bloccare all’interno di Self-hosting (che rinominerei piuttosto che Self-hosting support). Forse Support è più simile a “Supporto generale”? Perché quasi tutto in Meta è in qualche modo supporto, non è vero?

A proposito: Migration mi confonde, perché come persona che mette le persone al primo posto penso immediatamente “oh, come gestisco la migrazione nel suo complesso”, e quando guardo la categoria, sembra essere tutta “migrazione tecnica”, script ed esportazioni e roba del genere.

Di recente abbiamo avuto alcune discussioni su facebook-migration che riguardano più la strategia, le persone e le sfide specifiche. In un certo senso, sento che Migration possa agire come un attrattore malvagio per le persone preoccupate per gli aspetti più generali o umani della migrazione. Capisci cosa intendo?

2 Mi Piace

Avere una maggiore possibilità di farlo nell’app è qualcosa che potrebbe valere la pena esplorare, ma non sono sicuro di come dovrebbe funzionare.

Al momento, penso che questo accada in modo molto organico: una massa critica di certi tag si accumula in una data categoria, e le persone iniziano a vedere lo schema e incoraggiano la sua fioritura.

Ci sono funzionalità integrate per limitare i tag a determinate categorie, o richiedere un numero di tag in una data categoria, in particolare da un dato gruppo di tag, ma sento che possono essere spesso troppo onerose.

:+1: d’accordo. Penso alla configurazione come più “supporto generale” (a meno che non si tratti di configurare cose a livello di sysadmin, come la porta su cui si è in ascolto, ecc.).

Sì, è quello che avevo pensato inizialmente anch’io… Lo lascerò sedimentare per un giorno, ma rivedrò questo dettaglio domani.

Lo è, ma non sono sicuro di quanto aiuti quella parola in più. Capisco cosa intendi, però.

Sì, è possibile che ci siano due categorie nascoste qui. Se guardassimo questo attraverso la lente della struttura nidificata proposta, forse questo dovrebbe essere suddiviso in qualcosa di più simile a support/migration, e qualcosa di più simile a dev/migration.

Potrei vederci modellare questo ulteriormente nel tempo, facendo prima una mossa più piccola qui.

Capisco cosa intendi, anche se il fatto che siano nascosti in un menu a discesa li rende molto meno visibili delle sottocategorie, che si possono visualizzare in modo prominente.

Ti risponderò su questo, perché è una cosa che ho intenzione di usare in modo piuttosto estensivo :sweat_smile: (richiedere almeno un tag da un dato gruppo di tag in una data categoria) per evitare la moltiplicazione delle sottocategorie…

Penso che una parte lo sia, ma un’altra parte è la continuazione dell’“installazione”, tutto il lavoro di configurazione. Bene, ora ho installato Discourse, ha tutte queste funzionalità incredibilmente interessanti, ho il controllo su così tante cose, ma come lo “modello” in base alle esigenze della mia community? Questa parte mi ha scoraggiato moltissimo tempo fa, perché anche se tutte le impostazioni e le cose sono documentate, ho avuto difficoltà a) a capire da dove iniziare e b) a capire come tradurre la mia “visione” per la mia community in impostazioni e configurazione.

Quindi forse quello che sto pensando è un livello aggiuntivo attorno al percorso della configurazione iniziale. Vedo Support (non lo rinominerei “Supporto generale”, lo stavo dicendo per indicare come lo percepivo) più per “Sono operativo, o ho un problema specifico che devo risolvere” piuttosto che “Ho la mia installazione appena tolta dalla scatola e ora cosa devo fare per prepararla per un qualche tipo di lancio”.

Tutto questo per dire che in realtà penso che la “configurazione” abbia senso come parte del percorso di amministrazione e che non sia esattamente la stessa cosa del “supporto”.

Un parallelo con la mia community – mi ricorda che devo dare qualche notizia a riguardo nella conversazione appropriata – è il seguente: considerando il proprietario di un gatto diabetico che ha appena ricevuto una diagnosi e si unisce alla nostra community, come organizziamo le categorie? Quello che ho deciso ora è essere molto “incentrato sui membri” e iniziare con “Sono appena arrivato, che diavolo faccio” (un equivalente francese più educato), poi “Sto prendendo l’attrezzatura di cui ho bisogno”, “Sto imparando” – e poi sono pronti per il vero “supporto” che è il cuore della community.

Se penso in questi termini con Discourse, come qualcuno che è completamente nuovo a tutto come lo ero io, ci sono sicuramente: 1) capire se ospiterò io stesso o meno e scegliere l’hosting; 2) passare attraverso l’installazione vera e propria 3) progettare la mia community e tradurla nella configurazione di Discourse. E in quel caso c’è una distinzione da fare tra a) sto costruendo da zero e b) la community esiste e voglio migrarla – come discusso nel mio argomento sfide di migrazione da Facebook penso davvero che cambi l’approccio alla configurazione.

Il che ci porta a dove mettere le cose relative alla migrazione.

Direi che di nuovo, dipende da quale storia vogliamo raccontare. Discourse vuole incoraggiare e facilitare la migrazione di community esistenti su Discourse, o l’attenzione è più rivolta alle persone che costruiranno da zero con Discourse?

Nessuna sorpresa, direi che ha senso concentrarsi sulla migrazione dei clienti, perché sono persuaso che ci sia un enorme mercato inutilizzato lì.

In tal caso, vorrei che “Migrazione” non fosse sepolta troppo in profondità. Personalmente la manterrei come un aspetto della Gestione della Community (e rinominerei la categoria Community attuale, perché “Community” da solo è ambiguo, inizialmente pensavo fosse “per la community di Discourse” piuttosto che “sulla progettazione/costruzione/gestione di community”). Tag o sottocategoria? Potrebbe almeno meritare una sottocategoria. Gli script di migrazione e le cose tecniche relative alla migrazione andrebbero in una categoria di primo livello diversa?

O Forse Migrazione è una categoria a sé stante, che contiene discussioni su come si adattano e traducono gli aspetti esistenti della community in Discourse, come affrontare il processo effettivo di migrazione (implementazione), e anche la “migrazione dei dati”.

1 Mi Piace

Aspetta. E se ci fosse un modo per incoraggiare gli utenti a taggare gli argomenti con #standard-install come facciamo con unsupported-install?

Tuttavia, non sono sicuro di come realizzarlo.

2 Mi Piace

Nella proposta attuale, immaginiamo che “Successo della Community” sia la categoria di livello superiore con “Gestione della Community” come sottocategoria di quella: come si allinea questo con il tuo pensiero qui?


Mi piace l’idea di avere una qualche indicazione definita attorno alla nostra comprensione di quali potrebbero essere i passaggi tipici del percorso…

1 Mi Piace

Non capisco la distinzione tra i due. Cosa andrebbe in Successo della Community che non va in Gestione della Community? Se penso alle cose che ho pubblicato finora in Community qui, le metto in gestione della community o successo?

Dovrò pensarci domani o venerdì, il cervello oggi si sta spegnendo, scusate!

1 Mi Piace

Beh, a parte le sottocategorie che vedi nella bozza, hai menzionato altre due attività qui oltre al gestire le community (progettarle e costruirle):

Ma forse tutto questo rientra ancora nella “gestione” per la maggior parte delle persone.

clicca per andare

staging site con un clic comprese le credenziali

→ Nascosto nel caso non si vogliano far andare i robot lì.

Ecco la mia riorganizzazione delle categorie:

  • Notizie ed Eventi
    • Annunci
    • Blog
    • Riassunti
  • Community
    • Agorà (precedentemente: generale)
    • Feedback sul Sito
    • Lodi
    • Confronto
    • Gestione della Community
    • Marketplace
    • Wiki Utente
    • Wiki Admin
    • Wiki Dev
    • Wiki Sysadmin
  • Documentazione
    • Usare Discourse
    • Gestione del Sito
    • Integrazioni
    • Hosting di Discourse (precedentemente: Clienti Ospitati)
    • Self-Hosting
    • Migrazione a Discourse
    • Guide per Sviluppatori
    • Contribuire
  • Aiuto
    • Installazione
    • Hosting
    • Migrazione
  • Integrare
    • WordPress
    • SSO
  • Contribuire
    • Bug
    • Funzionalità
    • Dev
    • Traduzioni
    • UX
  • Personalizzare
    • Plugin
    • Extra
    • Tema
    • Componente Tema
    • Dati e Reportistica

Motivazione:

  • Community sarebbe il luogo vivace per discussioni relative a qualsiasi cosa non trattata altrove, riunendo la più ampia community di Discourse, incluse wiki, discussioni generali (#agora), feedback sul sito, lodi e confronti con altri software, ma anche discussioni sulla gestione della community e sul marketplace.
  • #news-events sarebbe per la normale comunicazione CDCK
  • #help sarebbe per ottenere supporto
  • #integrate sarebbe per discutere integrazioni specifiche
  • Documentation ospiterebbe la knowledge base ufficiale
  • #contribute ospiterebbe tutto il processo di sviluppo
  • #customize ospiterebbe tutto ciò che rende ogni istanza di Discourse una community speciale, inclusa la reportistica e l’esplorazione dei dati.

Quando arriva qualcuno di nuovo, andrebbe alla documentazione (ufficiale) o alle discussioni della community…

Suggerirei un tag #welcome che punti a una manciata di argomenti introduttivi per navigare facilmente e inserire i nuovi arrivati, ad esempio per passare da tl0 a tl1, cogliendo l’atmosfera e le aree.

Probabilmente la documentazione dovrebbe avere un inizio prominente con i tag del Sistema di Documentazione: tutorial, explanation, how-to, reference.

Community Management potrebbe essere chiamato Community Building invece… Non mi piace “Community Success” per qualche ragione poco chiara.

3 Mi Piace

Sì, l’ho già fatto prima su una community e penso anch’io che sia un modo piacevole e flessibile per indicare un percorso di onboarding, oltre a usare qualsiasi categoria. Qualcosa come
image

4 Mi Piace

Applaudo questa iniziativa e apprezzo il coinvolgimento nel processo.

Avendo seguito il percorso di Discourse di @stephtara, mi è ovvio che Meta ha bisogno di un luogo dedicato per i nuovi costruttori di comunità. Non ho idea di come chiamarlo, ma un luogo caldo e accogliente per coloro che costruiscono con Discourse per la prima volta aiuterebbe a superare il sovraccarico di opzioni di configurazione. Le persone che offrono aiuto qui saprebbero che potrebbe essere necessario uno sforzo e una pazienza extra nel rispondere con aiuto in quest’area.

Forse mi è sfuggito, ma una categoria di documentazione sulle Opzioni di Configurazione con un indice che rispecchi l’area di amministrazione “attuale” sarebbe fantastica. Discourse è in continua evoluzione. La documentazione dovrebbe fare lo stesso rimanendo al passo.

Oltre a questa revisione delle categorie/tag, spero che seguirà una “nuova sistemazione” degli argomenti esistenti con la riorganizzazione. La maggior parte del mio tempo su Meta alla ricerca di risposte è speso cercando di capire quali informazioni sono pertinenti allo stato attuale di Discourse e quali sono vecchie e non applicabili. Confesso che il mio BBS è parte del problema, ma molti dei documenti sono molto difficili da sistemare. Apprezzo il lavoro che lo staff ha fatto e sta ancora facendo per migliorare la documentazione, ma molti/la maggior parte sembrano averne bisogno.
A tal fine, suggerisco di etichettare la maggior parte dei documenti o degli argomenti che sembrano essere documenti con un tag “Needs Review” (Necessita di revisione). Sì, sarebbe una quantità enorme di tag, ma una volta completato il processo di revisione, l’esperienza utente migliorerebbe enormemente. Io e forse altri saremmo disposti ad aiutare in questo sforzo. Una sequenza di modifica e tagging potrebbe aiutare a gestire il processo.

Lo sto usando su un sito:

Riepilogo

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

Forse un tag “Out of Date” (Obsoleto) sarebbe utile.

@mcwumbly Grazie ancora per aver avviato questa riorganizzazione e per averci incluso nel processo. :clap:

6 Mi Piace

Ecco il mio piano per i prossimi passi:

  • Settimana del 23 febbraio
    • Aggiornare l’organizzazione delle categorie qui per farla corrispondere a quella nel primo post, magari prendendosi qualche piccola libertà in base al feedback ricevuto finora
    • Aspettarsi molti altri feedback di discussione su come ci si sente nella pratica
    • Apportare alcune piccole modifiche in base al feedback
  • Settimana del 2 marzo
    • Continuare a perfezionare se le cose stanno andando generalmente bene. OPPURE
    • Tornare indietro se le cose sembrano molto sbagliate
5 Mi Piace

Metto qui questa idea:

Probabilmente merita un argomento tutto suo, ma possiamo discuterne prima qui come parte di questo rimescolamento più ampio.

3 Mi Piace

Ho provveduto ad apportare una prima serie di modifiche qui in modo da poter iniziare ad avere un’idea di come ci si senta insieme nella pratica.

Ho anche aggiornato le categorie predefinite della barra laterale, ma non le ho applicate a tutti, quindi se vuoi provare a impostare la tua barra laterale sui nuovi valori predefiniti, puoi farlo così:

  1. Fai clic sulla matita di modifica accanto a “Categorie” nella barra laterale
  2. Scegli “Ripristina valori predefiniti” nell’angolo in basso a destra della finestra modale
  3. Regola come desiderato
  4. Fai clic su “:Salva modifiche”

Per favore, condividi qualsiasi feedback tu abbia qui durante la prossima settimana circa:

2 Mi Piace