Instruções para Mentores do Ports

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

Razões para uma mentoria solitária:

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).

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.

À 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.

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.

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.