Con l'evolversi del nostro flusso di lavoro della Knowledge Base, desideriamo creare confini più chiari su quando le richieste di contenuti possono essere assegnate ai collaboratori della comunità.

Apprezziamo profondamente la competenza dei collaboratori. La conoscenza di lunga data dei prodotti all'interno della comunità è incredibilmente preziosa. Allo stesso tempo, il lavoro sui contenuti legato ai rilasci dei prodotti e alla collaborazione interfunzionale richiede una titolarità chiara, tempistiche prevedibili e un coordinamento strutturato, in modo da poter garantire la consegna tempestiva di contenuti accurati e utili per supportare la base di utenti globale di Mozilla.

Queste linee guida sono progettate per:

• Proteggere le tempistiche di rilascio
• Chiarire la titolarità e la responsabilità
• Preservare una sana collaborazione
• Evitare attriti causati da aspettative poco chiare

Questi cambiamenti mirano a creare una collaborazione sostenibile tra lo staff e i collaboratori.

Prima di iniziare

Prima di procedere, si noti che vengono seguiti flussi di lavoro diversi per gli aggiornamenti minori e maggiori.

Consultare l'articolo Modifiche minori e maggiori agli articoli della Knowledge Base per comprendere che cosa rientra in ciascuna categoria e l'articolo Modificare un articolo della Knowledge Base per indicazioni su come inviare direttamente aggiornamenti minori.

Queste linee guida si applicano solo alle nuove richieste di contenuti o agli aggiornamenti maggiori, e non riguardano le revisioni minori inviate direttamente alla Knowledge Base.

Processo per le nuove richieste di contenuti e gli aggiornamenti maggiori

Il seguente processo si applica alle nuove richieste di contenuti e agli aggiornamenti maggiori inviati tramite Bugzilla.

• Passaggio 1: Invio

Tutti gli aggiornamenti maggiori dei contenuti devono essere inviati tramite un ticket su Bugzilla.

• Passaggio 2: Valutazione e assegnazione
  • Valutazione: tutte le nuove richieste di contenuti passano attraverso un processo di valutazione per determinare la priorità e l'assegnazione. I collaboratori sono incoraggiati a partecipare, a condizione che la richiesta sia in linea con i criteri di assegnazione descritti nella sezione sottostante. Per esprimere interesse, commentare direttamente sul ticket di Bugzilla.
  • Assegnazione: il team CX (Customer Experience) è responsabile dell'intero processo di richiesta di contenuti, indipendentemente dalla titolarità del prodotto, e assegnerà il bug a un collaboratore o a un redattore tecnico. Non iniziare a redigere la bozza finché un membro dello staff CX non conferma l'assegnazione. Una volta assegnato, il Community Manager o un altro membro del team CX guiderà l'utente attraverso il processo.
  • Tempistiche previste: la valutazione viene condotta settimanalmente e i collaboratori possono aspettarsi una risposta entro 5 giorni lavorativi dalla richiesta iniziale.
• Passaggio 3: Creazione del contenuto
  • Bozza del contenuto: esaminare attentamente il ticket per comprendere appieno la richiesta, l'ambito e il risultato atteso. Se una bozza viene fornita dal team di prodotto, utilizzarla come punto di partenza. Altrimenti, è possibile iniziare a redigere il contenuto in Google Docs. Se Google Docs non è un'opzione, è possibile allegare la bozza direttamente al ticket di Bugzilla per la revisione. Assicurarsi di pubblicare il link alla bozza nel ticket di Bugzilla e di impostare le autorizzazioni del documento per consentire alle parti interessate di commentare.
  • Approvazione del contenuto: collaborare strettamente con il richiedente o i portatori di interesse del prodotto per garantire che l'articolo sia completo e accurato. Se mancano informazioni necessarie per completare il lavoro, utilizzare l'opzione "Request information from…" in Bugzilla per raccogliere ulteriori dettagli.
  • Escalation:
    • Se non si è in grado di ottenere le informazioni richieste dal richiedente, contattare un CX Product Support Manager o un Community Manager per ricevere supporto (consultare questo articolo per sapere chi contattare).
    • Se non è possibile rispettare la scadenza prevista dal richiedente, informare il team CX il prima possibile aggiornando il ticket di Bugzilla o contattando direttamente un membro dello staff CX.
• Passaggio 4: Pubblicazione del contenuto
  • Pubblicazione del contenuto: una volta che la bozza è finalizzata e approvata dai portatori di interesse, è possibile inviare il contenuto come nuova revisione dell'articolo della Knowledge Base. Si ricorda che la Knowledge Base di SUMO utilizza una sintassi Wiki personalizzata, quindi assicurarsi che il contenuto sia formattato correttamente se lo si copia da un documento di Google.
  • Revisione del contenuto: i collaboratori devono attendere una revisione della Knowledge Base da parte di un membro dello staff o di un revisore della Knowledge Base (diverso dall'autore) per il controllo della qualità e l'adeguatezza del markup.
  • Chiusura del ticket: una volta pubblicato l'articolo della Knowledge Base, il ticket di Bugzilla può essere chiuso contrassegnandolo come Resolved — Fixed.

Approvazione del contenuto e revisione del contenuto

L'obiettivo primario dell' approvazione del contenuto è convalidare la sostanza e l'intento del contenuto con le parti interessate del prodotto. Ciò include la garanzia che la bozza del contenuto sia:

• Tecnicamente accurata e che rifletta il comportamento previsto del prodotto
• Allineata con la terminologia e le convenzioni di denominazione approvate per il prodotto
• Coerente con la voce e i messaggi del marchio Mozilla

La revisione del contenuto integra l'approvazione concentrandosi sulla qualità e sulla presentazione dell'articolo. Ciò include:

• Garantire la sintassi e la formattazione corrette (incluso il markup wiki)
• Migliorare la chiarezza, la leggibilità e la struttura
• Verificare l'allineamento con le linee guida per i contenuti e quelle editoriali

L'approvazione e la revisione dei contenuti garantiscono che gli articoli siano accurati e di facile utilizzo prima della pubblicazione.

Linee guida aggiuntive per i collaboratori

• Equità nell'assegnazione

I collaboratori che hanno rapporti diretti con i team di prodotto possono essere a conoscenza delle richieste imminenti prima che vengano inviate formalmente. Tuttavia, non iniziare a lavorare o a richiedere l'assegnazione prima che la richiesta di contenuto sia stata creata e valutata. Ciò garantisce che le opportunità di contribuire rimangano aperte ed eque per tutti i collaboratori.

• Rispettare il processo di valutazione

Si prega di concedere al team CX l'intera finestra di valutazione di 5 giorni lavorativi per esaminare e assegnare i ticket di Bugzilla. Evitare di richiedere o fare pressione per le decisioni di assegnazione prima che questo periodo sia trascorso.

• Comunicare i cambiamenti di disponibilità

Comprendiamo che possono sorgere situazioni impreviste. Se non si è in grado di rispettare una scadenza a cui ci si è impegnati, informare il team CX il prima possibile in modo che si possano apportare le dovute modifiche.

• Criteri per la riapertura dei ticket di Bugzilla

Non riaprire un ticket di richiesta di contenuto di Bugzilla risolto per richiedere la revisione di revisioni che non sono direttamente correlate alla richiesta originale. Per aggiornamenti correlati, aggiungere un nuovo commento al ticket esistente invece di riaprirlo. Se non si dispone dell'autorizzazione per commentare, inoltrare la richiesta alla mailing list kb-reviewers (vedere di seguito).

La riapertura di ticket senza che venga soddisfatto questo standard può comportare il rigetto della richiesta. Seguire il Galateo di Bugzilla per mantenere una collaborazione produttiva e rispettosa.

• Richieste di revisione accelerata/urgente

Se la revisione richiede tempi di consegna più rapidi, come una modifica urgente del prodotto, incidenti in corso o imprecisioni critiche, è possibile inviare un'email a kb-reviewers@mozilla.com per richiedere una revisione accelerata.

Dove cercare le richieste di contenuti in arrivo?

I collaboratori sono incoraggiati a partecipare a richieste di contenuti non riservati. Ecco come cercare le richieste di contenuti in arrivo:

• Monitoraggio manuale

Tenere d'occhio i nuovi bug di richiesta di contenuti controllando le richieste in arrivo che non sono state assegnate qui. Quando se ne trova una a cui si è interessati, commentare direttamente sul bug per notificare al team CX che si desidera dare una mano con la richiesta.

• Rimanere aggiornati

Se si desidera ricevere notifiche sulle nuove richieste di contenuti, si può prendere in considerazione la possibilità di "osservare" (watching) il componente Knowledge Base Content su Bugzilla. Per fare ciò: accedere al proprio profilo Bugzilla → Edit Profile & Preferences → Component Watching. Scegliere support.mozilla.org nella selezione del prodotto e selezionare Knowledge Base Content per il campo Component. Non dimenticare di fare clic sul pulsante Add per salvare le modifiche.

Criteri di assegnazione

Una richiesta di contenuto può essere assegnata a un collaboratore quando soddisfa le seguenti condizioni:

• Non include informazioni riservate

Le richieste di contenuti che coinvolgono informazioni sotto embargo o contenuti sensibili rimarranno di proprietà dello staff.

• Non comporta strette dipendenze interne

Anche le richieste che implicano sensibilità dei messaggi, revisione della conformità o specifiche in evoluzione e che richiedono un coordinamento attivo con i partner legali, di marketing e comunicazione, di sicurezza ed esterni rimarranno ai membri dello staff.

• Non relative a prodotti a pagamento

Le richieste di contenuti relative a prodotti in abbonamento e funzionalità a pagamento devono rimanere di proprietà dello staff a causa di requisiti legali, di conformità, di test e di coordinamento interfunzionale. Queste richieste spesso coinvolgono informazioni contrattuali, di fatturazione o sensibili al rilascio che richiedono una responsabilità centralizzata.

• Non urgenti

Le richieste di contenuti con un tempo di consegna inferiore a 5 giorni rimarranno allo staff per garantire una consegna tempestiva e l'allineamento con i programmi di rilascio.

• Capacità del collaboratore

I collaboratori sono limitati a un massimo di 3 assegnazioni attive alla volta. Ciò aiuta a garantire un'esecuzione mirata e previene lo squilibrio del carico di lavoro. Si riconosce che alcune richieste possono subire ritardi a causa di dipendenze tecniche. Se una richiesta rimane bloccata per dipendenze lato prodotto per più di due settimane, il ticket può essere considerato inattivo (obsoleto) ed escluso dalle aspettative di carico di lavoro del collaboratore.

Ulteriori chiarimenti:

• Questo si applica solo alle richieste tramite Bugzilla e non si applica alle revisioni minori della Knowledge Base.
• Questo non si applica alla creazione di Risposte comuni per il forum di supporto Mozilla.
• Lo staff mantiene la responsabilità finale per i contenuti pubblicati.