Netiquette per lo issue settimanale

[kitsunenosaraT]

Stiliamo una netiquette per gli issue settimanali

Questo issue è rivolto a @MozillaItalia/l10n tutti i volontari che prendono parte al progetto di localizzazione settimanale di Pontoon. Durante gli anni ci siamo dati tante piccole regole e convenzioni non scritte per gestire meglio il progetto. Ora che il nostro team sta crescendo, con sempre nuovi utenti che offrono la loro collaborazione, credo sia giunto il momento di metterle nero su bianco, e se necessario rimettere in discussione, o scriverne di nuove.

Di seguito elencherò le regole più comuni, e invito tutti i volontari a commentarle e proporre le loro modifiche o aggiunte nella sezione dei commenti di seguito. Io aggiornerò mano a mano la lista con le proposte. La lista finale verrà aggiunta nel primo messaggio dello issue settimanale di Pontoon in modo che tutti possano consultarlo.

Netiquette (bozza)

1. Non usare lo issue per discussioni fuori tema, conversazioni personali, battute umoristiche ecc. (per cui sono disponibili appositi gruppi Telegram e sezioni del forum).
2. Non usare la @menzione quando non strettamente necessario, in particolare non menzionare uno o tutti i revisori ogni volta che chiedi il QA (a meno che non desideri il parere di quel revisore specifico).
3. Prendi un progetto a testa in rotazione, in modo che tutti possano partecipare. Questa regola non è applicabile: 3.1 il week-end: visto che la settimana volge al termine, i progetti rimasti sono aperti a tutti; 3.2 per le stringhe delle settimane precedenti/con scadenza imminente/scadute: prima vengono tradotte, meglio è; 3.3 quando c'è un numero elevato di stringhe: essendoci abbastanza stringhe per tutti, non è necessario limitarsi.
4. Puoi (anzi sei incoraggiato a) aggiornare la lista di stringhe presenti nello issue se noti che sono apparse nuove stringhe su Pontoon e desidera tradurle (senza bisogno di aspettare che @kitsunenosaraT o altri aggiornino lo issue per iniziare la traduzione)
5. Puoi prendere anche solo una parte delle stringhe di un progetto, secondo la tua disponibilità. Basta che inserisci una casella di spunta con rientro <spazio><spazio>- [ ] nella riga sotto il progetto in questione, scrivendo accanto il tuo nome e il numero di stringhe che prendi.

[kitsunenosaraT]

Vorrei lasciare un nuovo suggerimento. Quando posso, cerco sempre di suddividere le stringhe numerose in parti, es:

• [ ] Progetto 25 + 18 fuzzy
  • [ ] 25 stringhe
  • [ ] 18 fuzzy

Oppure

• [ ] Progetto 60 stringhe
  • [ ] traduttore 1 x stringhe
  • [ ] traduttore 2 x stringhe

Ma a volte non ho tempo di suddividere le stringhe, oppure non mi sembra che valga la pena suddividerle. Però può succedere che qualche volontario abbia, per esempio, il tempo di fare solo 5 stringhe su 15, oppure preferisca lavorare solo sulle fuzzy. In quel caso non voglio penalizzare la buona volontà del volontario, quindi propongo di aggiungere la seguente regola:

5. Puoi prendere anche solo una parte delle stringhe di un progetto, secondo la tua disponibilità. Basta che inserisci una casella di spunta con rientro <spazio><spazio>- [ ] nella riga sotto il progetto in questione, scrivendo accanto il tuo nome e il numero di stringhe che prendi.

[Sav22999]

• Nel punto 1 correggere "canale" in "gruppo" 😄
• Nel punto 2 farei un esempio pratico invece di inserire solo la "@", in questo modo @menzione (così non menzioniamo nessuno, perché è un codice e non viene interpretato)
• Nel punto 4 correggere il tag di sara da @kitsunenosara_t a @kitsunenosaraT 🤣

Sono solo piccole osservazioni, ma per il resto mi sembra tutto Ok (anche il punto 5) 👍

[flodolo]

ben accette invece sul canale Telegram

Se parliamo del canale Telegram dedicato a l10n, non sono d'accordo. Ci sono altri canali Mozilla Italia per quello, e sarebbe bene specificarlo.

[kitsunenosaraT]

Grazie per i suggerimenti molto oculati @Sav22999 (non so più neanche scrivere il mio nome utente 🤣 )

Riguardo a canale/gruppo, @flodolo ha ragione sul fatto che mi sono espressa male. Così sembra che puoi usare il gruppo l10n per parlare delle ricette di cucina, e questo ovviamente non andrebbe bene.

Piuttosto intendevo che il gruppo l10n raccoglie un team di persone che lavorano insieme, e ogni tanto si sente il bisogno di scambiarsi qualche battuta tra camerati, che interessa i membri del gruppo stesso, ma non i canali aperti. Penso per esempio a un membro che torna dopo una lunga assenza e saluta tutti, un aggiornarsi a vicenda su come va la vita, ecc.

Per esempio, può succedere che flod scriva nello issue "Lo guardo con calma la settimana prossima, che adesso sono in Giappone" e io, incuriosita voglia chiedergli "Ma flod, che ci fai in Giappone?". In quel caso è meglio che io te lo chieda sul gruppo, dove magari le avventure di flod diletteranno tutti i membri, piuttosto che intasare lo issue.

Ecco, questo intendevo. Devo sforzarmi di esprimere il concetto meno prolissamente.

Già che applico le correzioni di Saverio, ne approfitto per riscrivere tutto in seconda persona, che mi sembra più conciso e amichevole.

[ChiaraGambone]

Ho da ridire su

3.3 quando c'è un numero elevato di stringhe: essendoci abbastanza stringhe per tutti, non è necessario limitarsi.

perché non so proprio cosa significa "numero elevato". Ad esempio la settimana che sono entrata in l10n ho preso 8 stringhe e pensavo fosse un buon numero (tenendo conto che altri progetti ne avevano solo 1) ma poi ho visto ad esempio michro prendersene 50 e ho pensato "urca".

Quindi fare un esempio di quanto sia tante stringhe (50+?) oppure dire di iniziare sempre con 10-20 stringhe a testa in una settimana

[AndyUrbi]

Concordo con @ChiaraGambone : per me possono essere molte anche 3, magari quando sono difficili da inquadrare come contesto per cui si perde del tempo anche per fare delle ricerche. Inoltre sempre più spesso troviamo nuovi utenti che si cimentano nelle traduzioni ma che ancora non conosciamo per cui @kitsunenosaraT poi si prende la briga di contattarli: in questi casi come ci comportiamo?

[kitsunenosaraT]

Grazie a entrambi, era proprio il tipo di feedback che speravo di ricevere!

Hai ragione @ChiaraGambone i concetti di "numero elevato" o "abbastanza stringhe per tutti" sono molto poco oggettivi. Capisco la necessità di avere dei numeri di riferimento.

poi ho visto ad esempio michro prendersene 50 e ho pensato "urca".

Ecco, dovrei precisare michro si è unito da poco alla squadra di Pontoon, non è ancora abituato ai nostri usi. Né è lui il primo che, benintenzionato, si fa una scorpacciata di stringhe al suo primo issue. Molti nuovi volontari tendono a farlo. Da qui il bisogno di scrivere una regola.

Io tendenzialmente non vorrei mettere paletti rigidi con dei numeri, preferirei che riuscissimo ad auto-regolarci in base al principio di lasciare la possibilità a tutti di partecipare. Anche perché non si tratta solo di quante stringhe sono, ma di come sono ripartite.

Per esempio, se ci sono 2 progetti da 25 stringhe ciascuno, le stringhe di per loro sono tante, ma in un certo senso sono anche "poche", visto che ci possono lavorare solo 2 volontari. Al contrario, se abbiamo 25 progetti da 1 stringa ciascuno, le stringhe sono poche, ma paradossalmente sono "tante" perché c'è lavoro per 25 volontari.

Quindi fare un esempio di quanto sia tante stringhe (50+?)

I progetti più grandi possono essere suddivisi in più stringhe. Nell'attuale issue #191 trovi un esempio con il sito Firefox Donate. Direi che si può mettere una regola per cui nei progetti di 50+ stringhe si possono prendere 25 stringhe alla volta.

oppure dire di iniziare sempre con 10-20 stringhe a testa in una settimana

Ecco, questa già la vedo difficile. Come dicevo sopra, in una settimana in cui ci sono 2 progetti da 5 stringhe ciascuna, uno che si prende 10 stringhe si prende tutto. Forse è il caso di ragionare a progetti più che a stringhe?

Potremmo fare, ditemi se vi va bene, che la regola del turno non vale sopra i 10 progetti, oppure se sono presenti mega-progetti divisibili da 50+ stringhe?

[kitsunenosaraT]

@AndyUrbi

Concordo con @ChiaraGambone : per me possono essere molte anche 3, magari quando sono difficili da inquadrare come contesto per cui si perde del tempo anche per fare delle ricerche.

Concordo con questa affermazione. Quindi suppongo che apprezzerai la regola della divisione che ho proposto qui sopra.

Inoltre sempre più spesso troviamo nuovi utenti che si cimentano nelle traduzioni ma che ancora non conosciamo per cui @kitsunenosaraT poi si prende la briga di contattarli: in questi casi come ci comportiamo?

Dunque, Pontoon è aperto ai suggerimenti di chiunque si registra, anche se a stabilire cosa andrà online sono solo i membri con il permesso di "Manager". Per il locale italiano abbiamo sviluppato questo nostro sistema del team che collabora, ma fare parte dei team di localizzazione non è una regola ufficiale di Mozilla Foundation (l'organizzazione madre, da non confondersi con Mozilla Italia, che è un gruppo spontaneo di volontari).

Premetto anche che abbiamo recuperato vari elementi validissimi pescando tra i suggeritori anonimi di Pontoon e invitandoli nel team.

Ora, se una traduzione è fatta bene, con impegno e abilità, io non troverei giusto cestinarla a priori solo perché il suggeritore non fa parte del nostro gruppo. Proporrei di trattare i suggerimenti degli estranei come fuzzy: se vanno bene le accettiamo così come sono. Se non vanno bene, mettiamo un suggerimento alternativo.

Solo, teniamo presente se ci sono estranei che contribuiscono regolarmente con i loro suggerimenti: potrebbero essere interessati ad entrare nel gruppo.

[Sav22999]

@kitsunenosaraT il concetto di "elevate" è, come dici tu, molto complesso poiché dipende dalla complessità delle stesse, dalla settimana e dalla quantità ... a questo punto, non sarebbe meglio aggiungere una sezione nelle linee guida, nella quale viene spiegato nel dettaglio questo punto? Così da poter aggiungere anche più esempi, perché non c'è un problema di "essere concisi" (magari nella netiquette "linkare" alla sezione)

[michrogit]

Intervengo per quanto riguarda la mia "iperattività" nella traduzione delle stringhe chiedendo scusa se ho stravolto i vostri ritmi di lavoro abituali e il vostro modo di distribuirvi le varie traduzioni e per darvi un'idea di come ci muoviamo nei confronti di nuovi collaboratori che traducono senza segnalarci la loro attività.

Per quanto riguarda l'iperattività, purtroppo è un "viziaccio" che abbiamo noi traduttori degli articoli di supporto SUMO… Assieme al mio collega Underpass, l'altro locale leader italiano per la Knowledge Base di Sumo, traduciamo e aggiorniamo articoli a raffica quotidianamente dal 2008 e di solito non ci pestiamo i piedi. Se c'è un nuovo articolo da tradurre, abbiamo un'apposita sezione nel forum di Mozilla Italia in cui segnaliamo che ce ne prendiamo carico. Se c'è un aggiornamento da fare, abbiamo la fortuna che aprendo la pagina di modifica sul sito, si viene avvisati che la pagina è attualmente aperta da (nome del localizzatore) e quindi sappiamo che c'è già qualcuno in azione. Se dopo un po' di tempo non arriva l'email di notifica (su Sumo funziona così) che è stata sottoposta una nuova revisione da parte di (nome del localizzatore) allora ricontrolliamo per vedere se la pagina di modifica è ancora aperta dal localizzatole che se ne sta occupando, altrimenti interveniamo (spesso capita che si desista dall'aggiornare per mancanza di tempo e si esce dalla pagina di modifica). A traduzione o aggiornamento avvenuto, ci arriva un'email di notifica e nella maggior parte dei casi (se si tratta soprattutto di modifiche "pesanti" all'articolo) segnaliamo nell'apposita discussione sul forum e chiediamo il QA. Devo dire che il QA lo chiediamo spessissimo anche per avere un controllo a più occhi che aumenta la qualità della traduzione ed evita frasi mal interpretate, refusi o errori di digitazione.

Per quanto riguarda le traduzioni fatte da collaboratori a noi sconosciuti di cui spesso riceviamo notifica, nella nostra dashboard https://support.mozilla.org/it/localization c'è un avviso all'inizio che segnala la mancata pubblicazione se non si segue una determinata procedura (leggetelo).

Indipendentemente dall'avviso, che spesso non viene proprio preso in considerazione da molti nuovi traduttori e presumo sia difficile da applicare a Pontoon, a me e a Underpass arriva un'email di notifica quando qualcuno traduce qualcosa. In questo caso, valutiamo la bontà della traduzione e se ci sembra valida, indipendentemente da eventuali errori riparabili (siamo stati tutti neo traduttori e capiamo per esperienza diretta le difficoltà iniziali), contattiamo il nuovo collaboratore e lo invitiamo sul forum per aprire la discussione relativa all'articolo tradotto e sottoporlo a QA. Di sicuro (è capitato) non prendiamo in considerazione i traduttori che fanno copia/incolla del testo dell'intero articolo tradotto da Google Translator. In quel caso, o rifiutiamo le traduzioni o le lasciamo lì a cuocere nel loro brodo.

Nel corso degli anni abbiamo avuto degli ottimi collaboratori che però, purtroppo, si sono persi per strada o per impegni personali o perché perdevano la passione iniziale per il progetto. Spesso erano studenti che trovato il primo impiego non ce l'hanno fatta a gestire anche questo tipo di collaborazione. Altri invece erano proprio inadatti e poco ricettivi perché continuavano, traduzione dopo traduzione, a ripetere sempre gli stessi errori nonostante i nostri sforzi continui nell'aiutarli suggerendo le correzioni da fare. Io e Underpass ora siamo soli soletti a portare avanti le traduzioni e gli aggiornamenti nonostante arrivino spesso messaggi privati via Sumo di nuovi utenti che si propongono per collaborare e dopo averci fatto perdere un sacco di tempo a fornire tutte le puntuali spiegazioni su come procedere, spariscono senza neanche degnarsi di rispondere. Approfitto, se qualcuno di voi fosse interessato a darci una mano, questa è la nostra sezione sul forum di Mozilla Italia: https://forum.mozillaitalia.org/index.php?board=25.0

Scusate il monolite, era solo per darvi un'idea di come ci muoviamo su Sumo e forse darvi qualche spunto di riflessione anche se mi rendo conto che tradurre un articolo intero avendo ben presente il contesto e potendo verificare direttamente dall'interfaccia di un browser è una cosa e tradurre delle stringhe è senz'altro più complesso soprattutto quando (in alcuni casi) non si capisce bene il contesto. Sappiate però che è grazie alle vostre traduzioni che riusciamo a verificare tutti gli elementi dell'interfaccia dei vari prodotti Mozilla e che il vostro lavoro è fondamentale ;-)

[kitsunenosaraT]

Riguardo alla discussione sulla regola 3.3 @Sav22999 scrive

a questo punto, non sarebbe meglio aggiungere una sezione nelle linee guida, nella quale viene spiegato nel dettaglio questo punto? Così da poter aggiungere anche più esempi, perché non c'è un problema di "essere concisi" (magari nella netiquette "linkare" alla sezione)

Ecco, scrivere una specie di statuto a parte che dettaglia nei minimi termini il comportamento da tenere era proprio quello che volevo evitare 😅 Onestamente, la mia intenzione era scrivere due o tre regolette di buona creanza per non pestarci i piedi a vicenda, non dare ai nuovi volontari l'incombenza di leggere l'ennesimo malloppazzo di regolamento, considerando che già devono:

• leggere le istruzioni dello issue
• leggere la Guida di localizzazione
• familiarizzarsi con Pontoon
• nella maggior parte dei casi familiarizzarsi con GitHub

In realtà anche l’idea di mettersi lì a sviluppare complessi algoritmi per capire quante stringhe ciascuno può prendersi in una settimana non mi entusiasma molto.

La regola del “limitarsi” nasce per dare a tutti la possibilità di partecipare. Prima c’erano per esempio, volontari che, avendo il lunedì mattina libero, si prenotavano tutte le stringhe della settimana a poche ore dall’apertura dello issue oppure, essendo veloci, macinavano un progetto dopo l’atro, mentre altri non potevano accedere al computer fino a sera o traducevano con più flemma, e si trovavano sempre a bocca asciutta.

Tuttavia, la regola di prendersi solo un progetto a rotazione o un tot. di stringhe a testa non risolve i problemi all’atto pratico: le persone che vorrebbero tradurre di più non possono farlo, mentre le persone a cui vengono lasciate le stringhe magari quella settimana non hanno tempo di tradurle. Quindi finisce sempre più spesso che ci ritroviamo a fare il QA la domenica sera o a lasciare le stringhe per la settimana dopo.

Non muore nessuno, ben inteso. Allo stesso tempo però, noi facciamo volontariato sì, per nostro piacere e gratificazione, ma soprattutto per offrire un servizio agli utenti, e mi sembra paradossale che quando eravamo solo in due riuscivamo a fare tutto in tempo, mentre adesso che siamo una squadra ben nutrita ci riduciamo sempre alla fine perché ciascuno teme di rubare le stringhe all’altro.

Secondo me le regole ferree servono per le grandi organizzazioni dove non è possibile un confronto diretto, mentre nei piccoli gruppi come il nostro è preferibile stabilire pochi principi condivisi e poi affidarsi al buon senso dei singoli membri.

Per cui vi propongo di modificare la regola (che io stessa ho scritto male) in: 3. Puoi prenotarti per i progetti a seconda della tua disponibilità, ma ricorda di lasciare anche agli altri volontari occasione di partecipare.

In questo modo ciascuno dovrebbe regolarsi proporzionalmente: se ci sono 5 stringhe ne prenderà 1-2; se ce ne sono 15, 5-6; se ce ne sono 200, una quarantina e così via. Vi sembra che possa funzionare? Datemi il vostro sincero parere. Specialmente chiedo a @ChiaraGambone che segnalato l’inadeguatezza della prima versione.

[kitsunenosaraT]

@michrogit Grazie per averci offerto una comparazione con il modo di lavorare di SUMO. Non nascondo che nel gestire il team ho preso a modello il vostro approccio, pur con le dovute differenze tecniche tra la piattaforma di SUMO e quella di Pontoon.

Io e Underpass ora siamo soli soletti a portare avanti le traduzioni e gli aggiornamenti nonostante arrivino spesso messaggi privati via Sumo di nuovi utenti che si propongono per collaborare e dopo averci fatto perdere un sacco di tempo a fornire tutte le puntuali spiegazioni su come procedere, spariscono senza neanche degnarsi di rispondere.

Qui sarebbe un esercizio interessante capire cos’è che scoraggia i nuovi utenti a questo stadio: troppa documentazione da leggere? Si sentono intimiditi dagli alti standard richiesti? O dal fatto di venire corretti davanti a tutti su un forum pubblico? A volte, riuscire a identificare le difficoltà dei volontari e trovare il modo per venire loro incontro (senza compromettere la qualità e la serietà del lavoro, naturalmente) può fare la differenza.

[ChiaraGambone]

Per cui vi propongo di modificare la regola (che io stessa ho scritto male) in:

3. Puoi prenotarti per i progetti a seconda della tua disponibilità, ma ricorda di lasciare anche agli >altri volontari occasione di partecipare.

Personalmente mi piace molto questo frase @kitsunenosaraT :) Esprime tutto quello che volevamo esprimere senza diventa complicata nè pesante da gestire