Grazie mille!
Ieri sera ho implementato e ho testato con successo l’intera stack (anche se non ho ancora testato in produzione) i miei primi due AC, ma non ancora il flusso dei trascritti, utilizzando un campo personalizzato su Topic e una regola thread. Quindi sto facendo buoni progressi verso la possibilità di mostrare il codice in almeno una PR di bozza.
Ho anche un commit separato per rimuovere l’uso non necessario di pstore_get dal provider Slack. Dato che questo è l’unico utilizzo di pstore in tutta la stack, vorresti che rimuovessi anche tutti i pstore_* da app/initializers/discourse_chat.rb in quel commit di pulizia?
È esattamente da dove sono partito, e sarebbe stato sicuramente più semplice!
Tuttavia, almeno per il mio caso d’uso (e ho sentito lo stesso da persone in altre aziende, non siamo unici), canali diversi hanno preferenze diverse sull’uso dei thread. Ci sono canali pensati per essere utilizzati con i thread (perché la maggior parte delle persone si interessa solo ad alcuni argomenti) e canali che sono fortemente contrari ai thread (perché i thread seppelliscono informazioni importanti).
Ho visto due aspetti essenzialmente non correlati che guidano questa preferenza:
- Membri: i canali con la maggior parte dei membri che usano IRC attivamente da decenni sono abituati a disambiguare mentalmente i thread conversazionali intrecciati in un singolo canale e non vogliono cliccare sui thread per vedere contenuti importanti, mentre i canali con la maggior parte dei membri cresciuti nell’email si aspettano che le conversazioni siano thread e di cliccare sulle conversazioni che li interessano.
- Scopo: i canali con uno scopo aziendale di annunci tendono ad essere fortemente threadati, ma i canali con scopi di ricerca o collaborazione sono spesso intenzionalmente non threadati perché i thread nascondono le informazioni a meno che non le si noti e non si clicchi su di essi.
Se desideri avere una sintassi comune per le opzioni delle regole, penserei che Rule potrebbe essere generalmente esteso in modo da avere un valore :options che, come :tags, è un array. Immagino che potrebbe avere senso prendere spunto dai shell da riga di comando, in modo che /discourse [watch|follow|mute] -something -here imposti :options su ['something', 'here'] — riservando un - iniziale per introdurre un’opzione. Quindi sarebbe /discourse watch my-category-slug #tagged-foo -threaded. Non so quanto lavoro in più richiederebbe rispetto a quello che ho già fatto. Hai forti opinioni in un senso o nell’altro qui? Posso vedere argomenti per entrambi i lati: aggiungere un altro valore a Rule la rende più complicata da scrivere per un provider di chat; aggiungere un altro valore di filtro rende un’altra funzionalità specifica di Slack (come la pubblicazione di un trascritto) che rende l’interfaccia più complicata per gli utenti non Slack. Ovviamente potrei mancare qualcosa che renderebbe più difficile di quanto penso; ad esempio, se uno slug di categoria potesse iniziare con - e diventasse improvvisamente ambiguo; lo shell usa -- per indicare “tutto ciò che segue non è un argomento”, ma forse potremmo invertirlo in modo che -- significhi “tutto ciò che segue è un’opzione”. Se desideri che mi occupi di questo, per favore dammi indicazioni sulla sintassi che troveresti appropriata per specificare le opzioni delle regole. Ma aggiungere semplicemente thread mi sembra più semplice, quindi in assenza di indicazioni specifiche per aggiungere una funzionalità generale “options”, aspetterò di apportare eventuali modifiche in quella direzione.
[Edit: Passare da un filtro di regola a un’opzione complicherebbe sicuramente l’interfaccia utente, che dovrebbe espandersi per supportare generalmente le opzioni generali, e questo non mi sembra una grande scelta. Quindi ora, dopo aver guardato l’interfaccia utente, preferirei attenermi al filtro; penso sia più pulito.]
Per il flusso del trascritto del post, grazie per l’idea del commento HTML. Per il mio caso d’uso non mi farà alcun male; onestamente mi aspetto di essere il principale utilizzatore, almeno inizialmente. È un bel trucco semplice.
Ho un’altra idea, da non includere in questa PR: sarebbe bello avere una mappatura dal canale per il messaggio in fase di pubblicazione alla categoria in cui dovrebbe essere creato il post Discourse risultante. Perché ciò accada, penso che il trascritto dovrebbe cambiare per avere un involucro o un sidecar, momento in cui l’involucro o il sidecar potrebbero avere sia la categoria che l’ID Slack. Sembra una quantità sostanziale di apprendimento per me, dato che sono ancora nella fase di “ricerca avanzata su Google del problema” dell’apprendimento di Ruby on Rails. 
