Fluxo de trabalho do inclusao-digital (primeira fase)

[fititnt]

Esse issue é para discutir/documentar/testar um fluxo de trabalho de como gerenciar conteúdo adicionado/alterado no repositório, foco na primeira fase.

No momento em que ele é escrito, o repositório está em fititnt/inclusao-digital/ (ainda privado, todos os convidados tem permissão de escrita no ramo master) e o site é servido na URL https://inclusao.etica.ai/.

Os marcadores dos issues tiveram poucas alterações, no caso foi criado apenas links-discussao-facebook e Situacao: confirmado, conforme print screen a seguir:

[fititnt]

Não está perfeito, mas já é uma evolução a questão dos marcadores. Na dúvida deixei maioria das cores em cinza, mas pode ser alterado depois.

[fititnt]

Pessoal, a questão de "muito controle" ou "pouco controle" sobre fluxo de trabalho pode depender de testes. Porém pelo menos inicialmente, diferente do que estava acontecendo antes de criar esse topico, suponho que primeira leva acabará sendo

1. Issues e marcadores ficarão com mais mais subdivisões
   • pode-se reduzir depois excessos; agora seriam testes
2. As pessoas que colaborarem nesse teste de processo não precisam continuar ajudando depois
   • o principal motivo é a gente ver o que daria ou não certo e poder até trocar feedback de forma privada
   • as pessoas que quiserem permanecer interagindo, podem acabar optando por assumir outro papel
     • em geral eu tendo a permanecer fazendo os papeis que não se tem pessoal para fazer
3. Uma tag especial, good-first-issue tenderá a ser especialmente documentada, a ponto de talvez até mesmo permitir copia e cola, e pelo menos por um período razoável deveriam ser deixadas para quem ainda não interagiu com projeto
   • Um bom exemplo são issues que permitem a pessoa fazer o primeiro commit de código
   • Esse tipo de issue pode ser muito bom para convidar amigos a fazerem primeira contribuição aqui, porém já fazer todo acompanhamento ao ponto de até mesmo ensinar para pessoa como usar a interface do GitHub, o que escrever de mensagem, etc (esse tipo de conhecimento acaba sendo mais importante do que o texto que seria adicionado)
   • Tem um projeto que eu tambem sou um dos admins, o pokemongovet/pokemongovet.github.io, que é especialmente otimizado para quem entra no Open Source, então creio que podemos repetir parte desse tipo de experiência aqui.
4. Caso haja mais de uma alternativa, escolher as valorizam trabalho principalmente de quem não faz commit no repositório principal
   • isso possivelmente implique em nem mesmo meu nome aparecer de forma diferente/proeminente
   • isso também implica em valorizar em especial o papel das pessoas que fazem testes de aplicativos

Tem outros pontos que não seriam uma mudança em relação ao proposito inicial do projeto, porém vou repetir eles aqui (até porque quem for ajudar pode acabar vendo isso aqui e não os demais issues)

1. O projeto vai permanecer focado em internacionalização
   • Página da wikipedia sobre o tema https://pt.wikipedia.org/wiki/Internacionaliza%C3%A7%C3%A3o_(inform%C3%A1tica)
   • De forma resumida, isso implica em decisões como
     • O resultado final deve ser mais fácil para quem quer traduzir e adaptar as realidades locais dos respectivos países que falam aquela língua
     • Que o repositório reusaria muito snippets de páginas da wikipedia (pense primeiro parágrafo de um tema, mesmo que o parágrafo seja meio ruim)
     • Se algo que consumir texto for realmente muito necessário, pode valer a pena deixar em repositório externo, e não escrever o repositório principal de forma que ele pareça requerer esse recurso externo
2. Site otimizado para prover uma boa/ótima experiência a visitantes de internet Free Basics
   • Vide issue Processo de inclusão no Free Basics / internet.org (acesso gratuito) #1
   • De forma resumida, isso implica em decisões como
     • Mensagens de commits podem ter referência a links externos, issues, etc, mas o texto da página final deve evitar fazer referências a links externos que não forem o objetivo fim do usuário (como o link para baixar aplicativo a URL de um serviço que é propagandeada; um exemplo seria evitar ter links no resultado final da página para issues do GitHub
       • Nota: o código fonte final ainda poderia conter <!-- comentários -->

[fititnt]

Criei o issue #30.

Creio que também vou aproveitar para fazer um teste de fluxo de trabalho, onde eu também fico menos ligado a fazer commits no repositório e um pouco mais em pegar o que deve ser incluído. De certa forma uma das consequências dele seria até mesmo pessoal que poderia comitar em projetos como o inclusao-digital.