Colaborando
Existem várias maneiras de se colaborar com efetividade para este projeto. As principais, em ordem crescente de "custo" do seu tempo e relevância para o projeto são:
- participando das discussões através do seu voto de endosso;
- participando das discussões ativamente, postando comentários;
- colaborando com trabalho nas planilhas, ou colaborando com trabalho no git (pull requests).
A seguir detalhes sobre cada uma delas.
O termo issue pode ser traduzido para incidente, tipo "telefone de reclamações" onde alguém registra o incidente. Se você descobre uma falha no vocabulário LexML, então tem onde reclamar: é no sistema de gestão de issues do lexml-vocabulary. O fundamento do sistema é a identificação única e controlada do seu chamado, que ganha um "ticket do chamado", aqui denominado issue number (por ex. #7). Mas esse ticket pode também ser relativo a uma ideia nova e bacana para melhorar o lexml-vocabulary, que não tem nada de falha ou reclamação... Tudo são issues.
Como aqui não é uma empresa, é um coletivo voluntário que cuida do projeto, então o cliente ou "consumidor" do projeto é também um potencial "fornecedor" do projeto... Não há um posicionamento tão rígido nos papeis, não basta reclamar nem dar uma ideia: precisa participar para fazer acontecer.
Outra forma de imaginar a interface aqui das issues, é que acaba sendo uma espécie de fórum de discussão das pessoas da comunidade LexML. Veja o Guia completo de como usar todos os recursos da interface de issues, inclusive habilitando a interação por e-mail (!).
Não morremos de amor pelo Github, poderíamos estar usando Gitlab ou qualquer outro... Mas optamos por Github. Um dos pré-requisitos é ter conta no Github: siga as instruções aqui ou clicando no botão de "sign-up". Daí em diante sempre lembrar de logar, ou deixar sempre logado (é seguro).
Tudo o que apresentamos neste guia de colaboração, o que se apresenta nos demais guias de participação, demanda e vai pressupor que você esteja logado.
Na prática são 5 passos simples, de navegação e preenchimento de formulário. Veja o Guia aqui.
Mas e o conteúdo da issue? O que podemos fazer e como é melhor fazer? Não temos regras especiais, é muito parecido como um fórum de discussão mesmo. Se ainda assim se sente "peixe fora da água", veja alguns exemplos, navegue por entre issues novas e velhas deste projeto, para ter uma amostra do "espírito da coisa".
Depois que postar sua nova issue, um mediador do projeto fará ajustes e rotulará do que se trata: temos labels (rótulos) para as issues. Pense sempre em elaborar um texto objetivo com um (apenas um) dos seguintes focos:
- Dúvida: apenas faça a pergunta, acrescentando exemplos se necessário.
- Falha: descreva alguma falha que tenha observado no projeto ou nos vocabulários LexML.
- Melhora: descreva a sua sugestão de melhora.
Tão importante quanto criar uma issue relevante, é postar um comentário relevante numa das issues já criadas.
Precisa estar logado, aí aparece a caixinha de resposta embaixo, com o botão verde "Comment", para postar o seu comentário. Se deseja um texto mais elaborado, aproveite os botões de edição,
Senão é só decorar aluns comandos como o negrito que se faz digitando **negrito**... Maiores detalhes aqui.
As pessoas da comunidade LexML podem discutir as issues... Às vezes, existem pontos complexos e matizados, mas outras vezes você só quer dar seu voto de "+1" ou "-1" no comentário de outra pessoa. E pode até manifestar outras reações (como amar, odiar, etc.) às conversas, expressando os seus sentimentos de forma mais simples e eficaz.
O voto (joinha) de qualquer forma é reconhecido neste projeto como um endosso ao ponto de vista manifesto pelo comentário, principalmente quando se trata de alguma decisão de projeto.
Esta planilha colaborativa com todos os vocabulários LexML é a interface amigável para os arquivos CSV (planilhas em formato aberto), para os usuários não-técnicos. O procedimento geral, para leigos e não-leigos é:
- Editar na planilha colaborativa a modificação desejada (sem medo!)
- Algum usuário "mais nerd" (ou você) baixa a planilha para o repositório e submete as modificações como pull-request, já dizendo num resumo quais seriam as modificações. 3 .. Daí em diante é como o git (ver abaixo)
... não é difícil, e todos estão convidados! Mas não são todos que se sentem "suficientemente nerds" para usar o git...
1 ... 2.... 3. Os mantenedores (e você) podem discutir o pull-request: fica como que "em consulta pública" por um ou mais dias, conforme o tamanho ou impacto da modificação. 4. O pull-request é aceito (é realizado um commit), e eventualmente justificará ser retulado como nova versão.