Contributing #201
Comments
|
Bem legal @williamespindola! Vou colocar como referência um
https://github.com/metabase/metabase/blob/master/docs/contributing.md |
|
Acho bem legal isso.
Mas acho mais importantes que essas orientações 2 coisas.
1-um manual de desenvolvimento, aonde é apresentada as tecnologias usadas
(pois a documentação da tecnologia se torna tbm documentação do projeto) e
estruturação do projeto. (Descrição de apis, se tiver)
2-um pouco de direcionamento, quais issues estão abertas para que a pessoa
que vai contribuir saber quais demandas existe.
(Apesar do sistema de issues uma pessoa que está chegando não visualiza
facilmente o que está planejado [roadmap] e muito menos quais são os
gargalos [milestones] para se atingir esses objetivos.)
Então explicitar o problema e ilustrar com um resumo do diálogo que foi
feito , facilita a pessoa a entender o contexto e poder participar.
Essas 2 coisas são facilitadoras.
Os guidelines como testes,patchs são dificuldades a mais (apesar de legais,
principalmente por educar, mas não fomentam a contribuição, acho)
Meus 0.20 cents
Em Qui, 7 de jun de 2018 6:13 PM, Fernando Paiva <notifications@github.com>
escreveu:
… Bem legal @williamespindola <https://github.com/williamespindola>! Vou
colocar como referência um contributing.md de um projeto aberto que
usamos aqui na Fundação Lemann. Ele é um pouco diferente do seu, é mais
high-level mas tem uns pontos que acho bem interessante:
1. Define a visão do produto
2. Explica o processo de construção do produto (aqui dentro desse
processo fala de coding standard e code review)
3. Explica formas de contribuição (necessidades do usuário, código,
documentação)
https://github.com/metabase/metabase/blob/master/docs/contributing.md
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
<#201 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AA-OQzR3g3Nz32pJB4iR8UxgqXB4achZks5t6ZdggaJpZM4Ub69q>
.
|
|
@JDias Poderia reorganizar seu comentário? |
|
@farribeiro !?!? |
|
Estava no FastHUB e via tudo em uma única linha @JDias Entre para o Slack você também! |
|
É, pelo celular eu tbm. 😊
Em Qui, 7 de jun de 2018 7:20 PM, Fábio Rodrigues Ribeiro <
notifications@github.com> escreveu:
… Estava no FastHUB e via tudo em uma única linha
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#201 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AA-OQwkCrlgxCaD6ZbMu_z4we8KR7pBLks5t6adAgaJpZM4Ub69q>
.
|
|
Voltando ao assunto, eu seria favorável a ter um "contrib" em um branch experimental, labs. https://github.com/ezrec/AROS-mirror/tree/ABI_V1/binaries/logo-contest |
|
@JDias e @fernandosjp Logo mais teremos, ainda não tenho visão do produto para colocar pontos como estes, por isto foquei na parte técnica e padronização que a comunidade ja usa. Logo mais quando as contribuições começarem a andar adicionamos estes pontos. Até porque exemplificar como criar algumas coisas com usando a estrutura de código que temos hoje é retrabalho. Muita coisa precisa ser refatorada. |
|
Obrigado pelo PR @farribeiro |
|
O @eberfreitas está trabalhando num doc bem detalhado sobre contribuição. Em breve colocaremos ele aqui numa versão que vai requerer evolução contínua. @JDias não precisa de um branch sem regra. A pessoa pode usar um fork para fazer as suas brincadeiras e testes e só abrir issue e pull request do que testou e viu funcionando. O que acha? @williamespindola logo logo vamos ter o manual do produto, inclusive com ilustrações de como usar. Vai facilitar muito a questão de ter a visão de produto. |
|
Olá @MarceloCajueiro , isso sim, com certeza. O que falei vai na linha de uma referência que fizeram ao "contributing" do ruby. O que comentei é que as vezes alguem desenvolve algo interessante, mas inacabado. Na referência a pessoa explica os custos implícitos de aceitar, mas o caso deles não é o i-educar. A comunidade do i-educar é muito menor. O que sugeri é que houvesse a possibilidade de receber contribuições inacabadas, pois as vezes o código explicar melhor do que o texto. E alguém com mais traquejo em testes, formating, documentação podem elaborar. No caso do ruby o volume de "avaliação e refino" da contribuição seria alto, por causa do tamanho do volume, que não acredito que seja o caso do i-educar... Por exemplo, se alguém portar um pedaço do i-educar para o laravel ou fizer um tema, conjunto de views, para o i-educar, ou coisas assim, mesmo que inacabados servem de indicação. (Inspiração) Talvez apenas um txt com link para os repos aonde estão acontecendo as brincadeiras? |
|
Apesar desse repo ser da portabilis/i-educar acho que o escopo deveria ser o sistema de gerenciamento de escolas, não o código do i-educar, mas isso é uma decisão "pessoal" que vocês tem que refletir, acho. |
|
@JDias sim, faz sentido ter coisas inacabadas em aberto, até para pedir ajuda. Vamos pensar em como organizar isso. @JDias já sobre discussões, aqui vamos discutir ambos os assuntos, código e gestão escolar. Em breve teremos um fórum onde vamos poderemos categorizar melhor. O Github é um catalizador de desenvolvedores. É inevitável que o foco aqui não seja o código. O código é um meio para o produto final. Sem um código de qualidade, com poucos bugs e fácil manutenibilidade, não se tem um sistema de gestão bom. Vamos todos avançando em todos os assuntos necessários. |
|
eu comentei um vez com a @carolinesalib (que eu vou ser eternamente grato por ter me falado sobre o laravel :) ) sobre forum, vou colocar novamente aqui o que eu vi que achei interessante @MarceloCajueiro usando o github como forum: https://github.com/laravelbrasil/forum ou, se quiser algo mais robusto eu gostei do: https://github.com/discourse/discourse esses foram os que eu vi, pode ser que tenha opções melhores. |
|
Tem mais um ponto que quero propor para o Contributing. Vi que o pessoal esta fazendo prs com muitos commits. Seria legal se os commits fossem atomicos, ou seja cada commit representa uma funcionalidade, um valor, algo que seja entregavel e funcional. Isto ajuda até na entrega das features. |
|
Gostou do meu jeito de commitar? |
|
Como o @MarceloCajueiro comentou aqui andei trabalhando numa versão do guia de contribução usando um bocado do que foi discutido por aqui e outras fontes. Se puderem, dêem uma olhara em #219. Obrigado! |
|
Fechar ISSUE... |
|
Vlw |
É importante manter algumas regras, aqui é um punhado do que a própria comunidade PHP usa nos projetos, algumas coisas podem parecer "chatas", mas quando mais alinhado estiver o código, todos se beneficiarão.
Este seria o conteúdo nosso arquivo CONTRIBUTING.md
Contribuindo
Contribuições são bem vindas e sempre são devidamente creditadas. Você pode facilmente enviar suas contribuições través de pull requests no Github.
Devido a limitação de tempo, nem sempre estamos disponíveis para responder rapidamente como queríamos, por favor não leve para o lado pessoal.
Antes de enviar qualquer feature ou bug fix:
Antes de enviar um Pull Request
** Você deve conhecer sobre PHP-FIG** nós usamos padrões como PSR-2 Coding Standard - Verifique o estilo do código com:
vendor/bin/php-cs-fixer fix.Adicione testes - Seu path não será aceito se não tiver testes.
Documente qualquer comportamento - Tenha certeza que
README.mde qualquer outro documento relevante esteja atualizado.Considere nosso ciclo de lançamento - Nós seguimos SemVer v2.0.0. Quebrar aleatoriamente APIs públicas não é uma opção.
Um pull request por feature - Se você quiser fazer mais de uma coisa, envie várias pull requests.
** Envie um histórico coerente** - Tenha certeza que cada commit em seu pull request seja significativo. Se você tivesse que fazer vários commits intermediários enquanto desenvolvendo, or favor execute um squash antes de submeter.
Executando destes
$ composer testBom código!
The text was updated successfully, but these errors were encountered: