Ho notato sul mio forum e anche su Meta che gli argomenti vengono spostati in cima quando il titolo viene modificato. Per me è piuttosto confusionario perché l’argomento appare in cima all’elenco degli argomenti, quindi mi aspetto qualcosa di nuovo, ma è molto difficile individuare la modifica perché di solito vengo portato all’ultimo post mentre la modifica è avvenuta sul primo post.
Ho notato che hai cambiato il fatto che le modifiche all’ultimo post non spostano più l’argomento in cima. È possibile che il fatto che le modifiche al titolo dell’argomento ora attivino uno spostamento sia un effetto collaterale di tale modifica?
Influisce anche sulle modifiche di categorie e tag.
Grazie Moin, ho capito… dato che non sto più verificando se è l’ultimo post, devo verificare se solo le cose dell’OP dell’argomento stanno cambiando e ignorare il bump in tal caso.
Ho una soluzione qui:
Sono stato in grado di riprodurre con le modifiche di categoria ma non con le modifiche di tag.
Hmm ok, penso che sia valido che il titolo non faccia riemergere l’argomento, ma penso che le riemergenze basate sulla modifica di categoria + tag siano complicate da queste due impostazioni:
Queste controllano se un argomento viene fatto riemergere quando si modifica l’OP:
Ma queste impostazioni controllano anche se viene inviata una notifica effettiva quando si cambiano categoria/tag, quindi è un po’ complesso da districare. Ne discuterò internamente un po’ e ti farò sapere.
Prima che rimuovessi il bump sulle modifiche, solo le modifiche al titolo, alla categoria e ai tag facevano fare un bump all’argomento quando non aveva risposte. Altrimenti, non avveniva alcun bump perché non era l’ultimo post. Hai intenzione di ripristinare quella funzionalità, o vuoi bloccare anche questi bump?
Mi sono anche chiesto perché una modifica di categoria sul mio argomento di prova non abbia fatto fare un bump all’argomento ora. Ho l’impressione che sia a causa del periodo di grazia per le modifiche. Dopo aver atteso 5 minuti, la modifica della categoria ha fatto fare nuovamente un bump all’argomento.
Sono ancora confuso su cosa causi un bump ora, oltre a una risposta. Capire ciò potrebbe aiutarmi a trovare soluzioni su come notare le modifiche in cui l’utente ha seguito le istruzioni di Discourse per modificare il proprio post invece di pubblicare risposte consecutive[1]. Penso che possa essere un’esperienza frustrante quando il sistema ti dice di modificare il tuo post invece di rispondere, tu lo fai, e nessuno se ne accorge. Ho anche chiesto aiuto su come le modifiche ai wiki possono essere tracciate ora.
Buon compleanno
“Non sono consentite più di %{count} risposte consecutive. Modifica la tua risposta precedente, o attendi che qualcuno ti risponda.” ↩︎
Per il mio utilizzo, la modifica di un argomento per portarlo in cima al feed più recente era una funzionalità, non un bug. Mi affidavo a questo comportamento per comunicare agli utenti che c’era stata una modifica negli argomenti.
L’ultimo post modificato, che causa il bump, è probabilmente utilizzato da molti per sollevare i post nel feed più recente e attirare l’attenzione delle persone.
Comunicare la modifica rispondendo a un post non è efficiente come una volta che un utente ha letto il post 1, il bump con una risposta lo porterà alla risposta, se la modifica è nel post 1 (che è sempre nel mio caso), non la vedrà.
Se fosse disponibile un’impostazione per attivare/disattivare questa modifica, le persone potrebbero davvero personalizzarla a proprio piacimento, piuttosto che stravolgere una funzionalità consolidata.
Non voglio sempre aumentare un argomento modificato, ma a volte vorrei rendere più evidente una modifica tempestiva. L’aumento automatico è un’opzione, ma non è esattamente quello che vorrei:
L’aumento automatico richiede l’impostazione di una data/ora:
È allettante suggerire un’opzione “Ora” nel menu di aumento automatico, ma l’avviso di aumento automatico indica anche un aumento automatico, non deliberato, che è un segnale diverso:
A volte ho desiderato un’opzione di aumento automatico per argomento in caso di modifica che potesse essere abilitata per ruoli o livelli di fiducia. Immagino pulsanti per “Salva modifica” e “Salva modifica e aumenta”:
…e l’avviso risultante potrebbe dire Argomento modificato dallo staff o simile.
Vorrei anche dire che il vecchio comportamento era incredibilmente utile. Qualcuno può aggiungere un pulsante per poter passare dal vecchio al nuovo comportamento?
Puoi spiegare come hai usato il bumping e in quali casi ti è stato utile?
Ancora non riesco a decidere se preferisco il nuovo o il vecchio comportamento.
Ad esempio, mi piaceva il fatto che le modifiche al titolo, alla categoria e ai tag riportassero l’argomento in cima se non aveva ancora ricevuto risposte. Ciò consentiva agli utenti che guardavano principalmente queste categorie o tag di notarle e rispondere. Mi ha anche aiutato molto qui nel forum a capire come i moderatori usano le categorie e i tag. Gli argomenti venivano spesso spostati prima che venissero risposti.
Mi piace anche l’approccio secondo cui le impostazioni di Discourse ti obbligano ad aggiungere informazioni invece di scrivere un altro post. Tuttavia, questo funziona solo se riporta l’argomento in cima. Quindi, al momento si trova in una situazione strana in cui agli utenti è impedito di scrivere più di 3 post di fila, ma la modifica non riporterà in cima il loro argomento, quindi è probabile che nessuno se ne accorga.
Ho anche pensato che avere un argomento wiki senza risposte in modo che le modifiche lì riportino in cima l’argomento e quando si fa clic sull’argomento, si atterra immediatamente sul post modificato fosse un buon modo per gestirlo.
Anche se i wiki ora riportano di nuovo in cima, non lo fanno solo quando sono l’ultimo post. Trovo questo confuso perché apro un argomento che è stato spostato in cima, ma dove atterro (all’ultimo post) non è chiaro il motivo.
Tuttavia, mi piace che le piccole modifiche non causino un bump. Ho notato che ho modificato di più per aggiungere piccoli dettagli che prima non avrei aggiunto perché li consideravo troppo poco importanti per un bump.
I post che intenzionalmente non ricevono risposte venivano portati in cima al feed più recente se c’era una modifica, ad esempio un annuncio in cui le informazioni erano cambiate.
Per aggiornamenti genuini a un argomento in cui una modifica rimuove informazioni ora obsolete, risalire al feed più recente era molto desiderabile. Poteva essere fatto con una serie di risposte, ma nel tempo questo diventerebbe ingombrante per l’utente per raccogliere ciò che veniva comunicato (immagina 10 risposte con modifiche, ad esempio). Era molto più pulito modificare il post originale / il post più recente e far salire l’argomento nel feed più recente.
Apprezzo che ci saranno persone da entrambe le parti. Aggiungere un’opzione per ripristinare la precedente funzionalità di lunga data in Discourse accontenterà tutti, forse l’opzionalità potrà essere ampliata nel tempo per controllare finemente quale attività su un post costituisce il suo salire nel feed più recente.
Per me, il modo in cui è stato per anni è ottimale e ci ho fatto affidamento.
Questo cambiamento mi ha colto di sorpresa e, sebbene gli utenti possano modificare le date dei post per riportare il loro argomento in cima, perché non farlo accadere automaticamente come è sempre successo prima?
@pmusaraj@martin Questa modifica ha ripristinato un comportamento di lunga data in cui la modifica dell’ultimo post lo riportava in cima al feed delle attività
Sarebbe molto utile se questo “bump” (spinta) alla modifica dell’ultimo post venisse restituito al prodotto, poiché in un solo colpo è stato sovvertito un precedente decennale, che è stato doloroso per noi.
Gli utenti che sono Staff possono risolvere questo problema spostando la data, ma altri utenti non possono. Penso che dovrebbe arrivare un’opzione per consentire il “bump” alla modifica o che il comportamento precedente dovrebbe essere ripristinato.
Non abbiamo intenzione di annullare questa modifica. Ho discusso internamente e per i tuoi casi d’uso puoi:
Rendere il post iniziale (OP) dell’argomento un post wiki. Le modifiche ai post wiki faranno comunque riapparire l’argomento.
Creare un nuovo post nell’argomento quando vengono apportate modifiche importanti.
Inoltre, anche l’utilizzo del timer di Auto-Bump Topic dovrebbe funzionare. In futuro, potremmo introdurre opzioni di configurazione aggiuntive per consentire un controllo più preciso per categoria sul ripristino degli argomenti.
Forse non tutti i post aggiornati dai TL4 e dallo staff dovrebbero diventare wiki che la maggior parte degli utenti del forum può modificare.
Inoltre, far salire l’argomento quando l’OP è un wiki e viene modificato non aiuta per gli argomenti con più di un post wiki o dove il wiki non è il primo post. Ad esempio, in un argomento per cose che vengono raccolte durante un mese, e poi crei un nuovo wiki come risposta per il mese successivo. Questo funzionava molto bene poiché il wiki per il mese corrente era il post più recente, quindi l’argomento veniva fatto salire.
Il timer aggiunge fastidiosi piccoli post di azione all’argomento, che non puoi eliminare, perché ciò comporterebbe il reset della data di “bump” ancora una volta.
Capisco che non si voglia annullare le modifiche, e posso vedere i vantaggi in un’area limitata (piccoli miglioramenti ai propri post), ma allora forse dobbiamo esaminare come garantire che i flussi di lavoro stabiliti nei forum continuino a funzionare.
Lo staff utilizza la reimpostazione della data di “bump” quando vede un argomento in “latest” che è stato fatto salire inutilmente, in qualche modo ha funzionato meglio rispetto allo staff che fa salire manualmente gli argomenti che avrebbero dovuto essere fatti salire ma non lo sono stati. Come se ne accorgono?
Come ha detto Martin, a questo punto non annulleremo questa modifica.
Ci sono tre soluzioni alternative:
Rendere l’OP una wiki
Utilizzare il Timer di Rilancio Automatico degli Argomenti
Pubblicare una risposta per spiegare la modifica (@Moin, questa è la soluzione alternativa suggerita nei casi che descrivi in cui qualcosa non dovrebbe essere una wiki e non si desidera utilizzare il Timer di Rilancio Automatico degli Argomenti)
Continuiamo anche a rilanciare gli argomenti Categorie Documenti quando vengono modificati.
Capisco che queste soluzioni alternative non siano ideali per tutti i casi d’uso. Quando incontrate casi d’uso specifici in cui nessuna di queste opzioni è praticabile, condivideteli con noi in un argomento Feature.
@lindsey@martin@pmusaraj Ho capito che non avete intenzione di annullare questa modifica. Sarebbe possibile introdurre un’opzione per ripristinare questa funzionalità? In modo che gli utenti possano scegliere?
In caso contrario, è tecnicamente possibile creare un plugin che consenta i “bump” alla modifica? Non vi sto chiedendo di crearne uno, ma chiedo se, in linea di principio, sia possibile, in modo da non andare incontro a un vicolo cieco cercando di ripristinare questo comportamento su cui ho imparato a fare affidamento.
