                       Instruc,oes para Mentores do Ports

  A Equipe de Gerenciamento do Ports do FreeBSD

   Revisao: 3f5c3f4996

   Copyright (c) 2011 Thomas Abthorpe, Chris Rees

   2018-09-06 00:32:15 +0000 por Edson Brandi.
   [ Documento HTML em partes / Documento HTML completo ]

     ----------------------------------------------------------------------

   Indice

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

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

   Esta sec,ao destina-se a ajudar a desmistificar o processo de orientac,ao
   (mentoria), bem como a promover abertamente uma discussao construtiva para
   adaptar e desenvolver as diretrizes. Em nossas vidas, temos muitas regras;
   nos nao somos uma organizac,ao governamental que inflige regulamentac,ao,
   mas sim um coletivo de individuos com o mesmo pensamento que trabalha em
   direc,ao a um objetivo comum, mantendo a garantia de qualidade do produto
   que chamamos de Colec,ao de Ports.

  1.1. Por que tornar um Mentor?

     * Para a maioria de nos, fomos orientados (mentorados) quando entramos
       no projeto, entao devolva o favor oferecendo-se para orientar
       (mentorar) outra pessoa.

     * Voce tem um desejo irresistivel de infligir conhecimento aos outros.

     * A punic,ao usual se aplica porque voce esta doente e cansado de fazer
       o commit do bom trabalho de outra pessoa!

  1.2. Mentor/Co-Mentor

   Razoes para uma co-orientac,ao (co-mentorship):

     * Diferenc,a significativa de fuso horario. Mentores acessiveis e
       interativos disponiveis via IM sao extremamente uteis!

     * Barreira de idioma potencial. Sim, o FreeBSD e muito orientado para o
       ingles, assim como ocorre no restante da area de desenvolvimento de
       software, no entanto, ter um mentor que fale uma lingua nativa pode
       ser muito util.

     * ENOTIME! Ate que haja um dia de 30 horas e uma semana de 8 dias,
       alguns de nos nao tem muito tempo para dar. Compartilhar a carga com
       outra pessoa tornara isso mais facil.

     * Um mentor iniciante pode se beneficiar da experiencia de um
       committer/mentor mais senior.

     * Duas cabec,as sao melhores que uma.

   Razoes para uma mentoria solitaria:

     * Voce nao joga bem com os outros.

     * Voce prefere ter um relacionamento um-a-um.

     * As razoes para a co-mentoria nao se aplicam a voce.

  1.3. Expectativas

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

   Esperamos que os mentores assumam a responsabilidade pelas ac,oes de seus
   mentees. Um mentor deve acompanhar todos os commits que o mentee faz,
   tanto os aprovados quanto os implicitos.

   Esperamos que os mentores se certifiquem de que seus mentees leiam o
   Porter's Handbook, o Diretrizes para manuseio de relatorios de problemas,
   e o Guia do Committer.Embora nao seja necessario memorizar todos os
   detalhes, todo committer precisa ter uma visao geral dessas coisas para
   ser uma parte efetiva da comunidade (e evitar o maior numero possivel de
   erros de novato).

  1.4. Selecionando um Mentee

   Nao ha uma regra definida para o que torna um candidato pronto; pode ser
   uma combinac,ao do numero de PRs que eles enviaram, o numero de ports
   mantidos, a frequencia de atualizac,oes dos ports e/ou o nivel de
   participac,ao em uma area especifica de interesse como GNOME,KDE,Gecko ou
   outros.

   Um candidato deve ter quase nenhum timeout, ser responsivo a solicitac,oes
   e geralmente cooperativo no suporte aos seus ports.

   Deve haver um historico de comprometimento, pois e amplamente entendido
   que o treinamento de um committer requer tempo e esforc,o. Se alguem
   contribui ja ha algum tempo e ja passou algum tempo observando como as
   coisas sao feitas, podemos antecipar que existe algum conhecimento
   acumulado. Frequentemente vemos mantenedores que enviaram alguns PRs
   aparecerem no IRC perguntando quando eles receberao o commit bit.

   Estar inscrito e seguir as listas de discussao e muito benefico. Nao ha
   expectativa real de que enviar postagens para as listas torne alguem um
   committer, mas isso demonstra comprometimento. Alguns e-mails oferecem
   insights sobre o conhecimento de um candidato e tambem como eles interagem
   com as outras pessoas. Da mesma forma, participar do IRC pode dar a alguem
   um perfil mais elevado.

   Pergunte a seis commiters diferentes quantos PRs um mantenedor deve enviar
   antes de ser indicado, e voce tera seis respostas diferentes. Pergunte `as
   mesmas pessoas por quanto tempo alguem deveria estar participando, o mesmo
   dilema. Quantos ports eles devem ter no minimo? Agora nos temos um
   bikeshed! Algumas coisas sao dificeis de quantificar, um mentor tera
   apenas que usar seu melhor julgamento e esperar que o portmgr concorde.

  1.5. Durac,ao do Mentorship (Orientac,ao)

   A medida que o nivel de confianc,a se desenvolve e cresce, o mentee pode
   receber direitos "implicitos" de commit. Isso pode incluir mudanc,as
   triviais em um Makefile, pkg-descr, etc. Da mesma forma, pode incluir
   atualizac,oes de PORTVERSION que nao incluam alterac,oes de plist. Outras
   circunstancias podem ser formuladas a criterio do Mentor. No entanto,
   durante o periodo de orientac,ao, qualquer atualizac,ao de versao em um
   port que afete outros ports dependentes devera ser verificada por um
   mentor.

   Assim como somos todos individuos diferentes, cada mentee tem uma curva de
   aprendizado diferente, o tempo de dedicac,ao ao projeto e outros fatores
   de influencia irao contribuir para o tempo necessario antes que eles
   possam "voar sozinhos". Empiricamente, um mentee deve ser observado por
   pelo menos 3 meses. O numero de 90-100 commits e um outro objetivo que um
   mentor poderia usar antes de liberar um mentee. Outros fatores a
   considerar antes de liberar um aprendiz sao o numero de erros que eles
   podem ter cometido, QATs recebidos, etc. Se eles ainda estao cometendo
   erros, eles ainda precisam da orientac,ao 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 e o principal ponto de contato ou o "primeiro entre os iguais", o
   co-mentor e o backup.

   Alguns reprovados, cujo nome sera retido, fizeram o registro do primeiro
   commit de um co-mentor. Commits similares de co-mentors tambem foram
   vistos na arvore src. Sera que isso o torna correto? Sera que isto o torna
   errado? Parece fazer parte da evoluc,ao de como as coisas sao feitas.

  1.7. Expectativas

   Esperamos que os mentees estejam preparados para criticas construtivas da
   comunidade. Ainda ha muito "conhecimento" que nao esta escrito. Responder
   bem `a uma critica construtiva e o que esperamos que estar selecionando,
   ao primeiro analisar as suas contribuic,oes existentes no IRC e nas listas
   de discussao.

   Alertamos os mentees que algumas das criticas que eles receberao podem ser
   menos "construtivas" do que outras, (seja atraves de problemas de
   comunicac,ao de linguagem, ou da procura excessiva por erros pequenos ou
   sem importancia), e que lidar com isso com tranquilidade e apenas parte de
   estar em uma grande comunidade. Em caso de problemas especificos com
   pessoas especificas, ou quaisquer duvidas, esperamos que eles abordem um
   membro do portmgr no IRC ou por e-mail.
