Questo è esattamente il problema con la documentazione di Discourse.
Per quanto possa essere “ok” per alcuni andare a caccia di argomenti, non è una documentazione. Sono gli utenti, e peggio ancora, gli amministratori/moderatori che devono cercare informazioni.
No, non lo è. E questa è stata, ed è tuttora, la più grande mancanza di Discourse. Non so se sono troppo maleducato ora o qualcosa del genere, ma la tendenza ad agire qui è troppo incentrata sugli sviluppatori: se non lo sai, puoi sempre leggere il codice sorgente su GitHub. CDCK non ha troppa motivazione per iniziare a costruire una buona documentazione per gli utenti, compresi gli amministratori, ovviamente, perché il loro obiettivo sono le grandi aziende ospitate. Quindi per loro era sufficiente il livello minimo più l’aiuto della community per i “freerider” (che fanno una grande parte della caccia ai bug e delle proposte di UX 
). Tranne che poi avremmo bisogno di un uso più libero dei tag…
Era sufficiente non era solo un errore di battitura o scarse competenze linguistiche in inglese. CDCK/il team ha iniziato a costruire una documentazione migliore e sono totalmente sicuro che dopo un po’ di tempo argomenti secondari come questo saranno solo echi dal passato.
Per quanto riguarda le community di sviluppatori/utenti, Discourse è ben al di sopra della media. Gli errori sembrano essere corretti rapidamente, le richieste di funzionalità non vengono semplicemente ignorate, soprattutto se c’è un caso d’uso ragionevole per esse, e lo staff online (pagato o volontario, non sono sicuro di come si possa distinguere chi sia chi) è piuttosto bravo e abbastanza paziente nell’aiutarci, noi novellini.
Sì, la documentazione ha bisogno di lavoro, ma scrivere una buona documentazione è costoso e richiede tempo. Inoltre, gli sviluppatori spesso non scrivono una buona documentazione perché sono troppo vicini al prodotto, non lo vedono come lo vedono gli utenti. Essere troppo vicini al codice è anche un problema di test del prodotto, anche se in molti progetti open source la community di utenti fa un buon lavoro nel testare le cose.
Certo che lo è. Anche scrivere buon codice lo è. Il lavoro umano di buona qualità è molto spesso costoso. Ma codice e documentazione sono legati insieme, e la documentazione inizia a diventare costosa a quel punto quando nessuno la fa. Altrimenti è solo una parte cruciale di un prodotto come lo è la codifica, inclusi test, design, UX/UI, ecc. Ma gli sviluppatori odiano abbastanza spesso la documentazione perché odiano farla, non c’è niente di sexy in essa, inoltre sono abbastanza spesso davvero pessimi in questo Ma poiché i proprietari delle aziende e altri supervisori sono sviluppatori simili, semplicemente non si preoccupano che i ragazzi stiano selezionando ciò che fanno e ciò che non fanno.
Ma ora sto andando verso cose troppo generali che sono troppo fuori tema. Quindi mi fermo e indico Documentation perché si sta evolvendo in questo momento.
Sono assolutamente d’accordo. Sono uno sviluppatore con oltre 20 anni di esperienza a questo punto, anche se negli ultimi anni mi sono dedicato all’ingegneria delle piattaforme.
Ciò è ben chiaro qui quando si chiede un suggerimento e gli sviluppatori (presumo? Vedo solo che fanno parte di discourse stesso dal loro titolo) arrivano e ti dicono che non lo è e non lo sarà perché hanno deciso così.
OT da qui
L’ho già detto: c’è una differenza tra essere orientati alle proprie scelte tecnologiche e essere orientati al proprio prodotto. Il tuo prodotto dovrebbe soddisfare i casi d’uso degli utenti, nei limiti del ragionevole, non essere “la mia palla e se agli altri non piace possono andare altrove”.
Ho già avviato 5 nuovi progetti e grazie al cielo abbiamo avuto qualcuno nella nostra community che ne sa un po’ di Ruby e che nei prossimi giorni ci spiegherà alcune basi del flusso di discourse in modo che possiamo iniziare a scrivere alcuni plugin che forniscano le funzionalità di cui abbiamo bisogno. Una su tutte, rendere le Modifiche delle Categorie non uno scherzo.
L’argomento di supporto Users are receiving emails even when everything is set up to not send email notifications si è evoluto un po’, quindi l’ho diviso in un paio di nuovi argomenti in altre categorie per dare a ciascuno un po’ di spazio per respirare. 
Posso pensare a un progetto open source in cui gli sviluppatori tendono a lavorare su cose che li interessano, non su cose che potrebbero rendere la vita più facile agli utenti di quel prodotto. Il caso d’uso è sempre una questione di prospettiva, gli utenti dei prodotti hanno una visione diversa del caso d’uso rispetto agli sviluppatori. Gli sviluppatori tendono a pensare alle cose che gli utenti fanno come “solo più dati”, e spesso non vedono come un piccolo cambiamento possa fare una GRANDE differenza nell’usabilità. (Ho fatto la mia parte nello sviluppo di sistemi e sono sicuro di aver avuto quell’atteggiamento a volte.)
Finora non posso dire di aver visto quel tipo di atteggiamento nello sviluppo di Discourse, ma sono qui solo da un mese.
Per quanto riguarda l’essere troppo vicini al prodotto, sto attualmente svolgendo gli esercizi di un libro sullo sviluppo Ruby. Un semplice’hello world’ mi ha richiesto 3 ore per funzionare ieri, principalmente perché il libro presupponeva familiarità con un ambiente IDE AWS (cloud9) che non avevo ancora, quindi cliccavo su qualcosa e annullava le modifiche che avevo appena impiegato 10 minuti a digitare.
E poi c’è stato un problema nel visualizzare un’anteprima dell’app funzionante sul mio browser, che sembra essere dovuto a limitazioni di sicurezza che sia Firefox che Chrome hanno introdotto nei loro browser dall’ultima volta che il libro è stato aggiornato. Dopo circa un’ora di ricerca di soluzioni sul web, l’aggiunta all’elenco consentiti dell’indirizzo IP del mio laptop e desktop ha funzionato, anche se devo ancora fare un passaggio in più per visualizzare l’anteprima.