-
Notifications
You must be signed in to change notification settings - Fork 4
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
(IT) Introduzione v.2 #85
Comments
Non mi sembra di averlo letto da nessuna parte. Secondo me si potrebbe aggiungere che, nell'arco della settimana escono molte stringhe è, se pure si ha la disponibilità "totale" per tradurle tutte, sarebbe meglio fare "gioco di squadra" e "condividere"/"dividersi" il lavoro. Poi, in caso ci fossero ancora delle stringhe da tradurre (o fuzzy) nel fine settimana (o solo Domenica), allora si può procedere col tradurre tutto ciò che si vuole :) |
Grazie per aver sollevato l'argomento @Sav22999 . Credo però che sia una cosa che starebbe meglio nel post iniziale di ogni issue, più che non nella guida. Però si dovrebbe anche evitare la situazione opposta, ovvero che uno è libero solo il lunedì, ma non fa tutto quello che potrebbe per lasciare qualcosa agli (eventuali) altri traduttori. Poi nessun altro ci mette mano e si arriva a domenica sera strangolati. Io direi che la cosa migliore sia sapere in anticipo chi ha intenzione di tradurre qualcosa nell'arco della setti mana per regolarsi indicativamente. In questo senso potremmo usare Telegram per aggiornarci sulle disponibilità in tempo reale. Per i progetti da una manciata di stringhe, sono d'accordo che non abbia senso suddividerle, e che un traduttore possa prendersi più progetti da 1-2 stringhe ciascuno. |
Scusa, ma se non c'è una deadline, ciò che la Domenica non viene tradotto lo si riporta la settimana seguente e, magari, si dà il "via libero completo" su quelle stringhe (della settimana precedente) -> così, chi può solo il lunedì/martedì può tradurre quelle strighe a "go go". |
In linea di massima, anche quando non ci sono scadenze specificate, è preferibile che le stringhe siano tradotte in tempi brevi (compatibilmente con la disponibilità dei volontari, si intende). Appunto per questo ci eravamo dati la regola che le stringhe che rimangono il sabato sera sono "via libera" per tutti. Portare le stringhe alla settimana successiva è una sorta di ultima spiaggia quando nessuno ce la fa a tradurle, oppure nei casi in cui le stringhe escano di venerdì. Siccome escono comunque nuove stringhe tutte le settimane, mi sembra un po' assurdo far avanzare delle stringhe apposta da una settimana all'altra quando c'è qualcuno che potrebbe tradurle. Le regole che ci siamo dati, per ricapitolare sono:
Ho dimenticato qualcosa? Comunque, ferma restando la validità di queste regole come principio, sto notando i limiti di un regolamento troppo rigido. Per esempio, non tutti collaborano ogni settimana, per questo la regola di aspettare che tutti abbiano preso almeno un progetto non regge. Quindi, secondo me, in un gruppo piccolo come il nostro, sarebbe più funzionale gestire i progetti basandoci sulla comunicazione, sullo spirito di squadra e sul buonsenso, invece di fare regole troppo elaborate che alla fine ci ingabbiano. |
Esatto, è analogo a ciò che dico io :) Quindi, in definitiva, concordo col fatto di comunicare tra noi e, aggiungerei, bisogna avere un po' di buon senso. Nel senso: se A, volontario localizzazione, ha già tradotto 40 stringhe, dovrebbe rendersi conto in autonomia che magari B, C e D vorrebbero collaborare anche ma, o per velocità di A o per non disponibilità in quel giorno di B,C e D (ponendo sia solo lunedì) non si riescono a prenotare e/o a tradurre. Ti ringrazio, comunque, per questi scambi di idee e di pensiero, che non fanno mai male :) (Hai ragione che non tutti ogni settimana riescono a collaborare... secondo me è dipeso dal fatto, anche, che altri volontari, alcune volte, prendono tutto xD quindi un altro volontario, anche se vorrebbe collaborare, non può 😆) Tra l'altro è una cosa bellissima, a mio avviso, che nella nostra comunità (sezione localizzazione) si discute di "limitare le traduzioni", non credi? Significa che ci sono molti volontari e che tutti vogliono dare un proprio contributo :) |
Scusa se rispondo "a singhiozzo". È vero, è come un torneo con tanti cavalieri/picciotti che si contendono il nobile compito di tradurre! ⚔️ Per quanto riguarda la questione del lunedì, combinazione è un po' che non succede, ma tieni presente che spesso le nuove stringhe escono proprio il lunedì. Comunque dal prossimo issue includerò le 4 regole di cui sopra nel messaggio iniziale. |
In genere più si cerca di darsi delle regole, più diventa difficile rispettarle. Detto questo vorrei dare il mio piccolo contributo.
I miei 2 cent. |
@AndyUrbi anche io condivido i tuoi suggerimenti :)
Per questo io proporrei un'idea. Invece di dare solo il via libero per il QA, non si potrebbe dare l'"OK, terminato", poi se dopo 1 giorno non si dà l'OK passa in automatico a "QA"? Proposta "formale": |
Ma quando chiedi il QA non fai una citazione? Con la citazione arriva una notifica immediata, non serve spulciare tutti i dialoghi. |
Quando parliamo di scadenze, ovviamente parliamo di "scadenze" all'acqua di rose. Se Mozilla volesse pretendere che si rispettino scadenze fisse, dovrebbe assumere gente pagata per star dietro al progetto. La pratica di rileggere dopo un giorno è una cosa che raccomando e faccio anche io professionalmente (quando le scadenze lo permettono), ma magari non tutti hanno tempo di farlo. Inoltre non dovrebbe prolungarsi troppo (tipo aspettare una settimana per rileggere tre stringhe), perché non credo faccia bene neanche al traduttore. Se fai il QA in tempi ragionevolmente brevi ottieni le correzioni ancora a mente fresca, ti rimangono impresse e ti servono per la prossima volta. Per imparare, piuttosto che stare lì a cesellare la stessa traduzione all'infinito, è utile tradurre con regolarità e imprimerti le correzioni per fare meglio la prossima volta. Questo in particolare per @AndyUrbi , visto che hai detto che esiti a prenderti un incarico perché temi di non fare bene. Per quanto riguarda la pratica di mettere "In traduzione" "Richiesta QA" "Completo" accanto ai progetti, è una cosa a cui avevo pensato pure io all'inizio, ma poi avevo scartato perché mi sembrava solo un lavoro in più per il traduttore. AMO Il messaggio comunque ci vuole lo stesso, perché come ha detto AndyUrbi, genera una notifica che va ad avvisare chi di dovere. |
Non vorrei banalizzare il nostro lavoro, ma ritengo che così ci complichiamo solo la vita, eviterei di codificare status, primo perché siamo in pochi, secondo perché non credo che ci siano dei sistemi automatici con cui dobbiamo comunicare, inoltre se si sta seguendo quel progetto leggere il commento è necessario, non basta semplicemente agire al "comando". Per quanto riguarda il fatto che sia necessario far partecipare tutti sono d'accordo, ma non mi trovo d'accordo sul voler estremizzare l'organizzazione. Mi sembrano sufficienti gli strumenti forniti da GitHub, all'inizio non capivo, ma poi ho visto come facevano gli altri e mi sono adattato.
Io non so quando sono libero, non so se avrò tempo per tradurre le stringhe, non so quante sono, non so se sono difficili, e non mi va di dover fare in fretta il sabato (anche se non c'è nessuna obbligatorietà) per tradurre le stringhe rimaste. Mi collego quando posso vedo la issue aperta, mi rendo conto che ci sono stringhe non ancora assegnate e gli do uno sguardo, se capisco che posso tradurle in quel momento, me le assegno, altrimenti le lascio lì, magari qualcun altro potrà farle prima di me. Ora non dico che dobbiamo fare tutti così, ma se il lunedì ci sono 20 stringhe da tradurre divise in tre gruppi, ed io ho un po' di tempo e le faccio tutte, so che poi durante la settimana ne usciranno altre, non sto lì a pensare, aspetta che faccio solo il primo gruppo. Perché poi succede che gli altri giorni non ho tempo, escono altre stringhe, nessuno se le prende e resta il lavoro non fatto, o bisogna farle di fretta. Io direi di lasciare libertà, chiedendo un po' di moderazione, poi ognuno può regolarsi da sé, al massimo può essere utile sapere che qualcuno non sarà disponibile per tutta la settimana, in questo modo chi resta se può fare qualcosa in più la fa. Secondo me è sufficiente avvisare nel gruppo Telegram qualora uno sa già di non avere tempo in quella settimana, in questo modo ognuno sa quanti siamo e può regolarsi se assegnarsi più o meno gruppi di stringhe. Ad esempio è capitato che l'altra settimana io mi sia assegnato tutte le stringhe, ma non l'ho fatto a priori, erano poche, sapevo che @Sav22999 aveva gli esami, @kitsunenosaraT deve fare anche il QA, gli altri non li sentivo da un po', mi sono assegnato il primo gruppo e le ho finiti, i giorni successivi nessuno si assegnava nuove stringhe, ne sono uscite delle nuove, e mi sono assegnate anche quelle, ma complessivamente non si arrivava a 20. Questo è il mio pensiero, se poi si sente la necessità di organizzarci in modo più vincolante e di imporre delle regole, io mi adeguo, ma non so quanto posso reggere, diventa per me più stressante. |
Ottimo Giorgio. |
Ragazzi, sono contenta di questo scambio di idee. Per quanto riguarda la proposta di comunicare su Telegram la disponibilità, vorrei mettere in chiaro che:
Sono passata anche io per le varie manfrine di uscire da scuola/cercare/cambiare lavoro, o avere scadenze e impegni pressanti e improvvisi, e conosco quella sensazione di non sapere cosa sarà di me da una settimana all'altra, quindi vi invito a dare a queste traduzioni il giusto peso nella gerarchia delle vostre priorità e tenerla come un'esperienza piacevole e costruttiva senza fonti di ansia. |
Parole da una vera boss 👍 |
Questo issue è lo spazio dove i nuovi volontari possono discutere i miglioramenti da apportare alla seconda bozza dell’Introduzione.
L’introduzione presenta brevemente Mozilla e i suoi principi fondanti, oltre che il team di localizzazione di Mozilla Italia. Inoltre spiega il ruolo dei traduttori volontari all’interno della nostra organizzazione.
Per partecipare leggi il capitolo nel paragrafo precedente e scrivi in questa sezione i tuoi commenti, suggerimenti e impressioni.
Per citare una parte specifica della guida, copia-incolla la parte rilevante nel campo dei commenti e inserisci davanti il carattere
>
, come nel seguente esempio:verrà visualizzato come:
Vorrei suggerire alcuni false friend da aggiungere alla lista…
Aggiornamenti per la terza bozza
The text was updated successfully, but these errors were encountered: