Oi Meu nome é Dmitry Pavlov, trabalho na
GridGain e também sou colaborador e membro do PMC no Apache Ignite e colaborador do Apache Training. Recentemente, fiz um relatório sobre o trabalho do committer na reunião do Sberbank em código aberto. Com o desenvolvimento da comunidade de código aberto, muitos começaram a levantar questões: como se tornar um colaborador, quais tarefas executar e quantas linhas de código você precisa escrever para obter essa função. Quando pensamos nos comprometedores, somos imediatamente apresentados a pessoas onipotentes e oniscientes, com uma coroa na cabeça e um volume de “Código Limpo” em vez de um cetro. É isso mesmo? No meu post, tentarei responder a todas as perguntas importantes sobre os committers para que você possa entender se realmente precisa.
Todos os recém-chegados à comunidade de código aberto têm uma enxurrada de pensamentos de que nunca se tornarão comprometidos. De fato, para muitos, esse é um papel de prestígio que só pode ser obtido por méritos especiais escrevendo uma tonelada de código. Mas não é tão simples. Dê uma olhada no committer da comunidade.
Quem é um colaborador e por que é necessário?
Ao criar um novo produto de código aberto, sempre permitimos que os usuários o usem e pesquisem, além de modificar e distribuir cópias modificadas. Porém, quando há uma distribuição descontrolada de cópias do software com as alterações feitas, não recebemos contrapartidas no código principal e o projeto não se desenvolve. Aqui o mesmo committer já é necessário, o qual tem o direito de coletar contribuições do usuário para o projeto.
Por que se tornar um committer?
Para começar, o comprometimento é uma vantagem no currículo, e para iniciantes no campo da programação é uma vantagem ainda maior, porque muitas vezes ao se candidatar a um emprego, eles pedem exemplos de código.
A segunda vantagem indubitável de se comprometer é a capacidade de se comunicar com os principais especialistas e trazer algumas idéias interessantes do código aberto para o seu projeto. Além disso, se você conhece bem um determinado produto de código aberto, pode obter uma empresa que o suporte ou use. Existe até uma opinião de que, se você não participar de código aberto, não poderá obter altos cargos na carreira.
Além dos benefícios em termos de carreira e emprego, é bom se comprometer. A comunidade profissional reconhece você, você vê claramente o resultado do seu trabalho. Não é como em algum tipo de desenvolvimento corporativo, onde às vezes você nem entende por que está transferindo campos para lá e para cá em XML.
Nas comunidades de código aberto, você pode conhecer os principais especialistas no nível Linus Torvalds. Mas se você não é assim, não deve pensar que não tem nada para fazer lá - há tarefas de diferentes níveis.
Bem, existem bônus adicionais: os committers do Apache, por exemplo, obtêm uma licença gratuita do IntelliJ Idea Ultimate (embora com algumas limitações).
O que fazer para se tornar um colaborador?
Tudo é simples - você precisa se comprometer.
Se você acha que não há tarefas para você em projetos, está enganado. Basta fazer parte da comunidade que lhe interessa e fazer o que for necessário. A Apache Software Foundation possui um
guia separado para requisitos de committer.
Que tarefas você terá que resolver?
O mais diversificado - do desenvolvimento à escrita de testes e documentação. Sim, a contribuição de testadores e documentadores na comunidade é avaliada juntamente com a contribuição dos desenvolvedores. Existem tarefas não padrão, por exemplo, liderar um canal do YouTube e informar aos outros usuários como você usa o produto de código aberto. Por exemplo, a Apache Software Foundation possui uma
página separada que indica que ajuda é necessária.
Preciso escrever um grande recurso para me tornar um colaborador?
Não. Isso não é de todo necessário. O comunicador não deve escrever toneladas de código. Mas se você escreveu um grande recurso, será mais fácil para o comitê de gerenciamento de projetos avaliar você. Contribuir para a comunidade não é apenas sobre recursos, programação e teste. Se você escrever uma carta e falar sobre algum problema, ofereça uma solução fundamentada - isso também é uma contribuição.
É importante entender que se comprometer é confiar. As pessoas que decidem torná-lo um colaborador ou não são decididas por pessoas como você, com base em suas opiniões sobre você como uma pessoa que beneficia o produto. Portanto, você, através de suas ações e ações na comunidade, precisa ganhar essa mesma confiança.
Como se comportar?
Seja construtivo, positivo, educado e paciente. Lembre-se de que em código aberto todos os voluntários e ninguém deve nada a ninguém. Eles não respondem - aguarde e lembre-se da sua pergunta em 3 a 4 dias. Eles não respondem constantemente a você - bem, o código aberto é voluntário.
Não peça para fazer algo por você ou por você. Membros experientes da comunidade gostam de tais "mendigos" e imediatamente há uma alergia para aqueles que querem levar seu trabalho a eles.
Se você é ajudado, é ótimo, mas não abuse. Não escreva: "Pessoal, conserte isso, caso contrário estou perdendo o prêmio anual". É melhor perguntar para onde você vai seguir em frente e nos dizer 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 que eles respondam aumentará significativamente.
Por fim, leia o
Código de Conduta e aprenda
a fazer perguntas .
Como contribuir se você não é um colaborador?
Os projetos geralmente usam o esquema RTC, quando todos passam pela revisão primeiro e, em seguida, as alterações são mescladas no mestre. Com esse esquema, absolutamente tudo passa por uma revisão, até mesmo por comprometedores. Portanto, você pode contribuir com sucesso para o projeto sem ser um consolidador. E para tornar mais fácil a seleção como um novo colaborador, você pode orientar novos membros, compartilhar conhecimentos, criar novos materiais.
Diversidade - benefício ou dano?
Diversidade - no entendimento da Apache Software Foundation, é, entre outras coisas, a afiliação dos participantes de um projeto de código aberto com várias empresas. Se todos são afiliados a apenas uma organização, e com a perda de seu interesse no projeto, todos os participantes estão fugindo dali. A diversidade fornece estabilidade a longo prazo do projeto, experiência versátil e uma ampla gama de opiniões dos participantes.
Por amor ou por conveniência?
Nos projetos de código aberto, existem dois tipos de pessoas: quem trabalha em uma organização que contribui para esse produto e quem trabalha aqui por amor, ou seja, é voluntário. Qual deles é mais produtivo? Como regra, participantes que dão suporte ao produto da organização-colaboradora. Eles simplesmente têm mais tempo e há uma motivação clara para chegar à verdade, estão focados na tarefa e mais próximos do usuário.
Aqueles que fazem isso "por amor" também são motivados, mas de uma maneira diferente - estão ansiosos para estudar o projeto, para tornar o mundo um lugar melhor. E são precisamente esses participantes que são mais estáveis e focados no longo prazo, porque é improvável que aqueles que vieram à comunidade por iniciativa própria a deixem um dia.
Como encontrar um equilíbrio entre produtividade e estabilidade? Existem duas opções. A primeira opção: quando um participante trabalha para uma empresa que está oficialmente envolvida nesse projeto de código-fonte aberto e faz algo extra nele, por seu próprio interesse - por exemplo, ele apóia os 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 viram o principal projeto de negócios quatro dias por semana, e o resto do tempo eles fazem código aberto.
O comissário - ser ou não ser?
O comprometimento é um tópico bom e útil, mas você não deve se esforçar para se tornar um colaborador. Essa função pode ser obtida não para o código e não prova seu conhecimento. Somente a especialização é importante, ou seja, o conhecimento e a experiência que você obterá estudando o projeto, aprofundando-o e ajudando outras pessoas a resolver problemas.