Ola! Chámome Dmitry Pavlov, traballo en , e tamén son un committer e participante de PMC en Apache Ignite e colaborador en Apache Training. Hai pouco dei unha presentación sobre o traballo dun comisario na reunión de código aberto de Sberbank. Co desenvolvemento da comunidade de código aberto, moitas persoas comezaron a ter preguntas cada vez máis: como converterse nun committer, que tarefas asumir e cantas liñas de código hai que escribir para conseguir este papel. Cando pensamos en comisarios, inmediatamente imaxinamos persoas omnipotentes e omniscientes cunha coroa na cabeza e un volume de "Código limpo" en lugar dun cetro. É así? Na miña publicación, tentarei responder a todas as preguntas importantes sobre os committers para que poidas entender se realmente o necesitas.
Todos os recén chegados á comunidade de código aberto pensan que nunca se converterán en comprometidos. Despois de todo, para moitos, este é un papel de prestixio que só se pode obter por méritos especiais escribindo unha tonelada de código. Pero non é tan sinxelo. Vexamos o committer desde a perspectiva da comunidade.
Quen é un comisario e por que é necesario?
Cando creamos un novo produto de código aberto, sempre permitimos aos usuarios usalo e exploralo, así como modificar e distribuír copias modificadas. Pero cando se produce a distribución incontrolada de copias de software con cambios, non recibimos contribucións á base de código principal e o proxecto non se desenvolve. Aquí é onde se necesita o committer, que ten dereito a recoller as contribucións dos usuarios ao proxecto.
Por que converterse nun comisario?
Comecemos polo feito de que comprometerse é un plus para un currículo, e para os principiantes no campo da programación é aínda máis grande, porque moitas veces ao solicitar un traballo piden exemplos de código.
A segunda vantaxe indubidable de comprometerse é a oportunidade de comunicarse cos principais especialistas e incorporar ideas interesantes de código aberto ao seu proxecto. Ademais, se coñeces ben un determinado produto de código aberto, podes conseguir un traballo nunha empresa que o admita ou o utilice. Incluso hai unha opinión de que se non participas en código aberto, non chegarás a altos postos de carreira.
Ademais dos beneficios en termos de carreira e emprego, comprometerse en si é agradable. Estás recoñecido pola comunidade profesional, ves claramente o resultado do teu traballo. Non como nalgúns desenvolvementos corporativos, onde ás veces nin sequera entendes por que estás movendo campos cara atrás e cara atrás en XML.
Nas comunidades de código aberto podes coñecer aos principais especialistas como Linus Torvalds. Pero se non es así, non debes pensar que non hai nada que facer alí: hai tarefas de diferentes niveis.
Ben, tamén hai bonos adicionais: os committers de Apache, por exemplo, reciben unha licenza IntelliJ Idea Ultimate gratuíta (aínda que con algunhas restricións).
Que facer para converterse en committer?
É sinxelo: só tes que comprometerte.
Se pensas que non hai tarefas para ti nos proxectos, estás equivocado. Simplemente únete á comunidade que che interesa e fai o que necesites. A Apache Software Foundation ten un separado cos requisitos para os comisarios.
Que problemas terás que resolver?
O máis variado - desde o desenvolvemento ata a redacción de probas e documentación. Si, si, a contribución de probadores e documentadores na comunidade valórase en igualdade de condicións coa contribución dos desenvolvedores. Hai tarefas non estándar, por exemplo, executar unha canle de YouTube e dicirlles a outros usuarios como usas un produto de código aberto. Por exemplo, a Apache Software Foundation ten un separado , onde se indica que axuda é necesaria.
Necesito escribir unha función importante para converterme en committer?
Non. Isto non é para nada necesario. O committer non ten que escribir toneladas de código. Pero se escribiches unha función importante, será máis fácil que o comité de xestión do proxecto te avalie. Contribuír á comunidade non se trata só de funcións, programación e probas. Se escribes unha carta e falas dun problema, ofrece unha solución razoada; esta tamén é unha contribución.
É importante entender que comprometerse é unha cuestión de confianza. As persoas coma ti deciden se facerte un compromiso ou non en función dos seus puntos de vista como persoa que aporta beneficios ao produto. Polo tanto, a través das súas accións e feitos na comunidade, precisa gañar esta confianza.
Como comportarse?
Sexa constructivo, positivo, educado e paciente. Lembra que en código aberto todo o mundo é voluntario e ninguén debe nada a ninguén. Non che responden: agarda e recórdache a túa pregunta en 3-4 días. Non sempre che responden; ben, o código aberto é voluntario.
Non lle pidas a alguén que faga algo por ti ou por ti. Os membros da comunidade experimentados teñen un instinto por tales "esmoleiros" e inmediatamente fanse alérxicos a aqueles que queren facerlles o seu traballo.
Se recibes axuda, é xenial, pero non abuses dela. Non deberías escribir: "Rapaces, soluciona isto, se non, perdo o meu bono anual". É mellor preguntar onde debes ir a continuación e cóntanos o que xa desenterraches sobre este erro. E se prometes actualizar a wiki en función dos resultados da resolución do problema, entón a probabilidade de que che contesten aumentará significativamente.
Para rematar, ler e aprender .
Como contribuír se non es un committer?
Os proxectos adoitan usar un esquema RTC, onde primeiro todo pasa por unha revisión e, a continuación, os cambios únense no mestre. Con este esquema, absolutamente todos son sometidos a revisión, incluso os comisarios. Polo tanto, podes contribuír con éxito a un proxecto sen ser un comprometido. E para facilitar a selección de novos participantes, podes orientar a novos participantes, compartir coñecementos e crear novos materiais.
Diversidade: beneficios ou prexuízos?
Diversidade: segundo entende a Apache Software Foundation, esta, entre outras cousas, é a afiliación dos participantes nun proxecto de código aberto por parte de varias empresas. Se todos están afiliados a unha única organización, entón coa perda de interese no proxecto, todos os participantes fuxen rapidamente del. A diversidade ofrece un proxecto estable e a longo prazo, unha experiencia diversa e unha ampla gama de opinións dos participantes.
Por amor ou por comodidade?
Nos proxectos de código aberto hai dous tipos de persoas: as que traballan nunha organización que contribúe a este produto, e as que traballan aquí por amor, é dicir, voluntarias. Cal é máis produtivo? Normalmente, os participantes que apoian o produto da organización colaboradora. Simplemente teñen máis tempo e unha clara motivación para chegar ao fondo da verdade, están centrados na tarefa e máis preto do usuario.
Os que o fan "por amor" tamén están motivados, pero doutro xeito: están ansiosos por estudar o proxecto, por facer do mundo un lugar mellor. E son precisamente estes participantes os que son máis estables e orientados a longo prazo, porque os que chegaron á comunidade por iniciativa propia é improbable que a abandonen nun día.
Como atopar un equilibrio entre produtividade e estabilidade? Hai dúas opcións. A primeira opción: cando o participante traballa nunha empresa que está oficialmente implicada neste proxecto de código aberto e fai algo adicional nel, polo seu propio interese, por exemplo, apoiando aos recén chegados. A segunda opción é unha empresa que sufriu unha transformación de código aberto. Por exemplo, cando os empregados traballan no proxecto empresarial principal catro días á semana, e o resto do tempo traballan en código aberto.
Committer - ser ou non ser?
Comprometerse é un tema bo e útil, pero non debes esforzarte específicamente para converterte nun committer. Este rol non é un rol baseado en código e non demostra o teu coñecemento. O único que importa é a experiencia, é dicir, o coñecemento e a experiencia que se adquire estudando o proxecto, afondando nel e axudando a outros a resolver problemas.
Fonte: www.habr.com