Ecco perché li lasci applicare. Se necessario, l’accesso può essere revocato. Per quanto riguarda la fiducia? Beh, dipende dalla community. ![]()
Cosa li fa candidare? Non c’è bisogno di pensare alle vecchie categorie. Tutti dovrebbero essere uguali. Se qualcuno nota un errore nel testo e decide di correggerlo, dovrebbe fare domanda? Non conosco questo utente, non voglio dargli accesso a tutti i contenuti. E perché? Se la solita moderazione risolve tutti i problemi con la qualità dei contenuti. Inoltre, con la modifica dei contenuti tramite markdown, l’utente avrà difficoltà rispetto al solito editor visivo, è facile commettere errori. Nessuno può garantire che gli utenti non commettano errori.
Dovrebbe essere come GitHub. Chiunque può suggerire modifiche, ma non tutti hanno pieno accesso.
Se qualcuno nota un errore, può inviare un messaggio al gruppo che gestisce il database. Questo riduce la necessità di moderare pesantemente una knowledge base. Se qualcuno vuole diventare un manutentore attivo, può farlo; altrimenti, invia la modifica al gruppo che gestisce il wiki.
Nella mia esperienza, nessuno segnalerà un errore. Troppe azioni per un utente normale. È abbastanza facile correggere o aggiungere contenuti. L’utente non vuole unirsi a gruppi o diventare un moderatore, vuole solo correggere o aggiungere contenuti. Vuole farlo una volta. Procedi da questa logica. Non tutti gli utenti vogliono essere membri attivi della community. Ma possono contribuire. Ho già menzionato GitHub come esempio.
Allora questo è un problema della community con detta community. È molto facile aggiungere un pulsante/link per un "utente normale" per inviare una modifica proposta a detto post/argomento con un pulsante/link secondario se detto utente normale desidera unirsi a un team di manutentori.
Il punto qui è che se c’è un problema con le persone che corrompono la tua base di conoscenza e non vuoi dover usare una moderazione pesante; avere un gruppo di manutentori che possono apportare modifiche ha senso. In un mondo perfetto non ci si dovrebbe preoccupare di persone senza scrupoli che creano problemi non necessari. ![]()
![]()
![]()
Al momento, una notifica di modifica viene inviata al proprietario dell’argomento e a chiunque stia monitorando la wiki ogni volta che c’è una modifica, quindi penso che sia ragionevolmente facile tenere traccia delle modifiche a seconda di come sono impostate le tue notifiche.
Tuttavia, personalmente, non sono contrario all’idea di inviare le modifiche alla coda di revisione/una sorta di coda di revisione di gruppo prima che vengano pubblicate. Non so quanto lavoro richiederebbe costruirla?
Grazie per la comprensione. Sto creando una community tecnica e nessuno vuole che gli utenti scrivano accidentalmente delle sciocchezze. La cosa più importante che caratterizza qualsiasi knowledge base è l’accuratezza delle informazioni. Questa è la base di tutto. Altrimenti, è inutile farlo. Una corretta moderazione della knowledge base è importante quanto il contenuto stesso.
In realtà, stai cercando modifiche condivise. Perché a meno che tu non conosca in anticipo l’editor e faccia una pre-moderazione, quando le wiki lavorano con la post-moderazione, avrai un po’ di difficoltà a raggiungere questo obiettivo:
No. Questo è completamente diverso
In che modo è diverso? Non vuoi consentire la modifica gratuita, perché non ti fidi che un visitatore casuale sappia e possa. Ecco perché vuoi usare diritti di modifica di fatto limitati tramite pre-moderazione. Hai richieste di qualità e conoscenza,
Lo chiami wiki con l’approvazione dello staff. Eppure è una modifica condivisa per un gruppo — e per questo hai già strumenti e impostazioni.
Hai distorto le mie parole. Voglio che tutti possano modificare la knowledge base, compresi gli utenti regolari e occasionali. Per fare ciò, deve esserci una funzionalità composta da una funzione: accettare o rifiutare le modifiche. Questo è sufficiente
In una nota pratica, quale sarebbe lo stato della coda se ci fossero più modifiche in attesa? Al momento, una modifica viene salvata al momento e la wiki è pronta per la persona successiva per apportare una modifica (e se due persone cercano di modificare contemporaneamente si ottengono alcuni messaggi “x sta scrivendo” e alcuni avvisi al salvataggio, credo). La wiki dovrebbe essere bloccata fino all’accettazione/rifiuto dell’unica approvazione?
Non è vero. L’hai scritto tu.
Non ti piace la risposta perché hai deciso che deve passare attraverso wiki. Quella è una situazione totalmente diversa dal distorcere.
Poiché questa è una meta-discussione sui wiki, sono un po’ contrario a una pre-moderazione più dura perché esistono già strumenti adatti. Se un wiki non segue le regole generali, allora dovrebbe cambiare, se possibile. Dopotutto, un wiki è solo un altro argomento. Ma un wiki non ha bisogno di strumenti di moderazione più duri rispetto ad altri argomenti.
E l’idea dei wiki non è limitare i diritti di modifica. Dovrebbe essere un tutti contro tutti, ma senza una lotta alla selvaggia, quindi è necessario un controllo di base. E c’è già.
Credo che tu possa fraintendere. Egli supporta infatti la moderazione post \u003cmark\u003eFree-4-All\u003c/mark\u003e.
La semplice verità è che Discourse Meta supporta entrambi i metodi e ogni community deve decidere quale metodo funziona meglio. Che si tratti di correzioni di moderazione post-pensiero o di un processo di approvazione preventiva utilizzando le opzioni di sicurezza delle categorie dei diritti di gruppo per le categorie dedicate alla knowledge base wiki.
Entrambi i metodi funzionano bene e, come per la personalizzazione aperta di Discourse Meta, è fattibile.
la knowledge base e le discussioni aperte sono cose completamente diverse. Nella knowledge base, l’accuratezza delle informazioni è al primo posto, e nelle discussioni si può scrivere qualsiasi cosa.
In sostanza, ci dovrebbe essere una qualche forma di ramificazione delle versioni dietro questo, e unioni, ecc. L’alternativa è, come dici tu, il blocco, che non è affatto preferibile.
Sarebbe invece possibile inviare la versione modificata come messaggio privato all’autore, e l’autore è colui che può unire o rifiutare la modifica? Il processo potrebbe essere simile a:
- Modifico la wiki
- Clicco su invia
- Il proprietario riceve un messaggio privato della versione più recente della wiki
- Il proprietario può accettare la nuova versione – questa sostituirebbe l’originale con la versione nel messaggio privato
Il proprietario può anche rispondere alla proposta nel messaggio privato e suggerire modifiche o rifiutarla completamente. L’utente può ancora modificare la propria proposta modificando il messaggio privato – questo rimane come un “ramo” e viene “unito” solo quando l’autore originale lo accetta. Quando accettato, il messaggio privato viene archiviato (forse anche convertito in qualche modo in un formato più trasparente?)
Ho notato che anche gli utenti Invision hanno chiesto agli sviluppatori di aggiungere funzionalità simili dal 2015. Quindi questo problema non riguarda solo gli utenti Discourse
https://invisioncommunity.com/forums/topic/423493-wiki-like-editing-is-useless-at-this-moment/?tab=comments
Bump su questo. @SystemZ Penso che questa sia una funzionalità importante per supportare maggiormente quel tipo di configurazione ibrida community/wiki. Sono anche felice di contribuire con codice per portare qualcosa a termine.
Sto usando Discourse come base per una community di apprendimento delle lingue. Abbiamo una sezione articoli a cui le persone possono contribuire, tuttavia, anche gli studenti di lingue di livello intermedio a volte possono essere eccessivamente sicuri nella valutazione delle proprie capacità e finire per condividere informazioni errate.
Una funzionalità come questa sarebbe incredibile per permetterci di democratizzare la modifica dei contenuti wiki sul nostro sito, assicurandoci al contempo di mantenere accurate le nostre informazioni. Inoltre, previene un possibile uso improprio della funzione di modifica.
Se fossi una persona ricca con una casa estiva, invierei delle tangenti a Discourse per implementare questa funzionalità. Purtroppo sono solo una persona a caso in un posto a caso. ![]()
Penso anche che potrebbe essere una buona funzionalità. Abbiamo spostato la nostra documentazione da Docusaurus a Discourse e lì usavamo git per il controllo della versione e le approvazioni. Ora, non vogliamo che tutti siano in grado di modificare il primo post. Ma per l’approvazione, noi, i moderatori, vogliamo rivedere le modifiche apportate dagli autori (gruppo personalizzato).
Al momento, mi fido semplicemente che gli autori pubblichino le loro modifiche controllando in seguito le notifiche di “modifica” che ricevo da quell’argomento.
