Automatização de tarefas repetitivas

[woliveiras]

Podemos adicionar um task runner como Gulp ou via NPM para automatizar tarefas repetitivas e subir um ambiente de desenvolvimento local.

Eu gostaria de fazer isso para contribuir com o projeto.

Só precisamos listar as tarefas repetitivas para automatizar, podemos levantar isso nessa issue.

O que eu vejo necessário olhando o código por cima:

• [ ] Um servidor local para testes
• [ ] Compilação do Sass
• [ ] Comprimir HTML
• [ ] Minificação de imagens
• [ ] Compactar o que for possível (JS, CSS)

[fititnt]

Eu sei que você está com vontade de fazer isso, mas, pelo menos por mais algum tempo, provavelmente vamos preferir deixar o mais simples possível para alguém que tenha pouca experiência poder contribuir.

Dentro do possível, pelo menos para o estado atual, em que temos apenas landing page, vamos procurar deixar isso mais simples pra permitir que até mesmo quem nunca fez um PR na vida possa fazer, mesmo que o PR seja pra acrescentar cidades.

[woliveiras]

Show de bola @fititnt

Acho a ideia perfeita para incluir gente nova no Open Source! :raised_hands:

[lapa182]

@fititnt mas isso não tem incluído nem em pegar o .scss atual e destrinchar em componentes? Tipo usando BEM/Atomic whatever? Pelo menos dividir o sass atual para fazer manutenção é uma boa.

[neysimoes]

@fititnt cara podemos montar uma automação com Gulp em passo-a-passo como rodar o projeto localmente e colocar links com as referências. Algo bem simples, só para rodar um server localhost e compilar o Sass.

Hoje o projeto tem Sass e não explica como compilar. Se alguém mandar PR mexendo no CSS gerado não ajudará muito.

O que acha de começarmos com uma automação simples e bem explicada?

[rcgivisiez]

@neysimoes nesse momento, pra essa versão do projeto, a Isa e eu vamos sugerir remover o SASS.

Pra você e pro resto do pessoal aqui: não quer dizer que não gostamos de SASS, mas tem gente que contribuiu com centros pokémon (que é o "carro chefe" da Ideia) e nem tem Ruby ou NPM instalado pra poder compilar SASS e poder fazer esse tipo de teste.

Eu concordo em mantermos bloqueado esse issue por enquanto.

[lapa182]

E por que não fazer um fork a partir desse projeto pra um v2 com as issues de automação e etc? No caso, no caso uma equipa ficaria responsável por sempre estar atualizando o v2 com o atual e enquanto isso acontece trabalhar em cima de melhorar, além de documentar claro pra ajudar a todos.

Apesar de já ter experiência, nunca realmente ajudei num projeto open source. Preprocessadores, ferramentas de npm/rvm (como gulp, grunt, sass, sass_lint) apesar de serem muito técnicos, para aqueles Front-Ends que estão começando é algo também essencial de saber hoje em dia. Tudo bem, todos precisam saber da base de CSS/HTML que sem isso não conseguem entender a facilidade que é ao usar preprocessadores e o quão essas ferramentas ajudam no desenvolvimento.

[rcgivisiez]

@lapa182 aonde você vê problema, eu vejo oportunidade. A Isadora é bem contra fazer código que não seja usado no mundo real, e eu concordo com ela.

Se as pessoas querem realmente usar pre-processadores, ou automatizar coisas, a gente pode criar outro projeto que também seja útil, dar oportunidade pra todo mundo.

Dai temos o melhor dos dois mundos.

[neysimoes]

Sou completamente contra estagnar desenvolvimento em detrimento de "inclusão" de mais pessoas. Acredito que isso seja um retrocesso.

Deveríamos ajudar a quem quer contribuir com o o projeto a aprender mais sobre tecnologias de alto nível e não nós limitarmos o projeto ao conhecimento dos iniciantes. Acredito que podemos fazer um passo-a-passo de como ajudar com o projeto e mostrar onde pesquisar sobre as tecnologias usadas.

Devemos levar os iniciantes que querem ajudar a aprender mais e não limitarmos as tecnologias usadas no projeto.

[fititnt]

@neysimoes não é sobre estagnar, é sobre inclusão digital; Se temos pessoas de skills diferentes, e tem várias soluções que podem servir para resolver o mesmo problema, e pessoas interessadas em resolver de formas diferentes, podemos, por decisão comum de todos, já no início do projeto, definir como ele deve ser, e se manter relativamente fiel ao projeto.

Convido vocês para em especial propor essas alterações em #48 , #49 e #50.

E criei o #52 especialmente para discutirmos sobre quais tecnologias usar quando houver duas possibilidades. Eu convido todos vocês a tomar essa decisão com a gente

[fititnt]

Pessoal, como o projeto está crescendo, estamos dividindo em diversos repositórios na organização em https://github.com/pokemongovet. Um repositório que é indiscutível que isso aqui é interessante é o https://github.com/pokemongovet/gerador-fotos-adocao

Não sei nesse momento se o melhor é apenas manter a label "bloqueado" ou se fechamos esse e outros issues que dependem um do outro. Fica uma dúvida se é melhor quebrar aos poucos ou quebrar de uma vez.

[saraiva1989]

Como o foco do projeto é manter o mais simples possível (html, css e javascript puro) talvez essa issue pode ser encerrada.

Vi alguns comentários dizendo que isso é estagnar o projeto, mas acredito que seja inclusão, pois quem está iniciando já tem dificuldade em lógica e entender como funciona algumas coisas de um projeto simples.

Se adicionar NPM, GULP entre outras coisas pode perder o foco de incluir pessoas iniciantes no projeto.

[woliveiras]

Faz sentido, mano