- Caio Shimada Rabello (xcaiosr@gmail.com, @caiosr)
- Leonardo Barbosa Furtado (srleonardofurtado@gmail.com, @leonardofurtado)
- Atividade01: link aqui
- Projeto escolhido: PyGithub
-
Contribuidores novatos: jdufresne, cclauss, mstuttgart e vishalsodani pois realizaram commits recentes entre 2018-2019.
-
Contribuidores chave: jacquev6 (criador do projeto) que possui maior parte dos commits na história do projeto (936 commits em comparação ao segundo maior com 69 commits), sfdye (segundo maior contribuidor) que possui um papel forte na manutenção e não somente no desenvolvimento do código, em destaque a avaliando novos pull requests; e s-t-e-v-e-n-k que, apesar de ter começado a contribuir ativamente ao projeto durante o último ano, se tornou o quarto maior contribuidor ao projeto.
-
Sugestão de tarefas: está descrita no ReadMe do projeto na seção “Maintainership” detalhando que tipo de mantenedores estão sendo procurados. No projeto os mantenedores devem realizar triagem de issues, pull requests e cut releases. Pessoas que trabalham em projetos que utilizam o PyGithub e tem interesse em auxiliar eu seu desenvolvimento podem enviar um email a alguém do arquivo de Mantenedores.
-
- 404: Not Found
-
Análise geral da página inicial do projeto PyGithub
- Possui passo a passo para instalação na página seção de introdução da página inicial.
- Possui documentação em formato de exemplos dos métodos do projeto na seção de exemplos da página inicial, bem como uma página de referência.
- Não possui tradução, somente uma versão em inglês.
- A descrição de como contribuir não está na página do projeto, somente em seu repositório no github no arquivo CONTRIBUTING.md.
-
Teste de documentação do projeto Folium
- Seguindo o passo a passo da documentação de contribuição, foi identificado no passo 4 que não existe uma orientação para usar os arquivos requirements.txt para instalação de dependências.
- Após conseguir instalar as dependências, foi identificado que existe uma dependência que não está informada no arquivo requirements.txt e nem no arquivo adicional requirements-dev.txt.
-
Edição de arquivo descritivo (CONTRIBUTING.md) do projeto Folium.
-
Sobre projetos sem licença
- De acordo com choosealicense, um projeto sem licença, em geral, não pode ser copiado, modificado distribuído por terceiros sem o risco de consequências como “take-downs”, “shake-downs” e “litigation”. Mesmo em casos onde o autor aceitou os termos de uso se algum site de repositório como o GitHub, ter aceitado que o código pode ser copiado e utilizado por terceiros não é suficiente para isso, nesse caso, a licença ainda é necessário.
-
Licença utilizada nesse repositório
- Creative Commons Attribution 4.0 International: Normalmente voltada para fins educacionais e de mídia, sem fins de compartilhamento de software. Ela é descrita como tendo um conjunto de termos que autores podem utilizar para compartilhar trabalhos originais sujeitos a direitos autorais e outros direitos mais detalhados ao longo da licença.
-
Sugestão de inclusão de licença
- 404: Not Found
-
Linter
- Linter é uma ferramenta que inspeciona códigos para identificar erros de programação, erros de estilo, erros de construção, chamadas de funções obsoletas etc. Um exemplo de Linter é o Pylint, que pode ser integrado com uma editor de texto ou IDE como Atom, Visual Studio Code e Vim.
-
Guias de Boas Práticas para linguagens de programação
-
Guia de Boas Práticas para frameworks
-
Definição de Métodos Ágeis
- É um modelo criado com o fim de flexibilizar a acelerar o processo de desenvolvimento de um software, funcionando, diferentemente do modo cascata, com diversos ciclos de desenvolvimento, promovendo a melhoria contínua do processo. Como por meio desse modelo o processo de desenvolvimento é mais dinâmico, isto é, está em melhoria contínua, sendo reavaliado e adaptado constantemente, um produto consegue ser entregue com qualidade superior e mais rapidamente. Para que ele possa ser empregado corretamente e efetivamente, foi-se criado, então, o manifesto ágil contendo os princípios e valores do método.
-
Por que utilizar testes unitários?
- Devido a necessidade de sempre adicionar funcionalidades ou realizar alterações que realmente funcionem, há a necessidade de sempre testar os métodos implementados ou alterados através de testes unitários para manter o funcionamento do projeto em questão, principalmente quando esse projeto está sendo desenvolvido por vários indivíduos.
-
Quais as vantages de utilizar integração contínua?
- A integração contínua possui a finalidade de sempre manter o projeto ou uma branch específica atualizada, isto é, sempre estar integrando novas funcionalidades ou alterações ao projeto para que diminua a probabilidade de outros desenvolvedores trabalharem em uma versão desatualizada do projeto acidentalmente devido a não integração de alguma mudança por outro(s) desenvolvedor(es).
-
Pull request com adição de função na calculadora
-
Pull request com conserto de falha de build
-
Truck Factor x Heroes
- O Truck Factor analisa quais as pessoas VITAIS para o funcionamento de um projeto, logo, quanto maior o Truck Factor, menos perigo corre o projeto; enquanto que Heroes são os 20% ou menos que possuem 80% ou mais das contribuições. Pode-se dizer que o Truck Factor é mais restritivo, pois uma pessoa que contribui muito não necessariamente é vital ao projeto. Logo, apesar deles possivelmente incluírem uma ou outra mesma pessoa, suas finalidades são diferentes. Apesar de parecer que os Heroes são uma existência negativa ao projeto, um estudo de abril/2019 mostra que, na verdade, sua existência é positiva a saúde do projeto, haja vista que, dentre outros benefícios, Heroes normalmente possuem uma qualidade de código superior e contribuem muito mais com comunicação com outros desenvolvedores.
-
Porque meios de qualidade de software tradicionais têm pouca aderência.
- A medição de qualidade de um projeto tradicional objetiva em definir detalhadamente os custos, recursos humanos, não humanos, cronograma, além da qualidade do código. Além de questões como cronograma e orçamento não entrarem na análise de qualidade (haja vista que um projeto de software livre não possui data de fim, é um projeto em constante evolução), os recursos humanos requerem uma atenção muito maior em um software livre devido ao fato dele ser aberto e não definirem um ‘contrato’ de responsabilidade a ele diferentemente em um projeto tradicional onde há o contrato de EMPREGO, isto é, em um software livre, o desenvolvedor pode, em geral, ‘se demitir’ quando quiser. Logo, um software livre requer uma atenção ao recursos humanos tão grande quanto ao código, e devido a forma como softwares livres funcionam, as formas de medir e de aprimorar esse ponto é muito mais complexo que em um projeto tradicional.
-
Retorno da ferramenta cloc no projeto Julia
- 914 arquivos
- 46876 linhas em branco
- 22785 linhas comentadas
- 307226 linhas de código
-
Propostas de métricas para projetos de software livre
- Licença: Número de licenças adotadas pelo projeto. Quanto mais e mais divergentes entre si, maior a probabilidade de ocorrer alguma incopatibilidade de licença por outro projeto que o use, mas possibilita outros usos para o código dependendo do objetivo de importação.
- Heroes: Número de desenvolvedores com mais de 80% das contribuições.
- Facilidade para se envolver: Relação de contribuições (de preferência por não heroes) por número de forks; Relação de pull requests aceitos por pull requests negados; Quantidade de issues com a label "good first issue" ou "mentoring", por exemplo, em aberto. Analisa a facilidade de um novo contribuidor se juntar ao projeto.
-
O repositório qtbase, por exemplo, possui diversas licenças, umas para uso livre, outra para uso comercial.