Netiquette per lo issue settimanale #190
Comments
|
Vorrei lasciare un nuovo suggerimento.
Oppure
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. 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 |
Sono solo piccole osservazioni, ma per il resto mi sembra tutto Ok (anche il punto 5) 👍 |
Se parliamo del canale Telegram dedicato a l10n, non sono d'accordo. Ci sono altri canali Mozilla Italia per quello, e sarebbe bene specificarlo. |
|
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. |
|
Ho da ridire su
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 |
|
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. |
|
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.
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. 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.
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.
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? |
Concordo con questa affermazione. Quindi suppongo che apprezzerai la regola della divisione che ho proposto qui sopra.
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. Solo, teniamo presente se ci sono estranei che contribuiscono regolarmente con i loro suggerimenti: potrebbero essere interessati ad entrare nel gruppo. |
|
@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) |
|
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… 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. 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. 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. |
|
Riguardo alla discussione sulla regola 3.3
Ecco, scrivere una specie di statuto a parte che dettaglia nei minimi termini il comportamento da tenere era proprio quello che volevo evitare 😅
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: 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. |
|
@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.
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? |
Personalmente mi piace molto questo frase @kitsunenosaraT :) Esprime tutto quello che volevamo esprimere senza diventa complicata nè pesante da gestire |
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)
@menzionequando 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.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.
<spazio><spazio>- [ ]nella riga sotto il progetto in questione, scrivendo accanto il tuo nome e il numero di stringhe che prendi.The text was updated successfully, but these errors were encountered: