aboutsummaryrefslogtreecommitdiff
diff options
context:
space:
mode:
authorSecurity Workgroup <seguranca@sarava.org>2014-02-02 13:01:37 -0200
committerSecurity Workgroup <seguranca@sarava.org>2014-02-02 13:01:37 -0200
commita5867892bd7c37efd662a8e47a7b3f634d27db11 (patch)
tree09123734d51a7fb6f848cf36fdc21aeb8e50693a
parent1329fa1ec8a0d5319e8005ad95daf44ddd2a88e3 (diff)
downloadseguranca-a5867892bd7c37efd662a8e47a7b3f634d27db11.tar.gz
seguranca-a5867892bd7c37efd662a8e47a7b3f634d27db11.tar.bz2
Chamado 2014 para documentacao
-rw-r--r--chamado.mdwn137
1 files changed, 137 insertions, 0 deletions
diff --git a/chamado.mdwn b/chamado.mdwn
new file mode 100644
index 0000000..41e035c
--- /dev/null
+++ b/chamado.mdwn
@@ -0,0 +1,137 @@
+[[!toc levels=4]]
+
+Colabore com uma documentação sobre Segurança e Privacidade!
+============================================================
+
+Os Grupos de Trabalho em Segurança e Privacidade são uma iniciativa independente para orientar pessoas e grupos sobre segurança, privacidade e direitos civis na era da vigilância de massas.
+
+Convidamos grupos e pessoas a colaborar com a elaboração do nosso Manual de Segurança! - https://manual.sarava.org
+
+Queremos produzir uma documentação de referência:
+
+1. Em copyleft.
+2. Com texto, mas também com imagens e vídeos!
+3. Facilmente replicável, editável e conversível para diferentes formatos.
+4. Facilmente desmontável e re-arranjável, podendo derivar documentações diversas dependendo da necessidade.
+5. Com alto padrão de qualidade e que possa ser uma boa referência.
+6. Cujo conteúdo possa ser verificado criptograficamente!
+
+Como posso ajudar?
+------------------
+
+Não importa seu nível de conhecimento de tecnologia! Basta ter vontade e um pouco de tempo livre para se dedicar!
+
+1. Qualquer pessoa ou organização pode contribuir em grupos de trabalho específicos para cada assunto.
+2. O trabalho é voluntário, mas nada impede que grupos e pessoas encontrem formas de financiamento para se manterem, mas isso não deve ser feito no âmbito dos GTs em Segurança e Privacidade.
+3. Não há burocracia para entrar nem para sair: faz quem quer, sendo que o único comprometimento é o formato padrão de documentação.
+4. Contribuições anônimas também são aceitas :)
+
+Veja a seção "Metodologia e fluxo de trabalho" para mais informações e acesse também https://seguranca.sarava.org e https://saravea.net/g/seguranca.
+
+Cronograma 2014
+---------------
+
+1. Final de janeiro:
+ 1. [Este documento finalizado](https://saravea.net/tasks/view/15429/chamado-para-colaboracao)
+ 2. [Padrão de documentação](concebido: https://saravea.net/tasks/view/10705/definicao-de-padrao)
+ 3. [Site de desenvolvimento configurado](https://saravea.net/tasks/view/15423/site-de-desenvolvimento)
+ 4. Convidar editores(as)/coordenadores(as) para cada documentação do eixo de Ferramentas.
+2. Início de fevereiro:
+ 1. Lançamento deste chamado.
+ 2. Início da documentação do eixo de Ferramentas.
+ 3. Início da documentação de texto para o público ativista.
+ 4. Início da documentação de texto para o cenário de ataques e vulnerabilidades para grupos de mobilização.
+3. Maio: revisão.
+4. Junho: lançamento da primeira versão.
+5. Julho em diante: segundo ciclo de documentação.
+
+Metodologia e fluxo de trabalho
+-------------------------------
+
+Acreditamos no espírito e na forma de desenvolvimento dos Softwares Livres para avançar nosso trabalho:
+
+1. Os diversos temas serão divididos em Grupos de Trabalho (GTs) específicos para que o trabalho ocorra em paralelo.
+2. Cada GT é coordenado por "editores(as)", que são responsáveis pelo andamento da documentação e checagem de prazos.
+3. Pessoas com conhecimento apropriado ficam a cargo de revisar e assinar digitalmente a documentação, buscando padronizar termos técnicos traduzidos assim como adequação funcional/conceitual da ferramenta e adequação ao formato-padrão de disposição da documentação, garantindo a integridade e a qualidade do material.
+4. É encorajado que a documentação produzida seja incorporada à documentação oficial de cada software (upstream) e que as comunidades já existentes sejam convidadas para colaborar.
+5. A documentação é feita um sistema wiki capaz de exportação em vários formatos, usando controle de versão Git e fácilmente espelhável.
+6. A Licença de Uso da documentação deve respeitar a licença de uso original, no caso das documentações oficiais, e ser aberta no caso das outras. Na ausência de documentação oficial, o material será licenciado duplamente em GNU LGPLv3 e Creative Commons BY-SA.
+7. A documentação será modular o suficiente para facilitar a criação de obras derivadas que contenham apenas partes ou remixagens de acordo com a necessidade de uso.
+
+Implicitamente ao trabalho de documentação, as seguintes tarefas podem ser realizadas:
+
+1. Testes e avaliações de cada programa.
+2. Tradução da interface de cada programa.
+3. Tradução da documentação oficial de cada programa (que, dependendo do caso, pode ser a mesma das documentações acima citadas).
+
+Padrão de documentação
+----------------------
+
+A documentação de ferramentas deve seguir um padrão de organização e identidade comum, tendo as seguintes seções:
+
+* Introdução, para quem tem 5 minutos para entender do que se trata:
+ * Resumo da ferramenta.
+ * No que a ferramenta te protege.
+ * No que a proteção daquela ferramenta é limitada.
+ * Recomendação de outras ferramentas para serem usadas em conjunto.
+ * Tópicos (tags) relacionadas.
+* Roteiro de Uso, para quem quer testar/usar/instalar aquela ferramenta e tem uns 45 minutos disponíveis:
+ * Tutorial passo-a-passo, com texto e fotos com 10 a 20 etapas necessárias para instalar, configurar e utilizar a ferramenta.
+ * Screencast explicativo de instalação e configuração.
+* Guia detalhado, para quem quer ir a fundo:
+ * Histórico de quem criou a ferramenta.
+ * Conceito de funcionamento da ferramenta.
+ * Vulnerabilidades encontradas no passado,
+ * Auditorias que já foram realizadas no código-fonte da ferramenta.
+ * Guia para uso avançado.
+ * Como pedir ajuda/reportar bugs do software, comunidades existentes (especialmente em língua portuguesa).
+
+A documentação precisa ser escrita no seguinte padrão:
+
+1. Formatação [Markdown](https://pt.wikipedia.org/wiki/Markdown).
+2. Uso de linguagem inclusiva de gênero.
+
+Redação e revisão:
+
+1. A redação pode ser realizada do modo mais apropriado para cada grupo de trabalho, usando editores compartilhados, listas de email, etc.
+2. A documentação será integrada num ambiente de desenvolvimento localizado em: https://manualdev.sarava.org
+3. Após a revisão e validação, a documentação é integrada ao espelho oficial, em https://manual.sarava.org
+
+Eixos de trabalho
+-----------------
+
+Para que o manual consista num guia que englobe aspectos técnicos, políticos, culturais e sociais, os seguintes eixos foram considerados:
+
+1. Ferramentas
+2. Público interessado
+3. Cenários de ataques e vulnerabilidades
+
+Para o primeiro ciclo de desenvolvimento da documentação será abordado apenas um conjunto de ferramentas.
+
+### Ferramentas
+
+Ferramentas iniciais (vide https://saravea.net/tasks/view/10695/topicos):
+
+* Segurança digital básica
+ * Senhas
+ * Introdução à criptografia simétrica e assimétrica
+ * OpenPGP
+ * Criptografia de disco
+* Navegação web
+ * Rastreamento de usuários
+ * HTTPS/SSL
+* Email
+ * TLS
+ * Thunderbird com Enigmail
+* Anonimato
+ * Tor
+ * Tails
+ * OnionPi?
+* Comunicação instantânea
+ * Pidgin: Jabber e OTR
+ * Mumble
+ * Jitsi com jabber?
+ * Jitsi com Ostel?
+* Telefonia:
+ * Problemas inerentes à telefonia.
+ * Suite Guardian Project, como Ostel e ChatSecure?