On Mon, Feb 12, 2018 at 04:25:51PM -0500, Tassia Camoes Araujo wrote:
Minha sugestão é: ao começar a trabalhar, estime o tempo que vai levar numa tarefa (com a prática, fica mais fácil estimar). Se vc acha que vai conseguir concluir "numa sentada", geralmente, não vale a pena mandar o ITR/ITT, pq o RFR vai chegar antes mesmo da maioria das pessoas verem o ITR/ITT. Se é algo que vai ficar pro outro dia, aí sim, vale a pena avisar a todos que vc tá trabalhando nisso.

Tássia, isso tudo que você disse faz sentido para mim.

Seguem os meus 2 centavos também :-)

A ideia do ITT e do ITR é sinalizar a intenção de realizar algum trabalho, de modo a evitar trabalho duplicado.

A possibilidade de acontecer alguma duplicação de trabalho realmente é menor se o intervalo de tempo entre a intenção e a concretização do trabalho for pequeno.

Dessa forma, a sugestão de enviar ITT e ITR quando é algo que vai ficar pronto "no outro dia" me parece que pode funcionar.

No entanto, vale lembrar que já tivemos alguns problemas com os po-debconf que poderiam ter sido evitados com um ITT ou um ITR.

Há casos onde um arquivo já foi traduzido mas, por algum motivo, ainda consta como não traduzido na lista de pacotes a traduzir. Alguém inicia uma segunda tradução, desnecessariamente, que acaba sendo descartada. Ponto para o ITT.

Um outro caso que também acontece é o de chegarem duas revisões feitas em paralelo sobre a mesma versão de um arquivo, com patches conflitantes. Isso dificulta o trabalho do tradutor, que tem que integrar esses patches. Com um ITR, as revisões podem ser feitas sequencialmente, o que elimina os possíveis conflitos entre os patches. Ponto para o ITR.

De qualquer modo, enviar ITT e ITR é mais seguro para evitar duplicação de trabalho e não adiciona tanto sobre-esforço. Para intervalos curtos, o risco de não enviá-los é menor.

Responder a