Um contributo para um projeto que não é seu lê-se como trabalho credível no currículo quando a entrada indica com precisão o que fez realmente: um pull request concreto que foi integrado, um erro que localizou e corrigiu, uma revisão que deu e que moldou a alteração de outra pessoa, ou um papel de mantenedor que ocupa no projeto, em vez de apenas o nome de um repositório ao lado de uma ligação. O trabalho open source difere de um projeto que construiu sozinho num ponto importante: o seu nome fica no histórico de commits ao lado dos nomes de outros contribuidores, num projeto que já tinha os seus próprios mantenedores antes de chegar e que continuou a funcionar depois de a sua alteração ser integrada, pelo que a entrada tem de indicar com precisão a sua parte concreta, em vez de deixar o leitor presumir que é dono de todo o projeto.
Porque é que uma linha open source precisa de uma redação diferente de um projeto próprio
Para um projeto que construiu e controla inteiramente, apresentar projetos pessoais no currículo de um engenheiro de software explica como descrever o que faz, com que ferramentas o construiu e o que mudou por o ter construído. Um contributo open source coloca primeiro uma questão diferente, não o que o projeto faz, já que o leitor costuma poder verificar isso em segundos se o projeto for conhecido, mas o que fez especificamente dentro de um projeto que já existia e já tinha a sua própria direção. Uma linha vaga ao lado do nome de um projeto conhecido, sem qualquer descrição do seu envolvimento real, pode ler-se como uma tentativa de pedir emprestada a reputação desse projeto em vez de descrever trabalho real, o que é precisamente o oposto do que essa linha deveria alcançar.
Os tipos de contributo que vale a pena nomear com precisão
Um pull request integrado é a unidade de contributo mais clara a nomear, e dizer o que foi alterado importa mais do que apenas mencionar que existe: a correção de um erro concreto, uma funcionalidade nova, uma melhoria de desempenho, ou uma parte de documentação em falta. A revisão de código é trabalho real e valioso num projeto ativo, e merece uma linha separada das próprias alterações integradas quando fez o suficiente para que conte, sobretudo num projeto onde a qualidade das revisões faz parte de como os mantenedores avaliam a posição de um contribuidor. Um papel de mantenedor ou de triagem, em que tem acesso de escrita, revê pull requests de outras pessoas ou gere os issues de um projeto, merece a sua própria linha em vez de se diluir numa menção genérica a "contribuidor", porque diz algo que uma única correção integrada não diz: que outros mantenedores confiam no seu critério de forma continuada. Contributos recorrentes para o mesmo projeto ao longo de vários meses também vale a pena descrevê-los como um padrão, em vez de listar apenas a alteração integrada mais impressionante, porque um padrão lê-se como envolvimento sustentado e não como um episódio pontual.
Exemplo ilustrativo: uma linha de contributo open source
Exemplo ilustrativo, de vago a específico. Vago: "Contribuidor, projeto open source (github.com/example/project)." Específico: "Contribuidor, uma ferramenta de linha de comandos open source usada em ambientes de desenvolvimento locais. Corrigiu um erro que bloqueava a ferramenta com ficheiros de configuração de grande dimensão, e reviu vários pull requests de outros contribuidores do mesmo repositório ao longo de seis meses." A versão específica nomeia o propósito do projeto numa frase, indica com precisão o que a alteração integrada corrigiu de facto, e separa o trabalho de revisão da própria correção, em vez de dar a entender que toda a linha descreve um único contributo.
Creditar o trabalho partilhado sem exagerar
A maioria das alterações integradas num projeto open source ativo costuma passar pela revisão de outra pessoa antes de ser incorporada, e uma entrada de currículo que dá a entender que é o único autor de uma funcionalidade que na realidade vários mantenedores moldaram em conjunto lê-se como um exagero assim que alguém verifica o histórico de commits, algo que num repositório público demora apenas segundos. Nomear o seu contributo concreto, uma correção, uma funcionalidade, uma área que revê com regularidade, em vez de descrever toda a funcionalidade do projeto como se a tivesse construído sozinho, mantém a linha honesta e, na maioria dos casos, mais específica e credível do que uma afirmação mais ampla. Quando vários dos seus contributos se concentram numa área do projeto, como as suas ferramentas de build ou o seu conjunto de testes, nomear essa área costuma informar mais o leitor do que listar individualmente vários pull requests pequenos.
Em que difere de um projeto que é inteiramente seu
Um projeto pessoal construído do zero merece uma linha que descreva o seu propósito e o seu resultado, porque tomou todas as decisões sobre o que faz e como. Um contributo open source merece uma linha que descreva a sua parte concreta dentro das decisões de outra pessoa, porque a direção geral, a arquitetura e o âmbito do projeto costumam já estar definidos antes de chegar. Ambos são trabalho técnico legítimo que merece um lugar no currículo, mas confundir os dois, descrever um contributo open source da mesma forma como descreveria o seu próprio projeto, tende a exagerar o seu papel no projeto partilhado ou a diminuir o trabalho concreto que efetivamente realizou.
Onde deve ficar no currículo
Um contributo open source significativo, ou um papel de mantenedor mantido ao longo do tempo, costuma merecer a sua própria linha numa secção de projetos ao lado dos projetos pessoais, uma vez que ambos descrevem trabalho técnico fora de um cargo remunerado. Vários contributos mais pequenos em projetos diferentes costumam agrupar-se melhor sob um único título, como "Contributos open source", nomeando cada projeto brevemente em vez de dar a quatro linhas ténues e quase idênticas o mesmo peso visual de uma entrada bem descrita. O modelo Developer está construído com uma área de projetos ao lado do histórico profissional, o que se adequa a este tipo de entrada, quer tenha surgido de um emprego quer seja totalmente independente.
Adicione-o ao seu currículo
Um contributo open source, descrito com precisão e creditado com honestidade, é prova real de critério técnico que o leitor pode muitas vezes verificar diretamente. Comece com um modelo construído para trabalho de engenharia e adicione os seus contributos no editor, onde pode continuar a aperfeiçoar a redação à medida que surgem novos contributos.