Una recente modifica a Discourse ha rimosso il “bump” (spinta in alto) quando si modifica l’ultimo (o il primo post) in una discussione.
Questa era una funzionalità su cui avevamo imparato a fare affidamento e non esiste un metodo valido per imitarla per i membri non classificati come staff.
Abbiamo beneficiato di questa funzionalità principalmente per spingere in alto i post in stile annuncio o i post che intenzionalmente ricevevano poche o nessuna risposta.
Questi erano aggiornamenti genuini a un argomento in cui una modifica stava rimuovendo informazioni ormai obsolete. Il fatto che il post risalisse in cima al feed degli ultimi messaggi era molto desiderabile in quanto informava tutti i membri che c’era stata una modifica.
Sì, questo potrebbe essere imitato in una certa misura con una catena di risposte, ma nel tempo, questo diventerà ingombrante per l’utente raccogliere ciò che è stato comunicato (immagina 10 risposte con modifiche, per esempio). Era molto più pulito modificare il post originale / il post più recente e far sì che la discussione risalisse nel feed degli ultimi messaggi.
Apprezzo che ci saranno persone su entrambi i lati di questo, ma questo è stato un precedente di lunga data in Discourse per molti anni, e aggiungere un’opzione per ripristinare la funzionalità precedente a Discourse accontenterà tutti. Forse la possibilità di scelta può essere ampliata nel tempo per controllare finemente quale attività su un post ne costituisce la risalita nel feed degli ultimi messaggi.
Di seguito è riportato un link al thread del bug in cui è stata discussa questa modifica:
Non posso votare su questo poiché non ho ancora raggiunto il livello di fiducia richiesto, ma vorrei anche esprimere la mia approvazione per apportare questa modifica, se possibile.
Come ho detto prima, mi manca anche la possibilità di far risalire gli argomenti quando c’è una modifica significativa.
Uso rss-polling per essere avvisato sulla manutenzione del mio forum tramite il feed RSS di https://status.discourse.org/. L’argomento viene creato quando inizia la manutenzione e veniva fatto risalire con la modifica che ne annunciava la fine. Questa risalita ora manca, e non voglio che gli argomenti siano wiki, poiché nessun utente dovrebbe modificarli, né voglio che siano documenti. Quindi, le soluzioni alternative attuali non aiutano.
In un forum, abbiamo un argomento galleria che mostra i progetti degli utenti oltre agli argomenti individuali in cui gli utenti presentano i loro progetti. Questo argomento è molto utile per raccogliere ispirazione. Aggiungiamo un’immagine dall’argomento di presentazione e un link ad esso in questo argomento galleria. Troppe immagini in un post hanno causato problemi di prestazioni e rendono anche più difficile la modifica. Quindi, creiamo un nuovo post per ogni 10 progetti. La risalita durante la modifica quando veniva aggiunto il 2° o il 9° progetto era utile. È utile per gli utenti notare l’aggiornamento, ed è stato particolarmente utile per coloro che aggiungono progetti manualmente all’argomento. Grazie alla data di attività, potevo vedere immediatamente se qualcun altro aveva già aggiunto il progetto. Ora, ognuno di noi deve aprire l’argomento per verificarlo.
Ci sono anche altri argomenti che funzionano in modo simile: argomenti che servono come panoramica retrospettiva delle modifiche/attività all’interno di un mese e in cui l’ultimo post relativo al mese corrente viene aggiornato alcune volte. Questo funzionava molto bene perché le modifiche all’ultimo post facevano risalire l’argomento. Pubblicare ogni modifica individualmente diminuirebbe la chiarezza delle voci raggruppate mensilmente e significherebbe comunque che gli aggiornamenti alle voci esistenti vengono facilmente persi. Un nuovo argomento ogni mese per poche voci sembra eccessivo, e significherebbe anche che gli utenti dovrebbero reimpostare le loro notifiche ogni mese, oppure avremmo bisogno di una sottocategoria intera che consenta loro di impostare il loro stato di notifica predefinito.
Mi è piaciuto anche il fatto che le modifiche a categorie e tag sugli argomenti senza risposta li facessero risalire. Il più delle volte uso un elenco (filtrato) degli ultimi argomenti. E se un argomento aveva un titolo scelto male o era nella categoria sbagliata, potrei non cliccarci sopra. Se qualcuno migliora queste informazioni, potrei rendermi conto che posso aiutare dopotutto. Ecco perché era utile quando una modifica del genere faceva risalire l’argomento sopra la mia linea di lettura.
Inoltre, è stato utile conoscere categorie e tag. Ho spesso imparato nuovi tag perché sono stati aggiunti a un nuovo argomento o sulla differenza dettagliata tra categorie in base agli argomenti spostati da un moderatore. A volte ho persino chiesto perché, perché penso che la capacità di spostare argomenti in altre categorie comporti anche la responsabilità di conoscere la differenza tra loro.
Mi piace anche l’approccio secondo cui le impostazioni di Discourse ti costringono ad aggiungere informazioni invece di scrivere un altro post.
Per citare il messaggio pop-up:
Tuttavia, questo ha senso solo se gli altri notano che hai modificato il tuo post per aggiungere ulteriori informazioni. Un esempio che ho riscontrato alcune volte su Meta sono gli aggiornamenti a un post dopo che una pull request è stata unita. Aggiungere tali informazioni nel post non notifica coloro che hanno già letto il post, e coloro che non l’hanno fatto possono facilmente capirlo dal badge nell’anteprima.
Per me, non ha senso che l’impostazione che blocca più di tre risposte consecutive da parte di un utente sia ancora attiva e suggerisca modifiche come soluzione, quando tali modifiche sfortunatamente non hanno più l’effetto che avevano una volta.
Non ho un’opinione forte su questa funzionalità, ma un problema correlato è che mi piace fare l’auto-bump dei post e poi rimuovere il messaggio che indica che è stato fatto il bump, ma questo non è più possibile. Quando elimino il messaggio di bump, il messaggio torna giù dove si trovava prima. Se modificare un messaggio lo facesse salire senza creare un “ultimo bumpato 1 giorno fa”, allora sarebbe utile.
(Preferirei poter fare il bump, eliminare il messaggio di bump e mantenere comunque il post in prima pagina a meno che non faccia manualmente “reimposta data di bump”.)
Idea interessante, qualsiasi cosa per ripristinare la funzionalità in cui le modifiche riportavano il post in cima al feed delle attività sarebbe apprezzata
@lindsey c’è qualcosa che si può fare per ripristinare parte di questa funzionalità o è passato troppo tempo e questa è la nuova normalità
Temo che non abbiamo piani attuali per annullare la modifica / ripristinare i bump su tutte le modifiche. Capisco che questa non sia la risposta che volete sentire, tuttavia, continueremo a monitorare questo argomento e a considerare come possiamo supportare meglio i vostri casi d’uso in futuro.
Anche il fatto che qualcosa non accada più non lo è. Ci sono dati su quanti amministratori abbiano notato che il comportamento di Discourse è cambiato? Capisco la tua argomentazione secondo cui c’erano richieste ripetute su come prevenire gli spostamenti. È ovvio che gli amministratori notano uno spostamento che non vogliono. Ma se un argomento non viene spostato, non ti accorgi nemmeno che non è stato spostato, anche se avresti voluto che lo fosse. Quindi sembra meno probabile che le persone lo richiedano.
Inoltre, di recente è emerso di nuovo il fatto che lo spam è più facile da notare se l’argomento viene spostato qui. Mi chiedo perché questo sia rilevante nel caso ora piuttosto limitato in cui un post debba essere spostato durante la modifica. Ma non aveva importanza quando si cambiava l’impostazione predefinita per la maggior parte dei post. Perché un primo post che è una wiki ha bisogno di più protezione dallo spam rispetto a un ultimo post in un argomento che è una wiki?
Come ho detto molte volte prima, capisco i vantaggi, ma non sembra esserci molto interesse nel trovare soluzioni agli svantaggi. È inutile se c’è una sostituzione per i flussi di lavoro attuali dopo un anno o giù di lì. Dovrò trovare una nuova soluzione ora perché non manca molto tempo in cui esista una versione supportata di Discourse in cui una modifica dell’ultimo post sposta l’argomento in cima.
Questo non è affatto motivato dall’emergere di spam.
I post wiki e docs vengono aggiornati in base alla teoria che le modifiche a tali post siano generalmente di interesse.
Per quanto riguarda la protezione dallo spam, la teoria ora è che questi aggiornamenti non abbiano mai fornito molta copertura aggiuntiva. La maggior parte dei post non sono l’ultimo post e le modifiche ad essi non sono mai state fatte emergere dagli aggiornamenti comunque. Quindi, se lo spam tramite modifiche è un problema, necessita di una soluzione diversa a prescindere. Questa non è mai stata una soluzione davvero efficace a quel problema.
Penso ci sia un malinteso. Il mio punto non riguardava il motivo per cui i post wiki nel primo messaggio vengono fatti risalire. Stavo parlando del ragionamento alla base della restrizione del parametro API no-bump, come menzionato nel commento di GitHub:
Dovrebbe essere limitato alle chiavi API dello staff? Non penso che vogliamo che gli utenti normali possano aggirare il bumping (permetterebbe loro di iniettare spam negli argomenti senza portarli all’attenzione delle persone).
Se lo spam fosse davvero la preoccupazione, allora questa restrizione dovrebbe applicarsi in modo coerente, non solo nei pochi casi rimanenti in cui si verifica il bumping. Questo mi ha sorpreso: il ragionamento cita lo spam come un problema qui, ma il bumping non è inteso come un meccanismo di protezione dallo spam, ad esempio, nelle wiki che sono l’ultimo post di un argomento.
Apprezzo che i post wiki vengano fatti risalire in caso di aggiornamenti (anche se l’esperienza utente di essere portati in fondo all’argomento mentre il motivo del bumping è il primo post è ancora confusa).
Il mio punto è solo evidenziare questa apparente incoerenza riguardo allo spam.
Un altro caso in cui mi sarebbe piaciuto sapere della modifica dell’ultimo post ma me la sono persa perché l’argomento non è stato aggiornato: Restrict uploads - #30 by Arkshine