[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Tempo limite para RFRs e LCFCs



-----BEGIN PGP SIGNED MESSAGE-----
Hash: RIPEMD160

On 11/02/2005 04:12 PM, Augusto Cezar Amaral wrote:
> Olá, pessoal.
> Com o intuito de dimnuir o tempo que um arquivo leva entre 
> RFR e DONE, pensei em estipularmos um prazo máximo para a
> permanência em RFR ou LCFC, caso não hajam revisões/comentários.

	Na verdade, pelo processo de QA, uma RFR não pode mudar
pra LCFC a menos que pelo menos uma pessoa tenha revisado ele,
e essa pessoa não pode ser o tradutor, no momento atual não
estamos seguindo isso 100%, mas seria bom que começássemos a
seguir. :)


> Tratando-se especificamente dos WMLs, acho que três dias é o 
> tempo ideal. Nesse caso, se alguém mandar um RFR, e ninguém
> fizer uma revisão no prazo de três dias, o arquivo pode ser
> colocado em LCFC. Se ninguém responder ao LCFC em três dias,
> o arquivo deve ser enviado ao repositório (DONE).

	Não, isso quebra a idéia central de QA. O arquivo *tem*
que ser revisado. Se quem revisou não encontrou falhas tem que
mandar uma mensagem notificando isso. Um arquivo só mudar de
RFR pra LCFC com pelo menos uma revisão, da documentação das
pseudo-urls:

# Can be sent when there are no ITR's, discussion following the
  RFR has ended and it has been 3 days since the RFR
# should not be sent before there has been at least one review

	Depois que a discussão de uma RFR terminou há três dias
e não há outras ITR's pendentes, você pode definir o LCFC. E
não deve enviar um LCFC antes de uma revisão.


> O que vcs acham? Será que isso pode prejudicar a qualidade das 
> traduções?

	Indiretamente (ou a longo prazo) sim. Nossa equipe é
pequena mas dá sinais de crescimento novamente, logo, precisamos
estar com as regras afinadas pra evitar problemas no futuro. Eu
sei que isso atrasa um pouco a tradução e sei que nossa meta é
traduzir tudo o que for possível pro etch, mas temos que fazer
isso da melhor maneira possível e com o menor retrabalho.

	Ainda há revisões pela frente para itens como criptografia
e encriptado e finalmente devemos passar pela divisão entre pt e
pt_BR. =)

	Abraço e parabéns pelo trabalho!
- --
Felipe Augusto van de Wiel (faw)
"Debian. Freedom to code. Code to freedom!"
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)
Comment: Using GnuPG with Debian - http://enigmail.mozdev.org

iD8DBQFDcXaiCjAO0JDlykYRA2yhAJ4yBfm5uQjyWetMRlvXwdBZHCBjGwCgrO+L
NEeRA4d3UAdIABT9gPIoUbs=
=JwQ4
-----END PGP SIGNATURE-----



Reply to: