Instruções para Mentores do Ports

A Equipe de Gerenciamento do Ports do FreeBSD

Revisão: 52216

Copyright © 2011 Thomas Abthorpe, Chris Rees

2018-09-06 00:32:15 por ebrandi.

[ Documento HTML em partes / Documento HTML completo ]

1. Diretrizes para relacionamentos Mentor (Orientador) / Mentee (Aprendiz)

Esta seção destina-se a ajudar a desmistificar o processo de orientação (mentoria), bem como a promover abertamente uma discussão construtiva para adaptar e desenvolver as diretrizes. Em nossas vidas, temos muitas regras; nós não somos uma organização governamental que inflige regulamentação, mas sim um coletivo de indivíduos com o mesmo pensamento que trabalha em direção a um objetivo comum, mantendo a garantia de qualidade do produto que chamamos de Coleção de Ports.

1.1. Por que tornar um Mentor?

Para a maioria de nós, fomos orientados (mentorados) quando entramos no projeto, então devolva o favor oferecendo-se para orientar (mentorar) outra pessoa.

Você tem um desejo irresistível de infligir conhecimento aos outros.

A punição usual se aplica porque você está doente e cansado de fazer o commit do bom trabalho de outra pessoa!

1.2. Mentor/Co-Mentor

Razões para uma co-orientação (co-mentorship):

Diferença significativa de fuso horário. Mentores acessíveis e interativos disponíveis via IM são extremamente úteis!

Barreira de idioma potencial. Sim, o FreeBSD é muito orientado para o inglês, assim como ocorre no restante da área de desenvolvimento de software, no entanto, ter um mentor que fale uma língua nativa pode ser muito útil.

ENOTIME! Até que haja um dia de 30 horas e uma semana de 8 dias, alguns de nós não tem muito tempo para dar. Compartilhar a carga com outra pessoa tornará isso mais fácil.

Um mentor iniciante pode se beneficiar da experiência de um committer/mentor mais sênior.

Duas cabeças são melhores que uma.

Razões para uma mentoria solitária:

Você não joga bem com os outros.

Você prefere ter um relacionamento um-a-um.

As razões para a co-mentoria não se aplicam a você.

1.3. Expectativas

Esperamos que os mentores revisem e testem todos os patches propostos, pelo menos por um período inicial que dure mais de uma ou duas semanas.

Esperamos que os mentores assumam a responsabilidade pelas ações de seus mentees. Um mentor deve acompanhar todos os commits que o mentee faz, tanto os aprovados quanto os implícitos.

Esperamos que os mentores se certifiquem de que seus mentees leiam o Porter's Handbook, o Diretrizes para manuseio de relatórios de problemas, e o Guia do Committer.Embora não seja necessário memorizar todos os detalhes, todo committer precisa ter uma visão geral dessas coisas para ser uma parte efetiva da comunidade (e evitar o maior número possível de erros de novato).

1.4. Selecionando um Mentee

Não há uma regra definida para o que torna um candidato pronto; pode ser uma combinação do número de PRs que eles enviaram, o número de ports mantidos, a frequência de atualizações dos ports e/ou o nível de participação em uma área específica de interesse como GNOME,KDE,Gecko ou outros.

Um candidato deve ter quase nenhum timeout, ser responsivo a solicitações e geralmente cooperativo no suporte aos seus ports.

Deve haver um histórico de comprometimento, pois é amplamente entendido que o treinamento de um committer requer tempo e esforço. Se alguém contribui já há algum tempo e já passou algum tempo observando como as coisas são feitas, podemos antecipar que existe algum conhecimento acumulado. Frequentemente vemos mantenedores que enviaram alguns PRs aparecerem no IRC perguntando quando eles receberão o commit bit.

Estar inscrito e seguir as listas de discussão é muito benéfico. Não há expectativa real de que enviar postagens para as listas torne alguém um committer, mas isso demonstra comprometimento. Alguns e-mails oferecem insights sobre o conhecimento de um candidato e também como eles interagem com as outras pessoas. Da mesma forma, participar do IRC pode dar a alguém um perfil mais elevado.

Pergunte a seis commiters diferentes quantos PRs um mantenedor deve enviar antes de ser indicado, e você terá seis respostas diferentes. Pergunte às mesmas pessoas por quanto tempo alguém deveria estar participando, o mesmo dilema. Quantos ports eles devem ter no mínimo? Agora nós temos um bikeshed! Algumas coisas são difíceis de quantificar, um mentor terá apenas que usar seu melhor julgamento e esperar que o portmgr concorde.

1.5. Duração do Mentorship (Orientação)

À medida que o nível de confiança se desenvolve e cresce, o mentee pode receber direitos “implícitos” de commit. Isso pode incluir mudanças triviais em um Makefile, pkg-descr, etc. Da mesma forma, pode incluir atualizações de PORTVERSION que não incluam alterações de plist. Outras circunstâncias podem ser formuladas a critério do Mentor. No entanto, durante o período de orientação, qualquer atualização de versão em um port que afete outros ports dependentes deverá ser verificada por um mentor.

Assim como somos todos indivíduos diferentes, cada mentee tem uma curva de aprendizado diferente, o tempo de dedicação ao projeto e outros fatores de influência irão contribuir para o tempo necessário antes que eles possam “voar sozinhos”. Empiricamente, um mentee deve ser observado por pelo menos 3 meses. O numero de 90-100 commits é um outro objetivo que um mentor poderia usar antes de liberar um mentee. Outros fatores a considerar antes de liberar um aprendiz são o número de erros que eles podem ter cometido, QATs recebidos, etc. Se eles ainda estão cometendo erros, eles ainda precisam da orientação do mentor.

1.6. Debate Mentor/Co-Mentor

Quando um pedido chega para o portmgr, ele geralmente vem como,“ eu proponho 'foo' para um port commit bit, eu serei o co-mentor com 'bar'”. Proposta recebida, votada e executada.

O mentor é o principal ponto de contato ou o “primeiro entre os iguais”, o co-mentor é o backup.

Alguns reprovados, cujo nome será retido, fizeram o registro do primeiro commit de um co-mentor. Commits similares de co-mentors também foram vistos na árvore src. Será que isso o torna correto? Será que isto o torna errado? Parece fazer parte da evolução de como as coisas são feitas.

1.7. Expectativas

Esperamos que os mentees estejam preparados para críticas construtivas da comunidade. Ainda há muito “conhecimento” que não está escrito. Responder bem à uma crítica construtiva é o que esperamos que estar selecionando, ao primeiro analisar as suas contribuições existentes no IRC e nas listas de discussão.

Alertamos os mentees que algumas das críticas que eles receberão podem ser menos “construtivas” do que outras, (seja através de problemas de comunicação de linguagem, ou da procura excessiva por erros pequenos ou sem importância), e que lidar com isso com tranquilidade é apenas parte de estar em uma grande comunidade. Em caso de problemas específicos com pessoas específicas, ou quaisquer dúvidas, esperamos que eles abordem um membro do portmgr no IRC ou por e-mail.