- João de Deus Ferreira Filho (lubien1996@gmail.com, @lubien)
- Thiago Calado Sosinho (thiagocalado30@gmail.com, @uzumis)
- Atividade01: link aqui
- Identificar novatos nos projetos
Dos até então 18 contribuidores, 12 são novatos que contribuíram em até 2 commits na época do Hacktoberfest de 2018 visto que a globocom possuia uma premiação para quem contribuísse em seus repositórios. Além destes, 4 outros possíveis contribuidores casuais apareceram no decorrer do tempo de vida do projeto.
Hacktoberfest 2018:
hermancaldara, tiagodanin, davidsonsimoes, cesarsa, pantuza, fannyvieira, tayannevls , mateuspontes, thiagormagalhaes, lubien, tasiazevedo, lucasvst.
Demain:
fsouza, morpheu, guilhermebr, flavioribeiro
- Identificar desenvolvedores chave nos projetos
Criador do projeto: davidsonfelipe;
Mantenedor do projeto: arturfsousa.
- Identificar como tarefas são sugeridas
O projeto não há uma plataforma para distribuição de tarefas. O que há de demanda são explanadas no próprio projeto dentro do Github.
- Identificar como novas contribuições são avaliadas
O mantenedor avalia pessoalmente a qualidade do código e conta também com a utilização de uma ferramenta de automatização do estilo de código (husky) para evitar este trabalho na revisão.
- Identificar como os canais de comunicação das comunidades
- Selecione e identifique em um determinado projeto de software livre se a página inicial ou alguma página logo em seguida tem (ou não) links para instação, documentação, documentação traduzida, e como contribuir. Coloque o projeto avaliado e os links encontrados (ou não);
- Repo: Hospiral Run Frontend - software livre para gestão de hospitais.
- Tem sumário contendo todos os requisitos para instalação, contribuição e execução da página de testes. Todos possuem links para as suas determinadas subseções. O repositório usa o inglês e não há traduções para outros idiomas na sua documentação.
- Em cada seção há links para downloads dos requisitos para o funcionamento do mesmo, incluindo o link da página de demonstração para reconhecimento da ferramenta.
- Links para Instalação: https://github.com/HospitalRun/hospitalrun-frontend#installation
- Link para contribuir: https://github.com/HospitalRun/hospitalrun-frontend#contributing
- Revise uma página de um projeto de software livre e sumarize os problemas encontrados (o que falta para ela ser mais informativa);
JoaoPedroMoraes/graphic-simulator-2000 Possui apenas os arquivos relacionados à pagina. Não existe nenhum tipo de explicação de como fazer setup do ambiente de desenvolvimento, não possui licença tampouco guias de como contribuir. Além disso, não há nem um manual explicando como utilizar a ferramenta nem o que suas funcionalidades significam.
- Teste a documentação (por exemplo, siga as instruções de instalação) e sumarize os problemas encontrados;
Globo.com Open Source; No README os passos de instalação foram bem demonstrados porém os desenvolvedores esqueceram da necessidade de um token da API do GitHub para certas funcionalidades de sua aplicação até que um usuário reportou e eventualmente uma explicação fora adicionada.
- Encontre Roadmaps em pelo menos 3 projetos de software livre. Descreva os planos de curto e longo prazo desse projeto.
-
AniList: a curto prazo, trabalhar contra bugs porém é evidente que features voltadas a competição com plataformas rivais são visionadas.
-
NuxtJS: não possui um roadmap a longo prazo, prioriza trabalhar com issues para manter a estabilidade do projeto.
-
KoaJS: está desenvolvendo seu roadmap para a versão 3 em função de remover features depreciadas na versão 2.
- Selecione 5 projetos de software livre famosos (pelo menos 1000 estrelas) e coloque os links para seus respectivos site, repositório de código fonte, bug tracking e ferramentas de comunicação.
KoaJS
- Site: https://koajs.com/
- Código Fonte: https://github.com/koajs/koa
- Bug Tracking: https://github.com/koajs/koa/issues?q=is%3Aissue+is%3Aopen+sort%3Aupdated-desc
- Comunicação: https://webchat.freenode.net/?channels=#koajs
NuxtJS
- Site: https://nuxtjs.org/
- Código Fonte: https://github.com/nuxt/nuxt.js/
- Bug Tracking: https://github.com/nuxt/nuxt.js/issues
- Comunicação: https://cmty.app/nuxt
Knex
- Site: http://knexjs.org/
- Código Fonte: https://github.com/tgriesser/knex
- Bug Tracking: https://github.com/tgriesser/knex/issues?q=is%3Aissue+is%3Aopen+sort%3Aupdated-desc
- Comunicação: http://webchat.freenode.net/?channels=bookshelf
- Encontre 3 exemplos de pedidos de feature ou resolução de bugs que foram implementadas, coloque o link para elas e faça um relatório crítico sobre o fluxo: era bug ou feature? foi iniciado por um usuário ou desenvolvedor? os desenvolvedores foram reticentes ou abertos para a descrição realizada? houve pedido de mais informações? foi resolvido rapidamente ou demorou? houve algum impecilho técnico ou social para essa resolução? quem resolveu o problema foi um desenvolvedor experiente, novato ou algum usuário?
-
lubien/bookmarker#1 era bug ou feature? feature request foi iniciado por um usuário ou desenvolvedor? desenvolvedor os desenvolvedores foram reticentes ou abertos para a descrição realizada? abertos houve pedido de mais informações? não foi resolvido rapidamente ou demorou? demorou houve algum impecilho técnico ou social para essa resolução? não quem resolveu o problema foi um desenvolvedor experiente, novato ou algum usuário? desenvolvedor experiente
-
lubien/bookmarker#12 era bug ou feature? bug foi iniciado por um usuário ou desenvolvedor? usuário os desenvolvedores foram reticentes ou abertos para a descrição realizada? n/a houve pedido de mais informações? não foi resolvido rapidamente ou demorou? rapidamente houve algum impecilho técnico ou social para essa resolução? não quem resolveu o problema foi um desenvolvedor experiente, novato ou algum usuário? desenvolvedor novato
-
lubien/cerebro-reload#2 era bug ou feature? feature request foi iniciado por um usuário ou desenvolvedor? usuário os desenvolvedores foram reticentes ou abertos para a descrição realizada? reticentes houve pedido de mais informações? sim foi resolvido rapidamente ou demorou? rapidamente houve algum impecilho técnico ou social para essa resolução? não quem resolveu o problema foi um desenvolvedor experiente, novato ou algum usuário? desenvolvedor experiente
- Procure um projeto e indique um commit que contenha indícios da metodologia TDD (Test Driven Development), ou seja, o desenvolvedor enviou o código fonte com o teste no mesmo commit.
Adiciona sistema de autorização
- Biblioteca koa-jwt para tratar tokens no > cabeçalho Authorization
- Biblioteca jsonwebtoken para assinar tokens
- Adiciona rotas de GET e POST /api/auth para > ver usuário e login
- Criação do middleware isLoggedIn
- Separação de diferente usos do koa-body para > JSON e Multipart
- Adiciona os erros UNAUTHORIZED e INVALID_TOKEN
- Função auxiliar para geração de tokens em > testes em test-utils.js
- Criação dos casos de teste de para > autenticação
Vale salientar que o segredo dos tokens ainda é > mockado.
- Procure um projeto e indique um commit que tenha Refactor e qual informe o nome da técnica empregada durante o refactor.
Reutiliza middleware de body parsing no router.js
No commit fora reutilizado a referência de objetos para evitar a instanciação desnecessária de objetos com igual propósito.
A refatoração foi sustentada pelo fato que a equipe de desenvolvimento possuia uma bateria de testes para verificar as funcionalidades.
- Procure um projeto e aplique refactor em um código fonte, informe ao projeto com campo descrição do commit a técnica de refactor usada, envie sua correção ao projeto através de pull request.
Update deprecated Stream.filter_map/3 to Stream.filter/2 + Stream.map/2
- Informar o LOC de pelo menos 1 projeto usando a ferramenta cloc.
λ cloc cc55774
166 text files.
166 unique files.
14 files ignored.
github.com/AlDanial/cloc v 1.82 T=0.50 s (305.6 files/s, 55605.9 lines/s)
-------------------------------------------------------------------------------
Language files blank comment code
-------------------------------------------------------------------------------
JSON 3 0 0 16912
JavaScript 106 702 278 5604
Vuejs Component 33 331 4 3739
Markdown 9 31 0 52
YAML 1 0 0 4
-------------------------------------------------------------------------------
SUM: 152 1064 282 26311
-------------------------------------------------------------------------------
- Proponha pelo menos três métricas para avaliar um projeto de software livre.
- Entidade: Um monorepo.
- Qual o atributo: Fator de interdependência entre múltiplos pacotes em um monorepo.
Com o surgimento de cada vez mais monorepos justificados pela proximidade entre dependências entre projetos, uma complexidade nasce atrelada à necessidade de manter bibliotecas interdependentes em um projeto.
Exemplos imediatos são grandes monorepos como BabelJS ou em crescimento como Saber.land fora linguagens de programação que permitem a técnica como cidadão de primeira classe como Elixir e seus Umbrella Apps.
- Entidade: Um repositório.
- Qual o atributo: Custo do processo de manutenção.
Repositórios saturadors de features, vezes independentes, acabam por não ter como manter todas elas em um ambiente efêmero de desenvolvimento. Repositórios como refined-github optam por aceitar features quando as pessoas responsáveis pela implementação inicial aceitam dar manutenção quando necessário e "assinam" sua responsabilidade.
Como, quanto e onde isso impacta no processo de desenvolvimento?
- Entidade: Um mantenedor.
- Qual o atributo: A capacidade de um mantenedor revisar código vindo de terceiros.
Certos magos do software livre acabam por ativar uma armadilha de manter diferentes repos concorrentemente. Alguns deles até chegam a ter mais de mil repos que necessitam não só de manutenção como também de revisões de pull requests de terceiros.
Enquanto que o criador tem seu direito de tratar quaisquer entradas nos repois, talvez sua indisponibilidade possa causar um gargalo no crescimento de múltiplas features.
Quais mantenedores geram esse gargalo? Qual o tempo médio até uma feature ser implementada em função de atrasos de revisões?
- Implemente uma métrica para avaliar um projeto de software livre.
Usando a ferramenta plato o código de um projeto foi avaliado e o resultado pode ser visto aqui.