Olá! Meu nome é Dmitry Pavlov, trabalho em e também sou committer e participante do PMC no Apache Ignite e contribuidor no Apache Training. Recentemente fiz uma apresentação sobre o trabalho de um committer no encontro de código aberto do Sberbank. Com o desenvolvimento da comunidade opensource, muitas pessoas começaram cada vez mais a ter dúvidas: como se tornar um committer, quais tarefas assumir e quantas linhas de código precisam ser escritas para conseguir essa função. Quando pensamos em committers, imediatamente imaginamos pessoas onipotentes e oniscientes com uma coroa na cabeça e um volume de “Código Limpo” em vez de um cetro. É assim? No meu post tentarei responder a todas as perguntas importantes sobre committers para que você possa entender se realmente precisa disso.
Todos os recém-chegados à comunidade de código aberto pensam que nunca se tornarão committers. Afinal, para muitos, esta é uma função de prestígio que só pode ser obtida por mérito especial escrevendo uma tonelada de código. Mas não é tão simples. Vamos dar uma olhada no committer da perspectiva da comunidade.
Quem é um committer e por que é necessário?
Quando criamos um novo produto de código aberto, sempre permitimos que os usuários o utilizem e explorem, bem como modifiquem e distribuam cópias modificadas. Mas quando ocorre a distribuição descontrolada de cópias de software com alterações, não recebemos contribuições para a base de código principal e o projeto não se desenvolve. É aqui que é necessário o committer, que tem o direito de coletar as contribuições dos usuários para o projeto.
Por que se tornar um committer?
Comecemos pelo fato de que o comprometimento é uma vantagem para um currículo, e para iniciantes na área de programação é uma vantagem ainda maior, pois muitas vezes, quando se candidatam a um emprego, pedem exemplos de código.
A segunda vantagem indiscutível de se comprometer é a oportunidade de se comunicar com os principais especialistas e trazer algumas ideias interessantes de código aberto para o seu projeto. Além disso, se você conhece bem um determinado produto de código aberto, pode conseguir um emprego em uma empresa que o apoia ou utiliza. Existe até a opinião de que se você não participar do código aberto, não alcançará altos cargos na carreira.
Além dos benefícios em termos de carreira e emprego, o comprometimento por si só é prazeroso. Você é reconhecido pela comunidade profissional, vê claramente o resultado do seu trabalho. Não como em alguns desenvolvimentos corporativos, onde às vezes você nem entende por que está movendo campos para frente e para trás em XML.
Nas comunidades de código aberto você pode conhecer grandes especialistas como Linus Torvalds. Mas se você não é assim, não pense que não há nada para você fazer lá - existem tarefas de diferentes níveis.
Bem, também há bônus adicionais: os committers do Apache, por exemplo, recebem uma licença gratuita do IntelliJ Idea Ultimate (embora com algumas restrições).
O que fazer para se tornar um committer?
É simples – você só precisa se comprometer.
Se você pensa que não há tarefas para você nos projetos, você está enganado. Basta ingressar na comunidade que lhe interessa e fazer o que ela precisa. A Apache Software Foundation tem um separado com requisitos para committers.
Que problemas você terá que resolver?
Os mais variados – desde o desenvolvimento até a escrita de testes e documentação. Sim, sim, a contribuição dos testadores e documentadores na comunidade é valorizada em igualdade de condições com a contribuição dos desenvolvedores. Existem tarefas fora do padrão - por exemplo, administrar um canal no YouTube e contar a outros usuários como você usa um produto de código aberto. Por exemplo, a Apache Software Foundation tem um separado , onde é indicado qual assistência é necessária.
Preciso escrever um grande recurso para me tornar um committer?
Não. Isto não é de todo necessário. O committer não precisa escrever toneladas de código. Mas se você escreveu um artigo importante, será mais fácil para o comitê de gerenciamento do projeto avaliá-lo. Contribuir para a comunidade não envolve apenas recursos, programação e testes. Se você escrever uma carta e falar sobre um problema, ofereça uma solução fundamentada - isso também é uma contribuição.
É importante entender que comprometer-se tem a ver com confiança. A decisão de torná-lo um comprometedor ou não é decidida por pessoas como você, com base nas opiniões que elas têm de você como uma pessoa que traz benefícios ao produto. Portanto, você, por meio de suas ações e feitos na comunidade, precisa conquistar essa mesma confiança.
Como se comportar?
Seja construtivo, positivo, educado e paciente. Lembre-se que no código aberto todos são voluntários e ninguém deve nada a ninguém. Eles não respondem - espere e lembre-o da sua pergunta em 3 a 4 dias. Eles nem sempre respondem - bem, o código aberto é voluntário.
Não peça para alguém fazer algo por você ou para você. Os membros experientes da comunidade têm um instinto para estes “mendigos” e tornam-se imediatamente alérgicos àqueles que lhes querem empurrar o seu trabalho.
Se você conseguir ajuda, ótimo, mas não abuse. Você não deveria escrever: “Gente, consertem isso, senão vou perder meu bônus anual”. É melhor perguntar para onde você deve ir em seguida e nos contar o que você já descobriu sobre esse bug. E se você prometer atualizar o wiki com base nos resultados da solução do problema, a probabilidade de eles responderem aumentará significativamente.
Finalmente, leia e aprender .
Como contribuir se você não é committer?
Os projetos costumam usar um esquema RTC, onde primeiro tudo passa por uma revisão e depois as alterações são mescladas no mestre. Com esse esquema, absolutamente todos passam por revisão, até mesmo os committers. Portanto, você pode contribuir com sucesso para um projeto sem ser um committer. E para facilitar a seleção como novos committers, você pode orientar novos participantes, compartilhar conhecimento e criar novos materiais.
Diversidade - benefício ou dano?
Diversidade - no entendimento da Apache Software Foundation, esta, entre outras coisas, é a afiliação de participantes de um projeto opensource por diversas empresas. Se todos estiverem afiliados a apenas uma organização, com a perda de interesse no projeto, todos os participantes rapidamente fogem dele. A diversidade proporciona projetos estáveis e de longo prazo, experiências diversas e uma ampla gama de opiniões dos participantes.
Por amor ou por conveniência?
Nos projetos opensource existem dois tipos de pessoas: as que trabalham em uma organização que contribui para este produto, e as que trabalham aqui por amor, ou seja, os voluntários. Qual deles é mais produtivo? Normalmente, os participantes que apoiam o produto da organização contribuinte. Eles simplesmente têm mais tempo e uma motivação clara para descobrir a verdade, estão focados na tarefa e mais próximos do usuário.
Quem faz isso “por amor” também fica motivado, mas de uma forma diferente – tem vontade de estudar o projeto, de fazer do mundo um lugar melhor. E são precisamente esses participantes que são mais estáveis e orientados para o longo prazo, porque aqueles que vieram para a comunidade por iniciativa própria dificilmente a deixarão num dia.
Como encontrar um equilíbrio entre produtividade e estabilidade? Existem duas opções. A primeira opção: quando o participante trabalha em uma empresa que está oficialmente envolvida neste projeto opensource, e faz algo adicional nele, por interesse próprio - por exemplo, apoiando recém-chegados. A segunda opção é uma empresa que passou por uma transformação de código aberto. Por exemplo, quando os funcionários trabalham no projeto comercial principal quatro dias por semana e no resto do tempo trabalham em código aberto.
Committer - ser ou não ser?
Comprometer-se é um tópico bom e útil, mas você não deve se esforçar especificamente para se tornar um committer. Esta função não é baseada em código e não demonstra seu conhecimento. A única coisa que importa é a expertise, ou seja, o conhecimento e a experiência que você ganha ao estudar o projeto, aprofundá-lo e ajudar outras pessoas a resolver problemas.
Fonte: habr.com