Ao trabalhar diretamente em seu próprio código ou em um código que já esteja bem estabelecido como sua responsabilidade, provavelmente haverá pouca necessidade de verificar com outros committers antes de entrar com um commit. Ao trabalhar em um bug em uma área do sistema que é claramente órfã (e existem algumas dessas áreas, para nossa vergonha), o mesmo se aplica. Ao modificar partes do sistema que são mantidas, formalmente ou informalmente, considere solicitar uma revisão exatamente como um desenvolvedor teria de fazer antes de se tornar um committer. Para os ports, entre em contato com o MAINTAINER
listado no Makefile
.
Para determinar se uma área da árvore é mantida, verifique o arquivo MAINTAINERS na raiz da árvore. Se ninguém estiver listado, analise o histórico de revisões para ver quem fez o commit de alterações no passado. Um script de exemplo que lista cada pessoa que já fez commit de um determinado arquivo junto com o número de commits que cada pessoa fez pode ser encontrado na freefall
em ~eadler/bin/whodid
. Se as consultas não forem atendidas ou se o committer indicar uma falta de interesse na área afetada, vá em frente e faça o commit.
Evite enviar e-mails privados para os mantenedores. Outras pessoas podem estar interessadas na conversa, não apenas no resultado final.
Se houver qualquer dúvida sobre um commit por qualquer razão, submeta-o ao processo de revisão antes de faze-lo. É melhor fazer com que ele seja criticado lá e não quando ele já fizer parte do repositório. Se um commit resulta em controvérsia, pode ser aconselhável considerar a possibilidade de fazer o rollback do commit até que o assunto seja resolvido. Lembre-se, com um sistema de controle de versão, podemos sempre alterá-lo de volta.
Não impugne as intenções dos outros. Se eles vêem uma solução diferente para um problema, ou até um problema diferente, provavelmente não é porque eles são estúpidos, porque eles têm parentesco questionável, ou porque eles estão tentando destruir o trabalho duro, a imagem pessoal ou o FreeBSD, mas basicamente porque eles têm uma visão diferente do mundo. Diferente é bom.
Discorde honestamente. Argumente sua posição com base em seus méritos, seja honesto quanto a quaisquer deficiências que possa ter, e esteja aberto para ver a solução deles, ou mesmo a visão deles do problema, com uma mente aberta.
Aceite a correção. Somos todos falíveis. Quando você cometer um erro, peça desculpas e continue com a vida. Não se bata, e certamente não espanque os outros por seu erro. Não perca tempo com constrangimentos ou recriminações, apenas conserte o problema e siga em frente.
Peça por ajuda. Procure (e dê) revisões dos seus pares. Uma das maneiras pelas quais o software de código aberto deve se sobressair é no número de globos oculares aplicados a ele; isso não se aplica se ninguém revisar o código.
All FreeBSD documents are available for download at https://download.freebsd.org/ftp/doc/
Questions that are not answered by the
documentation may be
sent to <freebsd-questions@FreeBSD.org>.
Send questions about this document to <freebsd-doc@FreeBSD.org>.