Abbiamo un sacco di guide: a volte @dax o @jomaxro condividono una guida howto di cui non sapevo nemmeno dell’esistenza e rimango a bocca aperta!
Ho notato che la stessa cosa succede a molti nuovi utenti e community manager di Discourse qui su Meta. Per risolvere il problema, @justin ha avuto un’idea fantastica: raggruppare le nostre guide howto per offrire a tutti un punto di partenza migliore, con l’obiettivo di arrivare a qualcosa di simile a https://support.teams.discourse.com/docs
Haha sì, ce ne sono! Idealmente, se potessimo arrivare a 6-12 guide per categoria, sarebbe perfetto. Non intendiamo categorizzarle tutte, ma solo le migliori che le persone potrebbero cercare.
@osioke – un modo per affrontare la questione è cercare le guide più visualizzate che corrispondono a queste categorie e selezionare le 6-12 più viste da etichettare di conseguenza. Sarebbe un buon punto di partenza, combinato con i suggerimenti di @Benjamin_D qui!
La bellezza dei tag è che possiamo modificarli facilmente man mano che procediamo.
Grazie per aver condiviso questo, @Benjamin_D! Una delle cose con cui stavo faticando era come presentare e come pensare alla struttura; la tua tabella qui mi ha aiutato molto.
Ora sto cercando di espandere il raggruppamento da 3 a 6:
Per iniziare
Configurazione
Configurazione avanzata
Contributi
Configurazione
Configurazione avanzata
E, come ha condiviso @justin, guardando i più visualizzati, ho i primi 20:
Hmm, gli articoli sulla configurazione dell’accesso potrebbero probabilmente avere una categoria tutta loro, e sono un sottoinsieme di “Primi passi” perché sono tra le prime cose che si vogliono fare su un nuovo sito, se si desidera farlo.
Non sono sicuro che sia necessario menzionare il multisito qui , oppure forse il gruppo di configurazione avanzata potrebbe includere un avviso, cerca meta! Ad esempio, questo post è molto utile vantaggi-e-svantaggi-di-un-installazione-multisito.
Vero, vero, l’elenco si basa sui 20 più visualizzati, e l’ho condiviso per mostrare il mio ragionamento sull’organizzazione. In nessun modo è l’elenco finale, avrei dovuto essere un po’ più chiaro
Vorrei vedere “Amministrazione” o “Operazioni” come categorie per le attività amministrative e di moderazione in corso. Non rientrano nella configurazione/setup e non sono sviluppo/documentazione (contribuire).
Immagino che il sito di documentazione di Discourse for Teams utilizzi Discourse per tutti i documenti. Il problema con questo approccio per un sito di guide su Discourse, dove chiunque della comunità possa partecipare, è la gestione delle versioni e il tracciamento di tutto. Sono certo che l’uso di Discourse per questo scopo sarebbe il metodo preferito, ma posso suggerire di valutare un sito Hugo o un sito Jekyll, con i documenti come file in un repository GitHub a cui chiunque possa inviare pull request. Se nessuna di queste opzioni ti convince, esistono molti altri sistemi di documentazione basati su repository GitHub, disponibili in diverse varianti.
Oh, il versionamento funziona piuttosto bene su Discourse, anche molto bene. E se lo combini con la sicurezza degli accessi per categoria, ottieni qualcosa di cui siamo orgogliosi di usare
Solo per completezza, sto lavorando gradualmente alla pulizia di #howto:sysadmin, verificando che ogni articolo sia aggiornato e pertinente, per poi spostarli in auto-delete-posts-after. Sembra che la maggior parte di questi sia stata classificata qui come advanced config.
Sono pienamente d’accordo. Il multisito è una configurazione estremamente avanzata e non è qualcosa che supportiamo molto su Meta.
È proprio così. Discourse + il plugin Docs + alcune personalizzazioni aggiuntive. L’utilizzo di Discourse è la nostra preferenza in questo caso, ma vedo anche i vantaggi di utilizzare un sito wiki/SSG.
Sarebbe fantastico se gli argomenti “meno supportati” potessero finire nella loro categoria chiaramente indicata.
Sembra esserci un atteggiamento attuale secondo cui, se qualcosa è scritto qui, il supporto è in qualche modo dovuto.
Inoltre, rende più facile incoraggiare gli utenti a testare prima di aggiornare, poiché tali funzionalità sono solitamente più fragili o meno ampiamente testate tra le versioni.
Penso che il multisito sia piuttosto “supportato”, ma ci si aspetta che, se si intraprende questa strada, si sappia che sono richiesti maggiori sforzi (ad esempio, bisogna considerare cosa significhi rebuild app in vari contesti). Direi che è “avanzato”, ma non “super super avanzato”.
Concordo sul fatto che le categorie terziarie e le sottocartelle siano “super super avanzate”.
Forse sto pensando di più a un multisito con Let’s Encrypt, che si è rotto ripetutamente nel corso degli anni e talvolta la documentazione aggiornata ha richiesto settimane o mesi per essere pubblicata.
Ah, sì. Penso che ora sia probabilmente abbastanza stabile (credo che l’ultima modifica riguardasse il modo in cui nginx gestiva i reindirizzamenti), e ho un articolo su Multisite Configuration with Let's Encrypt and no reverse proxy - Documentation - Literate Computing Support che intendo pubblicare qui Prestissimo (lo avevo scritto e testato per l’ultima volta il 2 dicembre 2020). Tuttavia, il multisite è decisamente un’area in cui sei per lo più da solo. Non credo abbia senso a meno che tu non abbia almeno 3 (forse 10?) siti, dato che sembra che la maggior parte di coloro che pensano di volerlo stiano cercando di cavarsela con un singolo droplet da 1 GB.
Ciò che mi sarebbe più utile sarebbe non concentrarsi tanto sullo strutturare la categoria (how-to) in sé, quanto piuttosto dare una struttura migliore alla documentazione.
Apprezzo molto che il forum sia fluido per gli utenti che pubblicano. Penso che sia fondamentale avere categorie di primo livello ben definite e che gli utenti pubblichino in quella corretta. Tuttavia, quando le sottocategorie diventano complesse e diventa importante per gli utenti pubblicare nella sottocategoria giusta o cercare contenuti in quella specifica, trovo che ciò sia piuttosto disturbante.
Al momento, praticamente rifletti solo la struttura del forum nella documentazione:
Perché non far sì che lo staff utilizzi alcuni tag riservati allo staff per curare e strutturare la documentazione, come ‘docs-getting-started’, ‘docs-setup’, con contenuti provenienti da qualsiasi parte del forum? In questo modo potresti creare una pagina Documentazione che sia più di un semplice riflesso del forum, ma che abbia un indice curato correttamente, come:
In realtà, questa è proprio l’idea, @manuel! Stiamo pianificando di creare dei modi per filtrare facilmente questi tipi di guide, mantenendo però i filtri già presenti nel plugin Docs. Organizzare queste guide in tag specifici è il primo passo da compiere.
, oppure forse il gruppo di configurazione avanzata potrebbe includere un avviso, cerca meta! Ad esempio, questo post è molto utile 
), mentre 
.
