5 principais lições da Hacktoberfest 2020
Avalie esse Artigo
Hacktoberfest 2020 acabou e foi um sucesso estrondoso. Recebemos mais 100 contribuições de mais de 50 colaboradores diferentes para o projeto O-Fish. Saiba por que o aplicativo é crucial na história da nbB sobre o O-Fish.
Antes de vermos as Lições apren-das , vejamos o que foi realizado durante o Hacktoberfest e a quem temos que reconhecer por todo o bom trabalho.
Se você fez parte do Hacktoberfest para o projeto O-Fish, não deixe de assistir ao vídeo de encerramento abaixo. São cerca de 10 minutos.
O objetivo do Hacktoberfest é ser uma CELEBRATION do código aberto, não apenas "para fazer e obter contribuições". Todas as solicitações de pull, por maiores ou pequenas, tiveram um grande impacto. Se você participou do Hacktoberfest, não se lembre de exigir seus distintivosdo fórum da MongoDB Community! Você ainda pode obter um distintivo O-Fish a qualquer momento, contribuir para o projeto O-Fish. Veja como são os selos:
Basta Go aos fóruns da comunidade publicar Contribuidores de código aberto e pegar seus crachás aqui!
Houve muitas correções de erros, bem como adições de recursos pequenos e grandes, como o modo escuro para nossos aplicativos móveis!
Contribuições por semana por repositório
| Fundido/Fechado | o-fish-android | o-fish-ios | o-fish-realm | o-fish-web | wildaid. github.io | Total |
|---|---|---|---|---|---|---|
| 01 - 04 outubro | 6 | 6 | 0 | 7 | 14 | 33 |
| 05 - 11 outubro | 9 | 5 | 0 | 10 | 3 | 27 |
| 12 - 18 outubro | 15 | 6 | 1 | 11 | 2 | 35 |
| 19 - 25 outubro | 4 | 1 | 1 | 4 | 1 | 11 |
| 26 - 31 outubro | 2 | 4 | 2 | 3 | 0 | 11 |
| Total | 36 | 22 | 4 | 35 | 20 | 117 |
Aqui estão os colaboradores que fizeram do Hacktoberfest tão legal para nós! Isso não teria sido possível sem todas essas pessoas.
Colaboradores do Hacktoberfest 2020
O Hacktoberfest não tem a ver com fechar problemas e mesclar PRs. Trata-se de celebrar a comunidade, reunir-se e aprender uns com os outros. Aprendi muito sobre convenções de codificação específicas e senti que realmente nos unimos como uma comunidade que se preocupa com o aplicativo O-FISH.
Também aprendi que algumas coisas que achávamos que eram códigos acabaram se tornando permissões. Isso significa que algumas pessoas pesquisaram apenas para descobrir que o problema exigia uma instância própria para depurar. Além disso, corrigimos muitos bugs que nem ao menos sabermos que existiam ao corrigir permissões.
Então, o que aprenderam com o Hacktoberfest? Essas principais lições são para mantenedores e desenvolvedores de projetos.
Ser mantenedor de projetos é ser gerenciador de pessoas. Atrás de cada solicitação pull (PR) está uma pessoa. Ao contrário de um local de trabalho onde me comunico com outras pessoas o tempo todo, pode haver muito poucas comunicações com os colaboradores. E essas comunicações são públicas. Então,tive o cuidado de considerar o destinatário do meu feedback. Há uma grande diferença entre "isso não funciona" e "Fiz isso e aqui está uma captura de tela do que vejo — não vejo X, que o PR deveria corrigir. Você pode me ajudar?"
Dica 1: Com menos interações e relacionamentos estabelecidos, cada palavra tem mais peso. Mantenedores do projeto - certifique-se de que seu feedback seja construtivo e que seu tom seja grato, útil e acolhedor. Desenvolvedores - não há problema em se comunicar mais - faça perguntas nas edições, Go a qualquer horário de expediente e até mesmo comente sobre seu próprio PR para explicar as escolhas que você fez ou, como uma pergunta como " Eu fiz isso com CSS embutido, devo movê-lo para um arquivo separado? "
As pessoas provavelmente não codificarão ou organizarão da maneira que eu esperaria. Às vezes, isso é uma desvantagem - se o PR tiver código que introduz um vazamento de memória, por exemplo. Mas, muitas vezes, uma maneira diferente de trabalhar é uma coisa boa e leva à discussão.
Por exemplo, tivemos dois problemas semelhantes e atribuídos a duas pessoas diferentes. Uma pessoa compreendeu mal o problema e enviou um código que corrigiu o primeiro problema. A outra pessoa enviou um código que corrigiu o problema, mas usou um método diferente. Pedi que eles conversassem uns com os outros nos comentários e chego a um acordo mútuo sobre como fazer isso. O que também é demais, porque eu também aprendera que esse problema específico era sobre o uso de onClique e Link no node.js, e eu não fazia a menor ideia de por que um era usado em vez do outro antes que isso aparecesse.
Dica 2: Mantenedores do projeto - Enquadrem as coisas como um problema, não como uma solução específica. Você seria surpreendido com o que os colaboradores criam. Desenvolvedores - leia o problema completamente para ter certeza de que entendeu o que está sendo perguntado. Se você tiver uma ideia diferente, fique à vontade para trazê-la à tona na edição.
Enquadrar os problemas como um problema, não uma solução específica, é algo que faço o tempo todo como pessoa de produto. Eu diria que é uma das mudanças mais importantes que um desenvolvedor foi 'promovido' a mantenedor do projeto (ou gerente de equipe!) deve internalizar.
O O-Fish tem uma ótima infraestrutura de backend que qualquer pessoa pode construir gratuitamente. No entanto, leva tempo para construir e é irreal esperar que alguém que faz 30 minutos de trabalho para corrigir um bug passe 2 horas configurando uma infraestrutura.
Então, configuramos uma instância de sandbox onde as pessoas podem preencher um formulário e obter automaticamente um login no servidor de sandbox.
Há limitações em nosso sandbox, e alguns problemas precisam de sua própria instância para serem diagnosticados e corrigidos adequadamente. O sandbox não é uma solução perfeita, mas foi uma ótima maneira de reduzir a barreira para as pessoas que queriam resolver problemas menores.
Dica 3: Mantenedores do projeto – Facilite a contribuição dos desenvolvedores de maneiras significativas. Desenvolvedores - para o Hacktoberfest, se você fez trabalho, mas ele não resultou em um PR, pergunta se você pode fazer um PR que será fechado e marcado como "aceito" para que você receba o crédito que mede.
Há muito trabalho a fazer, que não é trabalho de codificação. As questões devem ser bem descritas e definidas como pequenas quantidades de trabalho, com bons títulos. Embora tenha feito isso em setembro, deixei passar alguns itens importantes. Por exemplo, temos um problema intitulado "Sistema de gerenciamento de localização" que soa muito difícil e nenhum o atendeu. Durante o horário de expediente, expliquei a alguém que queria trabalhar que era realmente 2 pequenos scripts de shell. Eles aceitaram o trabalho e fizeram um ótimo trabalho! Mas se eu não tivesse explicado isso durante o horário de trabalho, alguém o teria aceitado porque o título soa como um projeto grande.
O horário de expediente foi uma ótima ideia, e foi incrível que os desenvolvedores aparecessem para fazer perguntas. Isso realmente ajudou com algo que mencionei anteriormente - ser capaz de construir relacionamentos.
Dica 4: Mantenedores do projeto - Reserve um tempo regular para se reunir com os colaboradores em tempo real - por vídeo ou bate-papo em tempo real. Desenvolvedores - Aproveite toda e qualquer oportunidade que puder para conversar com outros desenvolvedores e com o(s) mantenedor(es) do projeto.
Organizamos o horário de expediente por uma hora, duas vezes por semana, às terças e quintas-feiras, em horários diferentes para acomodar diferentes fusos horários. Nosso desenvolvedor-chave também participou de algumas horas de escritório.
Quando recebe uma solicitação de pull, deseja aceitá-la. É desolador não aprovar algo. Embora eu seja técnicamente o guardião do código que é aceito no projeto, saber o que deixar de lado e o que manter é muito importante.
Além de aceitar código feito de forma diferente do que eu teria feito, também aceitei código que não era totalmente preciso. Às vezes, aceitei que era bom o suficiente e outras vezes sugeria uma mudança rápida que resolveria o problema.
Isso não é dever de casa e não há problema em dar dicas. Se alguém fizer uma query usando a função errada, explicarei o que fez e quais problemas isso pode causar e, em seguida, direi "use esta outra função - veja como funciona, ela recebe X e Y e retorna A e B." E vincularei a essa função no código. É mais trabalho da minha parte, mas estou mais familiarizado com a base de código e o colaborador pode ver que estou em sua equipe - não estou apenas rejeitando seu PR e dizendo "use esta outra função", estou tentando ajudá-los.
Como gerente de produto, espero estar permitindo que os colaboradores aprendam mais do que apenas o código. espero que as pessoas aprendam o "por que" e que as decisões não sejam necessariamente feitas com facilidade. Existem motivos. Fazer esse tipo de orientação é um tipo muito diferente de trabalho e pode ser exaustivo - mas é fundamental para o sucesso de um projeto.
Fui muito liberal com o rótulo aceito pelo hacktoberfest. Às vezes, alguém fornecia uma correção que simplesmente não funcionava devido à peculiaridade do próprio aplicativo. Eles dedicaram algum tempo a isso, discutimos o assunto, eles entenderam. Então eu fechei o PR e adicionei o rótulo aceito, porque eles fizeram um bom trabalho e mereceram o crédito. Em outros casos, alguém fazia perguntas sobre um problema e me explicava por que não era possível corrigi-lo, e eu pedia que enviasse um PR de qualquer maneira, e eu lhe dava o crédito. Nem todas as contribuições valiosas estão na forma de um PR, mas você pode fazer com que façam um PR para dar crédito a elas.
Dica 5: Mantenedores do projeto: Dê aos desenvolvedores o máximo de crédito possível. Agradeça a eles e conecte-se com eles nas redes sociais. Desenvolvedores: Saiba que todas as formas de trabalho são valiosas, mesmo que não haja um resultado tangível. Por exemplo, ser capaz de descartar uma opção é extremamente valioso.
Os PRs que mais me surpreenderam foram aqueles que me fizeram registrar tíquetes adicionais - como pessoas que apontaram problemas de acessibilidade e corrigiram alguns. Depois, voltei e criei tickets para todo o resto.
Ao todo, o Hacktoberfest 2020 foi um sucesso – por escrever código e corrigir bugs, mas também por construir uma comunidade. Graças a todos os que participaram!
Não é tarde demais para se envolver!
O-Fish é open source e ainda aceita contribuições. Se você quiser trabalhar no O-Fish, basta seguir as diretrizes de contribuição -. Para entrar em contato conosco, envie-me uma mensagem da minha página do fórum - você precisa ter o nível Sproutfácil de obter para mensagens.