Domanda veloce su quanto sopra. E per gli argomenti chiusi automaticamente con una soluzione? Logicamente, si desidera che quelli vengano visualizzati perché hanno una soluzione, ma se ho capito bene, al momento quelli sono automaticamente meno prominenti.
15 Mi Piace
È qualcosa che possiamo attivare/disattivare con un’impostazione del sito? In alcuni casi un argomento può essere Chiuso e Risolto. Al contrario, alcuni utenti potrebbero persino aspettarsi che sia più in alto nei risultati.
Sono molto felice di vedere che la ricerca sta ricevendo un po’ di attenzione. La possibilità di cercare specificamente per categoria è già un grande vantaggio per il nostro caso d’uso.
L’unica cosa su cui mi piacerebbe vedere un po’ di miglioramento sono gli errori di battitura comuni. Alcuni motori di ricerca mi hanno viziato al punto che premerò pigramente i tasti finché una combinazione di lettere che assomiglia vagamente alla parola originale non sarà nella barra di ricerca 
. Non mi aspetto che venga eguagliato, ma miglioramenti in quell’area sarebbero un grande passo avanti.
9 Mi Piace
Opinione forte! Penso che sarebbe meglio mantenere la coerenza (cioè, nessuna opzione per sito) e:
- Aumentare la priorità dei post chiusi che sono risolti (a un livello superiore rispetto ai post aperti).
- Aggiungere l’opzione di un timer (idealmente, per categoria e/o per tag) per archiviare automaticamente i post chiusi.
- All’interno dei post archiviati, dare priorità a quelli con soluzioni, ma non in modo tale che vengano visualizzati prima dei post non archiviati.
Disclaimer: sì, voglio quella funzione di archiviazione automatica per il mio sito! Ma penso che abbia senso in generale. Tutto ciò che ha una risposta ma è probabilmente irrilevante dovrebbe essere eliminato. E se non lo vuoi (le tue domande risolte sono sempreverdi), non abilitare l’archiviatore.
8 Mi Piace
Perché, perché rende le cose più facili per gli sviluppatori? O perché rende la vita degli utenti più facile quando saltano tra le discussioni? Qualcos’altro?
La prima ragione non è affatto una ragione: finché il carico di lavoro è umano e un compito è possibile in questa realtà. La seconda è una buona ragione per MS o Apple, che non vogliono lottare troppo con i clienti, ma altrimenti, come amministratore e creatore di contenuti, voglio servire i miei utenti, non mantenere le cose simili a qui, lì o altrove 
Quindi, la terza opzione è quella interessante.
4 Mi Piace
Entrambe le cose. E perché riduce la complessità amministrativa. Invece di un sacco di opzioni in più (e l’opportunità di non rendersi nemmeno conto che c’è un’impostazione per fare ciò che si desidera), fare un passo indietro e trovare uno schema generale in modo che lo schema desiderato funzioni semplicemente nella maggior parte dei casi.
7 Mi Piace
Questo è sicuramente un punto di forza.
Ma. Potremmo usare un’altra soluzione, ancora familiare: le impostazioni nascoste?
Vedo ora due strategie diverse:
- gli amministratori dovrebbero avere mano libera per ottimizzare parti importanti, come i risultati di ricerca, perché le esigenze della community sono diverse e non dipendono dalla piattaforma (questa è una questione di codifica/sviluppo)
- gli amministratori dovrebbero essere trattati come altri utenti e mantenere le cose ordinate e pulite dal punto di vista dell’UX, lasciando che CDCK decida cosa, dove e perché
Guardando Support, entrambi i modi hanno pro e contro Ma comunque, la prima direzione fa parte del mondo open source, mentre l’ultima è la via di Apple.
Più opzioni generano più domande e problemi creati da amministratori non così abili come me. Più opzioni possono dare risultati migliori per utenti e visitatori. Quindi?
Per me la domanda è molto semplice: voglio ottenere una ricerca il più potente possibile, e se chiudere un argomento ne diminuisce il posizionamento nei risultati di ricerca, non chiudo più gli argomenti o molto raramente. Scelta facile, ma poi devo agire a causa delle limitazioni del software, non per le esigenze della community.
Quindi, le strategie sono una cosa diversa dalle tattiche
4 Mi Piace
Abbiamo molti precedenti per le impostazioni qui, abbiamo la priorità di ricerca per categoria che qualsiasi amministratore può configurare.
Certamente non sono contrario a qualche impostazione in più su come il bonus “archiviato/chiuso/risolto” influenzi (in positivo o in negativo) i risultati di ricerca.
È un po’ una missione secondaria, raccomandiamo di dividerla in un altro argomento con una proposta chiara su quale impostazione avrebbe senso?
8 Mi Piace
Vorrei capire quali potrebbero essere i prossimi passi per un cambiamento qui, dato l’interesse espresso finora.
Attualmente, questa è la logica:
secondo @sam:
nota il caso limite qui!
Su meta… dato il rumore su Support tendiamo a volerlo deprioritizzare… una volta deprioritizzato il bonus di ranking chiuso non ha più effetto…
Quindi, qualcos’altro da considerare è come questo si integra con i pesi delle categorie.
Penso che un approccio iterativo qui potrebbe essere il seguente:
- Aggiungere semplicemente un caso per risolto
WHEN topics.solved then 1.1 - Modificare i pesi archiviati, chiusi e risolti in modo che siano moltiplicatori del peso della categoria e tra loro.
- Rendere i moltiplicatori di peso archiviati, chiusi e risolti configurabili tramite le impostazioni del sito
Forse ha senso fare tutto questo in una volta. O forse facciamo prima (1) e (2) e aspettiamo prima di renderli configurabili. Cosa ne pensi @sam?
3 Mi Piace
Usare moltiplicatori sembra un approccio generalmente valido, ma penso sia difficile esprimere ciò che stavo suggerendo sopra.
chiuso non risolto < aperto non risolto < aperto risolto < chiuso risolto
Chiuso dovrebbe essere un aumento di priorità per i post risolti ma una diminuzione per quelli irrisolti.
I post chiusi senza soluzione hanno quasi nessun valore — qualcun altro ha avuto questo problema, ma non c’è risposta qui, e tu non puoi fornirne una. I post chiusi con soluzioni, d’altra parte, valgono oro. Non sono semplicemente risolti, ma in modo definitivo.
4 Mi Piace
OK, e inoltre, hai menzionato anche argomenti archiviati in precedenza:
Quindi, se ho capito bene, preferiresti classificare le cose in questo modo?
(dal più alto al più basso)
- chiuso risolto
- aperto risolto
- aperto non risolto
- chiuso non risolto
- archiviato risolto
- archiviato non risolto
(E poi aggiungere la complessità stratificata delle classifiche per categoria in qualche modo)
2 Mi Piace
Sì, fondamentalmente, anche se l’ordine dei post archiviati probabilmente non ha importanza:
I post archiviati con soluzioni sono probabilmente irrilevanti ma potrebbero essere storicamente interessanti. I post archiviati senza soluzioni sono fondamentalmente gli stessi — se stai cercando nell’archivio, è probabilmente per motivi storici, quindi lo stato risolto è un’informazione ma se è importante quale sia dovresti includerlo esplicitamente nella tua query.
2 Mi Piace
Utilizzi i pesi delle categorie? Se sì, hai delle preferenze su come questi pesi dovrebbero sovrascrivere i pesi basati sullo stato attuali o essere moltiplicativi?
1 Mi Piace
Penso che l’interruttore per cercare in categorie specifiche sia sufficiente e potrebbe essere utile scartare quel peso durante la ricerca (perché le persone cercano soluzioni, non categorie o argomenti/categorie suggeriti).
Le mie due centesimi, sono pienamente d’accordo con quello che stai facendo qui 
2 Mi Piace
Sì, li utilizziamo decisamente. Abbiamo alcune categorie di "flusso di lavoro" che non dovrebbero mai comparire a meno che non vengano richieste, e altre che sono annunci e notizie che sono più importanti.
Sto inventando questo proprio ora quindi mi riservo il diritto di essere incoerente nella mia opinione in futuro, ma la mia sensazione è che voglio che i pesi delle categorie sovrascrivano tutti i pesi dello stato dell’argomento, eccetto l’archiviazione. Ci sto pensando nel caso delle notizie. Quelle dovrebbero comparire in alto nei risultati finché sono fresche, ma non affatto dopo un certo periodo di tempo. E l’archiviazione dei post potrebbe essere il modo in cui ogni sito specifica cosa significa "un certo periodo di tempo" lì.[1]
In alternativa, e forse più semplice: fai semplicemente in modo che i pesi delle categorie prevalgano, e poi introduci un’opzione per categoria per preferire i post freschi, e se questa è selezionata ci sarà un moltiplicatore che diminuisce nel tempo (da 2x a 0,5x, per esempio).
E poi c’è ancora la richiesta di funzionalità di archiviazione automatica a tempo, ma dettagli, dettagli! ↩︎
2 Mi Piace
OK, quello che sto sentendo è che i pesi delle categorie dovrebbero avere la precedenza.
Penso che i pesi risolto/chiuso/archiviato dovrebbero ancora applicarsi all’interno di una categoria.
Ho capito anche la cosa del timer automatico per l’archiviazione… è complementare, ma penso che possiamo ottenere dei risultati qui prima senza di essa.
1 Mi Piace
Sarei in disaccordo qui. Un argomento potrebbe avere una buona risposta, ma l’OP non si è preoccupato di contrassegnarla come soluzione/le soluzioni non erano disponibili se si tratta di un argomento più vecchio, ecc.
Un argomento aperto ha il pro che puoi sollevarlo, ma non ci metterei troppo peso. Preferirei piuttosto vedere il contenuto più pertinente basato sulle parole chiave.
Per quanto riguarda l’archiviazione, sono d’accordo: per me questo è contenuto che non è più rilevante e può avere meno peso.
2 Mi Piace
Perché un argomento del genere dovrebbe essere chiuso? (E, in via preventiva: “Perché il sito è impostato per chiudere gli argomenti dopo N giorni” è una risposta a come l’argomento è stato chiuso, non perché.)
3 Mi Piace
Penso che per mantenere questa modifica gestibile, la fase zero sia banale:
- Aggiungere l’impostazione del sito
prioritize_solved_topicscon valore predefinitotrue - Quando impostato su true, dare a solved 1.1 incondizionatamente.
Non risolve tutte le stranezze qui, ma ci darebbe un progresso ragionevole rapidamente.
Il problema è che dal punto di vista dell’estensibilità non è affatto una modifica facile.
Non c’è una colonna “solved” nella tabella topics, quello che siamo bloccati a fare qui è iniettare una sorta di join da solved nei campi personalizzati dei topic… questo significa che questo SQL deve essere trasformato in un modo piuttosto elaborato:
O
-
Dobbiamo iniettare un
LEFT JOINnel plugin solvedLEFT JOIN topic_custom_fields ts where name = 'accepted_answer_id' and value IS NOT NULL AND and topic_id = topics.id -
Dobbiamo trasformare questa istruzione
CASE, il che probabilmente significa rendere l’intera istruzione CASE componibile utilizzando un plugin.
In alternativa, potremmo cavarcela con qualcosa come CASE EXISTS(...) THEN 1.1 che elimina la necessità di un left join ma presenta i propri rischi.
Ci penserò su, la grande sfida qui è capire come non creare un enorme pasticcio aggiungendo questo supporto dato che il “core” non sa nulla degli argomenti risolti.
8 Mi Piace
@mcwumbly è uno di quelli in cui fare il lavoro è in realtà più facile che specificare il lavoro…
Ho fatto un tentativo su:
7 Mi Piace
Quasi tutti per me! Non riesco quasi mai a capire la specifica finché non ho scritto il codice che sono abbastanza sicuro funzioni. Questo (in parte) perché di solito scrivo codice per una specifica che non capisco. Un paio di volte sono stato in grado di scrivere prima le specifiche come un adulto, ma è piuttosto raro.
È bello sentire che succede anche a te almeno a volte. 
5 Mi Piace