Fix: convert to MkDocs

92 files changed, 5483 insertions, 0 deletions

diff --git a/docs/atividades/README.md b/docs/atividades/README.md
new file mode 100644
index 0000000..445508e
--- /dev/null
+++ b/docs/atividades/README.md
@@ -0,0 +1 @@
+# Atividades
diff --git a/docs/atividades/casa/README.md b/docs/atividades/casa/README.md
new file mode 100644
index 0000000..6d50339
--- /dev/null
+++ b/docs/atividades/casa/README.md
@@ -0,0 +1 @@
+# Casa & Jardim
diff --git a/docs/atividades/casa/checklist.md b/docs/atividades/casa/checklist.md
new file mode 100644
index 0000000..ddd5afa
--- /dev/null
+++ b/docs/atividades/casa/checklist.md
@@ -0,0 +1,53 @@
+# Checklist Doméstico Básico
+
+Pagamentos mensais
+------------------
+
+* Água.
+* Luz.
+* Gás.
+* Internet.
+
+Organização
+-----------
+
+* Fósforos.
+* Esterilizador (potabilizador) de água e filtro.
+* Água potável e comida para um mês.
+* Reserva de comida de último recurso com validade longa (enlatados, proteínas, etc).
+* Rádio portável a pilha ou manivela.
+* Kit médico.
+* Lista de contatos impressa.
+* Caixa de ferramentas.
+* OpenHouse.
+* Comissão aperiódica de reforma, renovação/rotação de estoques e descarte.
+* Bota-fora.
+
+Básico pessoal
+--------------
+
+* Kit de higiene completo.
+* Roupas de cama, toalhas de corpo e rosto.
+* Rede de dormir.
+* Tatames tradicionais japoneses (empilháveis) (para dormir/sentar) e travesseiros.
+* Bancada (caveletes, tábua, mesa, tomadas, carregadores, luminárias).
+* Sacola de roupa suja.
+* Arara de roupas.
+* Caixa pra festinhas.
+* Caixa de roupas.
+* Caixa de utensílios/acessórios, por exemplo:
+  * Bomba de ar.
+  * Kit de reparos de pneus.
+  * Jogo de ferramentas.
+  * Baterias para luz de bicicleta.
+  * Miscelânea de informática (cabos, adaptadores, pendrives).
+  * Sacolas, fita silver tape / black tape, papelaria.
+  * Protetores auriculares.
+  * Trocados.
+* Caixa de equipamentos.
+* Suporte para bicicleta.
+
+Referências
+-----------
+
+* [What are the essential items to stockpile in the face of impending nuclear disaster?](http://www.newstatesman.com/politics/uk/2017/08/what-are-essential-items-stockpile-face-impending-nuclear-disaster).
diff --git a/docs/atividades/casa/procedimentos.md b/docs/atividades/casa/procedimentos.md
new file mode 100644
index 0000000..00274df
--- /dev/null
+++ b/docs/atividades/casa/procedimentos.md
@@ -0,0 +1,87 @@
+# Procedimento padrão de limpeza ou reforma
+
+- Para o serviço 30 minutos antes do expediente para limpeza do local e das ferramentas.
+- Avisar com antecedência a necessidade de mais material.
+- Manter o ambiente sempre organizado, isso economiza tempo, evita perdas e deixa o ambiente menos carregado.
+- Não sujar.
+- Não danificar coisas.
+- Trabalhar com cuidado e sem pressa.
+- Forrar tudo.
+
+Ciclo de trabalho
+-----------------
+
+- No caso de reformas, isolar a área a ser trabalhada
+- No primeiro dia, juntar o material, forrar e preparar o ambiente
+- Tipos de sessão:
+  - Curtas: realizar sessões com objetivos pontuais, para que seja possível realizá-las ao longo dos dias entre outras atividades.
+  - Contínuas: força-tarefa concentradas num único local.
+
+Recomendações gerais
+--------------------
+
+- Macacão
+- Saco/lata de lixo
+- Lona
+- Vassoura e pá
+- Panos
+- Porta-ferramentas e peças
+- Procurar manter as mãos limpas
+- Antes de quebrar qualquer coisa, entre em contato e pergunte se pode
+- Antes de cortar qualquer coisa, entre em contato e pergunte se pode
+- Uso e economia de recursos (por exemplo água)
+- Não tomar decisões importantes sem consultar os/as responsáveis pela casa
+
+Como forrar a área de trabalho
+------------------------------
+
+- Lonas presas com fita adesiva no chão
+- Fazer um "tapete" contínuo com um rolo de saco de livo grande
+- Usar uma bandeja para fazer cimento
+
+Recomendações para jardins
+--------------------------
+
+- Não usar o rastelo para varrer piso.
+- Tirar folhas velhas?
+- Podar plantas? Quais?
+
+Recomendações sobre o uso de ferramentas
+----------------------------------------
+
+- Boa conservação.
+- Não manusear com as mãos sujas.
+- Limpar após o uso.
+- Não forçá-las.
+- Não misturar as ferramentas da casa com as de terceiros.
+
+Orçamentos
+----------
+
+- Nenhum trabalho pode começar sem a aprovação de um orçamento.
+- Orçamentos devem ter prazo.
+- Acertos podem ser feitos após o término dos serviços para compensar
+  excesso de trabalho, mas estes não podem passar muito do orçamento
+  acordado.
+
+Recomendações para louça
+------------------------
+
+- Reusar louça que está secando.
+
+Contabilidade
+-------------
+
+Pastas de gastos:
+
+- Já contabilidados.
+- Ainda não contabilizados.
+
+Almoxarifado
+------------
+
+- Empilhado.
+- Enfileirado.
+- Não esconder itens uns atrás dos outros.
+- Estoque (pode conter duplicatas) versus armário de coisas em uso.
+- Itens do mesmo tipo no mesmo lugar.
diff --git a/docs/atividades/casa/regras.md b/docs/atividades/casa/regras.md
new file mode 100644
index 0000000..8ded7ad
--- /dev/null
+++ b/docs/atividades/casa/regras.md
@@ -0,0 +1,92 @@
+# Regras Domésticas
+
+* Regras genéricas de convívio a serem combinadas caso a caso.
+* Elas podem ser orais ou escritas. Caso escritas, podem ser
+  afixadas em locais específicos da casa, como por exemplo
+  como lembretes em locais especiais (por exemplo sobre lavar
+  a louça num local próximo à pia).
+
+Básico
+------
+
+* Trabalho é dividido para não haver exploração.
+* Deixe as coisas num estado melhor do que as encontrou.
+* Se quer limpar menos, suje menos!
+
+Contabilidade
+-------------
+
+Vários são os modos de operação possíveis:
+
+### Esquema clássico
+
+Contabilidade usual, com planilha de gastos: muito útil durante o período de
+montagem do ambiente doméstico, onde tivemos vários gastos de material.
+
+### Esquema prático
+
+Esquema atual, mais prático uma vez que o ambiente doméstico já esteja montado:
+
+- Só custo fixo entrando no racha, podendo ser definido um valor médio.
+
+- Provisões e mantimentos a gente deixa rolar, cada um compra o que achar
+  necessário e come o que quiser, mas sem rachar os custos.
+
+Assim, uma das pessoas paga as contas e a(s) outr(o/as) só faria(m) um único depósito.
+E só é preciso refazer essa conta se algum dos valores mudar.
+
+Assim fica mais fácil, apesar de não ser mais exato.
+
+### Esquema colaborativo
+
+Usando uma aplicação como o [misery](https://packages.debian.org/stable/misery) ou o
+[ihatemoney](https://ihatemoney.org/) ([código](https://ihatemoney.org/)), permitindo
+que todos/as possam adicionar e editar gastos:
+
+- Gastos fixos podem ser compartilhados normalmente: a pessoa que pagou o gasto indica
+  para quem este gasto foi feito.
+
+- Por padrão, gastos que não foram acordados previamente são arcados apenas pela pessoa
+  que decidiu e gastou, porém quem quiser compartilhar/consumir o gasto pode se incluir
+  no racha.
+
+Definições
+----------
+
+* Sobre frituras.
+* Andar de sapatos dentro de casa.
+* Bagunça dentro e fora do quarto.
+* Compartilhamento de material de higiene.
+* Padrão de lavagem de panelas para aumentar suas conservação.
+* Evitar abrir produtos que já possuem outras embalagens abertas.
+* Manter ambiente limpo e organizado para evitar trabalho excessivo.
+* Locais para ativos pessoais e coletivos (geladeira, armários, despensas, etc).
+
+Limpeza
+-------
+
+Modos de limpeza:
+
+* Mutirão coletivo periódico.
+* Revezamento semanal periódico.
+* Coisas largadas por aí estão sujeitas a serem repostas no lugar!
+
+Louça:
+
+* Lave o que sujou + 1.
+* Secar bem a louça e guardá-la quando possível, evitando acúmulo.
+* Deixar esponja seca e sem sabão.
+* Deixar pia e ralo limpos para não entupir.
+
+Mantimentos
+-----------
+
+* Comprar periódicas em atacadões.
+* Compras semanais de frutas, verduras e legumes.
+
+Social
+------
+
+* Aluguel temporário.
+* Hospedagem solidária.
+* [Couchsurfing](https://www.couchsurfing.com)?
diff --git a/docs/atividades/lab.md b/docs/atividades/lab.md
new file mode 100644
index 0000000..f1886ed
--- /dev/null
+++ b/docs/atividades/lab.md
@@ -0,0 +1,68 @@
+# Laboratório de Hardware
+
+Lista de equipamentos básicos para um laboratório de hardware.
+
+* Avental.
+* Lupa com garras.
+* Caixa de ferramentas (martelo, alicate, fenda e philips).
+* Cabos JTAG.
+* Cabo USB to Serial (Raspberry Pi):
+  * [Ultimate Serial Port](http://www.mysticengineering.com/debug.buddy/pi.usage.html).
+  * [USB to TTL Serial Cable - Debug / Console Cable for Raspberry Pi ID: 954 - $9.95 : Adafruit Industries, Unique & fun DIY electronics and kits](https://www.adafruit.com/products/954).
+  * [USB MPSSE Cables](http://www.ftdichip.com/Products/Cables/RPi.htm).
+* Câmera infravermelha.
+* Leitores de Smartcard/Simcard. 
+* Leitor de RFID.
+* Leitor de senhas da BIOS dos Thinkpads.
+* [Bus Pirate - DP](http://dangerousprototypes.com/docs/Bus_Pirate).
+* [Bus pirate basic probe set ID: 238 - $7.00 : Adafruit Industries, Unique & fun DIY electronics and kits](https://www.adafruit.com/products/238).
+* [Bus Pirate - v3.6a - TOL-12942 - SparkFun Electronics](https://www.sparkfun.com/products/12942).
+* [SparkFun FTDI Basic Breakout - 3.3V - DEV-09873 - SparkFun Electronics](https://www.sparkfun.com/products/9873).
+* SDR Dongles.
+  * Baseados no rtl2832 como FunCubeDongle Pro+, que funciona em OM e OC (vai mais baixo em frequencia).
+  * Recomendo dar uma olhada no LimeSDR também.
+* Kit lockpicking.
+* Multímetro.
+* Testador de cabo ethernet.
+* Fonte de tensão regulável.
+* [OpenPCD Passive RFID Project - OpenPCD](http://www.openpcd.org/).
+* Arduíno Leonardo.
+* Shields RPI:
+  * RFID.
+  * Bluetooth 4.0.
+* Shields do Arduíno.
+* PCB? CNC João de Barro?
+* Cortadora Laser.
+* RPI 3.
+* [LinkIt ONE](https://www.seeedstudio.com/LinkIt-ONE-p-2017.html).
+* Beagle Board Green (pra usar de programador standalone pra Gnuk e afins).
+* Osciloscópio e gerador de sinais:
+  * [Comedi - Control and Measurement Interface](http://www.comedi.org).
+  * [xoscope for Linux](http://xoscope.sourceforge.net/) ([pacote](https://packages.debian.org/stable/xoscope)).
+  * [BitScope Mini Model 10 | World's Smallest Mixed Signal PC Based USB Oscilloscope!](http://bitscope.com/product/BS10/).
+  * [DIY: Turn your GNU/Linux computer into a free oscilloscope | Yann "Bug" Dubois](http://www.yann.com/en/diy-turn-your-gnulinux-computer-into-a-free-oscilloscope-29/09/2010.html).
+* Ferramentas e instrumentos para ver melhor:
+  * All-in-one:
+    * [PSLab.io](https://pslab.io/): small USB powered hardware extension for your Android phone or PC that lets you measure all kinds of things.
+    * [Espotek Labrador](https://espotek.com/labrador/) ([código](https://github.com/EspoTek/Labrado)): a USB device that transforms your PC or smartphone into a fully-featured electronics lab.
+  * Telescópio.
+  * Microscópio USB.
+  * Binóculo.
+  * Astrolábio.
+  * Teodolito.
+  * Sismógrafo.
+  * Balança.
+  * Paquímetro.
+  * Micrômetro.
+  * Réguas de cálculo.
+
+Dicas
+-----
+
+* Ao desmontar algo, colar as peças numa folha de sulfite, fazendo anotação da
+  ordem de desmontagem, posições, etc, como [nesta
+  foto](https://geoff.greer.fm/photos/x62/IMG_1158.jpg), usando fita dupla face
+  ou uma fita enrolada para colar as coisas; eventualmente tirar fotos durante
+  o processo para que a desmontagem e a remontagem sejam mais determinísticas;
+  uma dica do tipo se encontra em algum lugar do livro Zen e a Arte de
+  Manutenção de Motocicletas.
diff --git a/docs/atividades/orfanato.md b/docs/atividades/orfanato.md
new file mode 100644
index 0000000..8b93602
--- /dev/null
+++ b/docs/atividades/orfanato.md
@@ -0,0 +1,27 @@
+# Orfanato de Projetos
+
+* Trata-se de um esquema em que alguém possui um portfolio de projetos e
+  procura pessoas e times que queiram adotá-los.
+
+* Uma rotina periódica faz com que o orfanato entre em contato com as pessoas
+  para checar se os projetos que elas adotaram não foram abandonados.
+
+## Requisitos
+
+Para um projeto possa ser adotado, a pessoa ou grupo responsável terá de estar
+de acordo com algumas coisas:
+
+* O desenvolvimento precisa ser em software livre.
+* O software precisa ser instanciável, ou seja, grupos e pessoas podem criar
+  instalações deles onde quiserem.
+* Gestão da instância principal coletiva e com abertura.
+* Respeito à privacidade, preocupação com segurança e que estejam na linha dos
+  [Princípios Éticos](https://templates.fluxo.info/etica/coletiva/).
+* [Responsabilização](/coletivo/responsabilizacao/).
+
+Além disso, o orfanato tenta, na medida do possível:
+
+* Prestar consultoria sobre os projetos.
+* Realizar checagens periódicas (pings semestrais, por exemplos) para saber se
+  as pessoas ainda estão mantendo os projetos ou se é necessário procurar
+  outras pessoas para adotá-los.
diff --git a/docs/atividades/project.md b/docs/atividades/project.md
new file mode 100644
index 0000000..04b5930
--- /dev/null
+++ b/docs/atividades/project.md
@@ -0,0 +1,25 @@
+# Projetos
+
+## Sistemas de tarefas simples
+
+Sistema de tickets, como por exemplo:
+
+* No README.
+* Arquivo TODO em formatos plaintext, Markdown, YAML ou híbridos.
+* Um arquivo por tarefa em pastas `open` e `closed`.
+* Ditz, bugs-everywhere, taskwarrior ou similar.
+* Aplicação própria (Trac, etc)
+* TODOs and FIXMEs ao longo do código em última instância.
+
+## Projetos de Software
+
+* Vagrantfile e manifests do puppet.
+* Git ou VCS usado upstream.
+* Branches de desenvolvimento e upstream.
+* Workflow padrão (git-flow, git-hooks, etc).
+* Suíte de testes.
+* Adotar [Semantic Versioning](http://semver.org).
+
+## Ferramentas
+
+* [Planilha de Projeto](project.ods).
diff --git a/docs/atividades/project.ods b/docs/atividades/project.ods
new file mode 100644
index 0000000..4dd44f2
--- /dev/null
+++ b/docs/atividades/project.ods
diff --git a/docs/atividades/provedor/README.md b/docs/atividades/provedor/README.md
new file mode 100644
index 0000000..2165619
--- /dev/null
+++ b/docs/atividades/provedor/README.md
@@ -0,0 +1 @@
+# Provedor de Serviços de Internet - ISP
diff --git a/docs/atividades/provedor/backups.md b/docs/atividades/provedor/backups.md
new file mode 100644
index 0000000..5e10a77
--- /dev/null
+++ b/docs/atividades/provedor/backups.md
@@ -0,0 +1,46 @@
+# Grupo de Trabalho de Backups
+
+O presente processo estabelece as linhas gerais de funcionamento de um grupo de
+trabalho responsável pela realização de backups para o Coletivo, cujos
+objetivos são delineados nos critérios que a seguir.
+
+## Preservação
+
+O grupo de trabalho deve manter backups do máximo número possível de
+camadas/instâncias do Coletivo, preservando os critérios de segurança e
+privacidade assim como a Política de Segurança da Informação do Coletivo e
+especialmente o seguinte critério de persistência da informação:
+
+`
+Informações armazenados num determinado nível de acesso ou segurança (exemplo,
+disco criptografado) devem, por padrão, permanecer nesse mesmo nível ou serem
+transferidas para um nível mais seguro, exceto quando constitui informação
+desclassificada e permitida para descer de nível.
+`
+
+Do ponto de vista do [RSP](http://rsp.fluxo.info), o GT de Backups deve
+proporcionar replicação de camadas que preservem (ou que aumentem o nível, se
+possível) suas propriedades de segurança e privacidade no acesso à informação.
+
+## Otimização de parâmetros
+
+O grupo de trabalho deve ainda otimizar os seguintes parâmetros ao propiciar a
+realização de backups:
+
+1. Periodicidade.
+2. Incrementos.
+3. Largura de banda.
+4. Segurança e integridade.
+5. Espaço em disco.
+
+## Auditagem
+
+O grupo de trabalho deve também realizar auditagens periódicas nos backups para
+se certificar de sua realização e, se possível, possuir um sistema automático
+de relatórios de backups.
+
+## Dependências
+
+A realização deste processo depende da realização dos seguintes processos:
+
+* [Política de segurança da informação](/coletivo/comunicacao/acl).
diff --git a/docs/atividades/provedor/backups/entrega.md b/docs/atividades/provedor/backups/entrega.md
new file mode 100644
index 0000000..c2cfb75
--- /dev/null
+++ b/docs/atividades/provedor/backups/entrega.md
@@ -0,0 +1,93 @@
+# Entrega de backups solicitados
+
+Processo que consiste na entrega de backups solicitados por grupos e pessoas
+hospedadas na infra-estrutura do Coletivo. As tarefas envolvidas consistem em:
+
+1. Obter as solicitações a backups e organizá-las numa tabela, mantendo assim o
+   Coletivo informado sobre o andamento deste processo. Por possivelmente
+   existirem backups de qualidades distintas, é preciso perguntar à parte
+   solicitante, caso necessário, de qual backup os dados precisam ser entegues.
+2. Obter, caso existente, o backup solicitado, realizando uma auditoria caso
+   necessário.
+3. Disponibilizar os backups apenas às pessoas responsáveis pelos ou donas dos
+   dados ou informá-las caso o backup não exista. Informá-las também se o eventual
+   backup foi ou não auditado e:
+  a. Caso tenha sido auditado, disponibilizar, em linhas gerais, o procedimento utilizado.
+  b. Caso não tenha sido auditado, informal qual risco isso representa.
+
+Auditoria do backup
+-------------------
+
+Quando necessária, a auditoria básica consiste em:
+
+1. Retirar qualquer código executável que possa ser substituído.
+2. Marcar todo o código executável insubstituível como vulnerável, cuja
+   auditoria é deve ser repassada para o grupo dono do código.
+3. Destruição ou modificação de qualquer senha encontrada, mesmo que a mesma se
+   encontre armazenada de modo cifrado.
+4. Auditagem básica de conteúdo: verificação de datas de acesso e escrita a
+   arquivos, passar anti-virus, etc.
+5. Auditagem avançada de conteúdo, se possível.
+
+Procedimentos mais refinados ficam à cargo da situação e do grupo de trabalho
+de entrega de backups solicitados (composto pelas pessoas responsabilizadas
+pelas tarefas acima mencionadas).
+
+Prazos
+------
+
+O prazo de entrega de backups é proporcional ao tamanho do mesmo e à
+necessidade de auditoria:
+
+* Backups de até 100MB: entrega em até 30 dias.
+* Backups de até 1GB: entrega em até 60 dias.
+* Backups maiores que 1GB: entrega em até 90 dias.
+
+No caso de necessidade de auditoria, o prazo de entrega é duplicado.
+
+Template
+--------
+
+    Conforme solicitado, o último backup disponível de $descricao, datado de $data
+    e obtido $origem, já está disponível.
+    
+    Seguem os dados:
+    
+      - URL: https://backups.$dominio/$sitio
+      - Conta: $sitio
+      - Senha: $senha
+    
+    O https://backups.$dominio atualmente usa um certificado SSL
+    auto-assinado, cuja impressão digital é
+    
+      $fingerprint
+    
+    Hashes dos arquivos disponibilizados:
+    
+      md5sum:  $hashes
+      sha1sum: $hashes
+    
+    Auditoria realizada:
+    
+      - Busca e eventual remoção de código executável.
+      - Mudança de senhas em banco de dados (senhas truncadas).
+      - Busca por vírus.
+    
+    Tarefas não-realizadas porém recomendadas:
+    
+      - Checagem do conteúdo do banco de dados (para evitar calúnia ou
+        desinformação)
+      - Checagem do conteúdo dos arquivos.
+      - IMPORTANTE: checagem de usuários para evitar inscrições de
+        elementos estranhos.
+      - Checagem da configurações da instância, caso ela seja reinstalada
+        noutro local.
+      - Limpeza do spam e desativação de todas as contas desconhecidas
+        (principalmente relacionadas a spam).
+    
+    Observações:
+    
+      - Em princípio, não há prazo para a permanência de tal backup
+        no local disponibilizado. No entanto, pode ser que ele precise
+        ser apagado para liberar espaço ou nalgum procedimento de
+        limpeza. Por isso, recomenda-se que sejam baixados o quanto antes.
diff --git a/docs/atividades/provedor/cert.md b/docs/atividades/provedor/cert.md
new file mode 100644
index 0000000..dcf62a8
--- /dev/null
+++ b/docs/atividades/provedor/cert.md
@@ -0,0 +1,176 @@
+# Gestão de chave e certificado SSL
+
+O presente processo trata da gestão de chave e certificado SSL para conexões
+ditas seguras entre servidores do Coletivo.
+
+Considerações
+-------------
+
+O Coletivo reconhece que
+
+1. O protocolo HTTPS possui sérios problemas de design, impedindo por exemplo
+   que diferentes certificados possam ser utilizados num mesmo IP.
+
+2. A indústria da certificação digital representa um sério risco de segurança e
+   uma [imposição tecnocrata](http://lair.fifthhorseman.net/~dkg/tls-centralization/) à
+   utilização prática do HTTPS. Ela recria um domínio cartorial no cyberespaço e
+   pode a qualquer momento [ser utilizada por governos ou corporações para forjar
+   certificados autenticados](http://web.monkeysphere.info/news/internet_secret_backdoor/) e
+   com isso [grampear](https://secure.wikimedia.org/wikipedia/en/wiki/Man-in-the-middle_attack)
+   a conexão entre usuários/as e computadores.
+
+3. Idealmente, a atitude a ser tomada por um coletivo técnico radical deveria
+de não utilizar a indústria da certificação como meio de assegurar a
+identificação de seus serviços e máquinas. Deveria, ao invés disso, utilizar
+apenas esquemas abertos como
+    a. Certificadores Comunitários como o [CACert](http://cacert.org).
+    b. [Monkeysphere](http://web.monkeysphere.info).
+    c. A simples verificação da impressão digital dos certificados mediante
+       algum vínculo direto (por exemplo, troca de fingerprints ou validação via
+       OpenPGP) com os/as administradores das máquinas.
+
+4. No entanto
+    a. Nem todos os navegadores acompanham, por padrão, certificados de
+       entidades comunitárias. É o
+       [caso do CACert](https://secure.wikimedia.org/wikipedia/en/wiki/Cacert#Inclusion_status).
+    b. A adoção de ferramentas livres para HTTPS ainda está muito longe de se
+       tornar comum. No presente, haveria pouca possibilidade de que uma metodologia
+       livre seja eficiente. Ao invés disso, haveria um involuntário incentivo aos/às
+       usuários para que aceitem certificados considerados como inválidos pelos
+       navegadores, o que pode facilitar ainda mais o grampo: se os usuário aceitam
+       qualquer certificado, então não haveria diferença entre eles aceitarem o
+       certificado verdadeiro do falso.
+
+Conclusões
+----------
+
+Portanto, o Coletivo conclui que
+
+1. No momento, ainda importante ter um certificado assinado pela indústria da
+   certificação, isto é, por uma entidade autorizada pelo cartel do SSL.
+3. A autoridade certificadora a ser utilizada deve obedecer alguns critérios básicos:
+  a. Não é diretamente conectada a uma agência governamental.
+  b. Não possui problemas políticos óbvios.
+  c. Cujo certificado raíz não está encadeado com certificados que não satisfazem os critérios acima.
+2. Dada a sua insuficiência, tal certificação corporativa não deve ser o único
+   meio para a validação dos certificados SSL e assim esquemas alternativos como o
+   [Monkeysphere](http://web.monkeysphere.info) devem ser utilizados e
+   encorajados, de modo que haja um aumento da massa crítica necessária para
+   tornar tais métodos mais populares. O mesmo se aplica para a verificação da
+   impressão digital dos certificados.
+
+Utilização de HTTPS
+-------------------
+
+Conforme o documento [Best Practices for Online Service
+Providers](https://www.eff.org/wp/osp), o Coletivo concorda que conexões HTTPS
+devem ser utilizadas o máximo possível.
+
+1. O Coletivo utilizará HTTPS apenas em servidores confiáveis que onde seja
+   possível armazenar as chaves SSL de forma criptografada.
+2. Utilizar, quando possível, cabeçalhos
+   [HSTS](http://www.debian-administration.org/article/Enabling_HTTP_Strict_Transport_Security_on_debian_servers).
+2. Considerando que o certificado vale apenas para um único domínio e seus
+   subdomínios (isto é, o domínio principal do Coletivo), o Coletivo utilizará
+   HTTPS por padrão apenas:
+     a. Para serviços, sistemas e sítios que utilizem o domínio principal do
+        Coletivo, quando não houver impedimento técnico para tal.
+     b. Para outros domínios desde que solicitado pela parte hospedada.
+3. Considerar a utilização de [entradas CAA no DNS](https://links.fluxo.info/tags/caa).
+
+Implementação
+-------------
+
+A implementação de HTTPS também deve obedecer a uma suite bem estabelecida.
+
+Tal escolha deve desabilitar uma série de cifras ruins e habilitar aquelas que
+provém [Perfect Forward Secrecy
+(PFS)](https://secure.wikimedia.org/wikipedia/en/wiki/Perfect_forward_secrecy).
+
+Outros protocolos
+-----------------
+
+A utilização do SSL também deve se estender a outras plataformas, como por
+exemplo email (via TLS) desde que possível e que atenda critérios análogos aos
+anteriores.
+
+Escolha de autoridade certificadora
+-----------------------------------
+
+Dentre as autoridades certificadoras, o Coletivo escolhe a [Gandi](https://gandi.net) por:
+
+1. Atender os critérios acima estabelecidos.
+2. Diferentemente de outras empresas, possui uma preocupação com privacidade e
+   comprometimento com serviços de internet alternativos e independentes.
+2. [Contribuir com projetos de código aberto](https://secure.wikimedia.org/wikipedia/en/wiki/Gandi#Gandi_supports ),
+   vide [lista](http://en.gandi.net/supports/).
+
+No entanto, é importante notar as limitações envolvidas na escolha do Gandi:
+
+    Q: Por que muitos grupos usam GANDI como registrar?
+    R: Porque naqueles tempos (2000), ter seu próprio domínio era tranquilamente
+       de 5 a 10 vezes mais caro do que hoje. GANDI acabou com esses preços
+       introduzindo ofertas muito baratas no mercado. E como em geral temos
+       pouco ou nenhum dinheiro para colocar em projetos, simplemente compramos
+       nossos domínios lá.
+    
+    Q: O que GANDI significa?
+    R: Isso é uma curiosidade, mas GANDI significa "Gestion et Attribution
+       des Noms de Domaines Internet", "Atribuição e gestão de nomes de
+       domínio de Internet". Como empresa, o modelo de negócios era simples:
+       praticamente tudo automatizado, praticamente sem suporte e preços
+       baixos.
+    
+    Q: Por que GANDI é vista como uma organização política?
+    R: Os fundadores originais do GANDI tinham idéias políticas sobre bens
+       comuns e como todo o negócio de nomes de domínio da Internet era
+       baseado em escassez virtual. Um deles até escreveu um livro,
+       "Confessions d'un voleur" ("Confissões de um ladrão") no qual ele
+       descreve extensamente sobre como fez um monte de dinheiro exatamente
+       vendendo algo que não existia e que não havia sentido em vender.
+    
+    Q: Por que GANDI é visto como "descolado"?
+    R: Alguns dos fundadores originais também eram envolvidos na cena
+       alternativa da Internet na França. Parte do dinheiro obtida pelo
+       GANDI ajudou outros projetos, um dos quais o operador sem fins
+       lucrativos Gitoyen.
+    
+    Q: Onde estão esses fundadores agora?
+    R: Em algum outro lugar! Como não foram capazes de concordar em onde
+       o dinheiro deveria ir, os quatro fundadores resolveram vender o
+       GANDI. Eles fizeram isso até por um preço justo. Tentaram vender
+       para pessoas que respeitariam o espírito original, e em certo
+       sentido o fizeram. Parece que o GANDI ainda contribui para
+       projetos de software livre e relacionados, tanto em tempo de
+       trabalho quanto em dinheiro.
+    
+    Q: Devo confiar no GANDI?
+    R: Da mesma forma que você confia em qualquer companhia capitalista.
+       Eles preferirão preservar seu negócio ao invés de ajudar você.
+
+Responsabilização
+-----------------
+
+O Grupo de Trabalho formado pelas pessoas responsáveis pelo presente processo deve:
+
+1. Caso o Coletivo disponha de recursos financeiros, manter certificado SSL
+   assinado para `*.dominio` via [Gandi](https://gandi.net). O Coletivo arcará com
+   os custos. Caso contrário, adotar a certificação
+   [CACert](http://www.cacert.org/) como padrão.
+2. Manter formas alternativas de certificação via:
+     a. [Monkeysphere](http://web.monkeysphere.info).
+     b. A simples verificação da impressão digital dos certificados mediante
+        algum vínculo direto (por exemplo, troca de fingerprints ou validação via
+        OpenPGP) com os/as administradores das máquinas.
+     c. Manter, na medida do possível, o público informado das mundanças nas
+        haves de acesso, utilizando para isso OpenPGP. Como exemplo, manter uma página
+        ública e atualizada sobre os atuais certificados utilizados e também informar
+        rupos e pessoas próximas sobre mudanças em certificados.
+3. Opcionalmente, manter também a assinatura via [http://www.cacert.org/ CaCert].
+4. Evitar o vencimento da validade dos certificados, utilizando para isso
+   métodos como o [http://prefetch.net/articles/checkcertificate.html
+   ssl-cert-check], implementado por exemplo no
+   [http://git.fluxo.info/puppet-ssl puppet-ssl].
+5. Observar a aplicação dos critérios e determinações do presente processo,
+   operando conjuntamente com o GT de [wiki:Camadas Configuração de sistemas
+   padronizada e centralizada].
diff --git a/docs/atividades/provedor/hospedagem.md b/docs/atividades/provedor/hospedagem.md
new file mode 100644
index 0000000..6c40cd2
--- /dev/null
+++ b/docs/atividades/provedor/hospedagem.md
@@ -0,0 +1,64 @@
+# Hospedagem
+
+Este processo define os procedimentos de hospedagem do Coletivo. A hospedagem
+de conteúdo e/ou serviços constitui processo formal e é dividida em dois
+níveis:
+
+1. Grupo de trabalho de uma dada plataforma.
+2. Grupo responsável por uma dada hospedagem.
+
+## Necessidade de formalização
+
+Como a hospedagem consiste numa atividade sensível, onde é importante dar
+alguma garantia a quem se hospeda e da mesma maneira ter garantias contra
+possíveis problemas que cada hospedagem pode causar, ambos os níveis devem ser
+estabelecidos como processos formais. Além disso, como parte da implementação
+deste processo, inclusive sítios já hospedados e plataformas existentes deverão
+passar pela formalização.
+
+A hospedagem está sujeita a comprometimentos (do Coletivo e da parte hospedada)
+que satisfaçam a uma Política de Hospedagem do Coletivo.
+
+## Grupo de uma plataforma
+
+Ao grupo de trabalho de uma dada plataforma cabe cuidar do funcionamento,
+manutenção e segurança de uma dada plataforma de hospedagem. Para cada
+plataforma a ser oferecida hospedagem é preciso um grupo de trabalho
+responsável.
+
+A não existência de um grupo de trabalho de uma plataforma não proíbe a
+existência de instalações da plataforma para uso interno do Coletivo, mas
+impede que a hospedagem de terceiros (isto é, de grupos e indivíduos de fora do
+Coletivo) seja realizada.
+
+## Grupo de uma hospedagem
+
+Ao grupo de trabalho responsável por uma dada hospedagem cabe cuidar da
+hospedagem de um dado grupo/indivíduo. Para que seja possível hospedar um grupo
+ou indivíduo numa dada plataforma, é necessário que haja um grupo de trabalho
+em funcionamento para essa plataforma.
+
+O processo formal para cada hospedagem deve conter as seguintes ações:
+
+1. Apresentação do Coletivo (realizada durante a etapa "discussão" do processo)
+   através do envio de sua Carta de Hospedagem.
+2. Apresentação do grupo ou indivíduo a ser hospedado realizada durante a etapa
+   "discussão" do processo).
+3. Decisão:
+   * No caso de aprovação da hospedagem pelo Coletivo e após o processo sido
+     responsabilizado:
+       1. A(s) pessoas(s) responsável(is) pela hospedagem deve(m) enviar o
+          Termo de Comprometimento de Hospedagem e a Política de Hospedagem do Coletivo.
+       2. O coletivo ou indivíduo a ser hospedado deve concordar com o Termo de
+          Comprometimento de Hospedagem, caso contrário a hospedagem não pode ser
+          realizada.
+   * No caso de não-aprovação pelo Coletivo ou falta de responsabilização, o
+     grupo ou indivíduo que seria hospedado deve ser informado da decisão
+     juntamente com o motivo, se possível.
+
+## Responsabilização
+
+Cabe ao grupo de trabalho de uma hospedagem:
+
+1. Aplicar a Política de Hospedagem do Coletivo junto à parte hospedada.
+2. Manter a comunicação entre o Coletivo e a parte hospedada.
diff --git a/docs/atividades/provedor/hospedagem/carta.md b/docs/atividades/provedor/hospedagem/carta.md
new file mode 100644
index 0000000..10d7f75
--- /dev/null
+++ b/docs/atividades/provedor/hospedagem/carta.md
@@ -0,0 +1,73 @@
+# Carta de Hospedagem
+
+A Carta de Hospedagem não apenas estabelece as intenções e princípios que o
+Coletivo adota para a hospedagem quanto pode ser utilizada como apresentação
+aos grupos e indivíduos canditatos a hospedagem.
+
+    Carta de Hospedagem do $coletivo
+    --------------------------------
+    
+    O $coletivo é parte de uma intersecção de vários grupos que discutem política e
+    tecnologia de diferentes formas. Partindo disso, trabalhamos com servidores de
+    internet, voltados para distintas finalidades de cooperação. Sendo assim, nossa
+    idéia é colaborar com grupos/projetos que participem de experiências de apoio
+    mútuo e múltiplo.
+    
+    O $coletivo é um projeto autônomo, mantido por um coletivo de voluntários e
+    voluntárias. Um dos nossos principais objetivos é a construção coletiva de
+    espaços públicos, comuns entre diversos projetos e grupos que tenham a intenção
+    de fortalecer e estreitar sua convivência.
+    
+    Nossa intenção não é oferecer um "serviço de hospedagem", por isso não estamos
+    dispostos/as a nos aproximar de grupos que busquem este tipo de serviço.
+    Queremos que os grupos  por nós hospedados colaborem com a construção de uma
+    vizinhança, um rizoma. De tal maneira que a técnica e a tecnologia não sejam
+    impedimento para isso, muito pelo contrário.  Sendo a tecnologia também uma
+    construção social, seus propósitos, sua configuração e os processos nos quais
+    ela interfere não podem prescindir dos desígnios dos grupos sociais onde ela é
+    manipulada.
+    
+    A internet é um ambiente de cooperação, mas também de apropriação e exploração
+    de bens públicos.  Nós entendemos que ela só se torna essencialmente um espaço
+    público na medida em que as pessoas possam controlar seus meios de produção e
+    de acesso, o que não ocorre em espaços corporativos ou governamentais. Por isso
+    buscamos a criação de espaços públicos, não corporativos e não estatais, e
+    esperamos que os grupos por nós hospedados colaborem com a construção desses
+    espaços.
+    
+    Durante a construção de tais espaços, realizamos discussões nas quais tentamos
+    desvendar temas como cultura, sociedade, tecnologia, ativismo, mudanças sociais
+    entre outros. Tais estudos, quando possível, são disponibilizados publicamente.
+    
+    Estudamos as implicações políticas da técnica, desenvolvemos sistemas e
+    instrumentos a partir de outros valores políticos, além de dialogarmos
+    politicamente dentro da lógica cíclica da teoria/prática.
+    
+    Por isso, uma de nossas propostas é o estabelecimento coletivo de uma rede de
+    apoio mútuo entre os grupos e indivíduos interessados em partilhar de uma mesma
+    estrutura para compartilhar seus conhecimentos, atividades desenvolvidas e
+    estudos realizados, de forma a integrar ativamente esta rede.
+    
+    Buscamos, portanto, quebrar com a relação prestador de serviço/cliente, pois
+    não somos prestadores/as de serviço e nem os grupos/indivíduos por nós
+    hospedados são nossos clientes, ambos fazemos parte de uma mesma rede de
+    colaboração onde interesses diversos convergem para o fortalecimento dessa
+    rede, e quem sabe para que esta forma de organização extrapole a própria rede e
+    contamine assim as demais esferas que compõe a sociedade.
+    
+    Pensando na distribuição do conhecimento, e como incentivo a novos grupos
+    interessados em manter sua própria plataforma de servidores, buscamos divulgar
+    o máximo da sistematização de organização.
+    
+    E lembre-se: para nós, @ $coletivo não é apenas um sistema de hospedagem ou um
+    mero provedor de serviços.
+    
+    Links de interesse:
+    
+     - Estudos disponibilizados: http://wiki.$dominio
+     - Configurações e procedimentos operacionais: http://padrao.$dominio
+    
+    Atenciosamente,
+    Coletivo $coletivo
+
+[Versão inglesa](/english/hosting/letter).
diff --git a/docs/atividades/provedor/hospedagem/database.md b/docs/atividades/provedor/hospedagem/database.md
new file mode 100644
index 0000000..c869bb3
--- /dev/null
+++ b/docs/atividades/provedor/hospedagem/database.md
@@ -0,0 +1,16 @@
+# Checklist para Bases de Dados
+
+* Fundamental:
+  * Backups remotos automatizados.
+  * Acesso web à plataforma apenas via conexão mais segura (https).
+  * Adequação à legislação (LGPD, Marco Civil etc).
+  * Minimizar quantidade de dados pessoais coletados e exibidos ao estritamente necessário.
+  * Acesso restrito para informações pessoais.
+* Recomendado:
+  * Não utilizar "nuvem" corporativa: usar servidor próprio, pois evita o acesso por terceirizados.
+  * Protocolo (acordo comum) sobre o uso da plataforma pelos pesquisadores(as), incluindo aspectos sobre privacidade.
+  * Treinamento básico de segurança e privacidade para administradores(as) e alimentadores(as) do sistema.
+  * Definição sobre licenciamento de dados (direitos autorais) e política de dados abertos.
+* Opcional:
+  * Armazenamento criptografado.
+  * Backups offline.
diff --git a/docs/atividades/provedor/hospedagem/plataforma.md b/docs/atividades/provedor/hospedagem/plataforma.md
new file mode 100644
index 0000000..322296e
--- /dev/null
+++ b/docs/atividades/provedor/hospedagem/plataforma.md
@@ -0,0 +1,45 @@
+# Grupo de Trabalho de Hospedagem em $plataforma

+

+O presente processo estabelece o funcionamento do Grupo de Trabalho de

+Hospedagem em `$plataforma` (doravante mencionado apenas como

+'''plataforma'''), consistindo em:

+

+1. Manter instalações atualizadas e em funcionamento da plataforma.

+2. Acompanhar avisos de segurança e atualizações dos aplicativos necessários

+   para o funcionamento da plataforma.

+3. Caso não seja realizado automaticamente, efetuar atualizações de segurança

+   em no máximo '''uma semana''' (incluindo finais de semana e feriados) após as

+   mesmas serem disponibilizadas.

+4. Observar e aplicar os critérios de segurança e privacidade existentes para

+   os/as usuários da plataforma.

+5. Caso possível, atender a pedidos do Coletivo pela instalação adicional da

+   plataforma em locais distintos em virtude de aspectos legais e políticos.

+6. Disponibilizar ao Coletivo informações relacionadas aos procedimentos

+   utilizados pelo grupo de trabalho, manutenções e atualizações que foram ou

+   serão efetuadas.

+

+# Responsabilização

+

+É de responsabilização do grupo de trabalho a realização das tarefas

+anteriormente mencionadas. Não é de responsabilidade do presente grupo de

+trabalho:

+

+1. Manter ou entrar em contato com grupos hospedados.

+2. Prestar suporte aos grupos hospedados. 

+

+Não é de responsabilidade do presente grupo de trabalho:

+

+1. Pelo funcionamento de cada instância da plataforma.

+

+Em outras palavras, o presente grupo de trabalho não se responsabiliza pelo uso

+de cada instância da plataforma, mas sim pelo funcionamento, atualização e

+auditoria das instalações globais da plataforma, isto é, o grupo de trabalho

+não lida com instâncias específicas da plataforma mas sim com a infra-estrutura

+da mesma.

+

+# Sobre este texto

+

+O texto deste processo foi redigido utilizando o [Template para Grupo de

+Trabalho de Hospedagem](/organizacao/misc/plataforma). No caso de alterações

+que não dizem respeito apenas ao Grupo e que possam enriquecer tal template,

+favor submetê-las também upstream, isto é, ao texto do template. 

diff --git a/docs/atividades/provedor/hospedagem/politica.md b/docs/atividades/provedor/hospedagem/politica.md
new file mode 100644
index 0000000..b6cdd8d
--- /dev/null
+++ b/docs/atividades/provedor/hospedagem/politica.md
@@ -0,0 +1,47 @@
+# Política de Hospedagem do Coletivo
+
+    Política de Hospedagem do Grupo
+    -------------------------------
+    
+    1. O Coletivo reserva para si o poder de hospedar ou deixar de hospedar
+       qualquer grupo ou indivíduo a partir dos principios e critérios éticos,
+       politicos e práticos do Coletivo.
+    
+    2. No caso de deixar de hospedar um grupo ou indivíduo, o Coletivo se
+       compromete a avisar a parte hospedada com antecedência e disponibilizar os
+       arquivos envolvidos na hospedagem.
+    
+    3. Grupos e indivíduos só são hospedados pelo Coletivo se mostrarem-se
+       dispostos a uma relação recíproca de troca de conhecimento e atividades.
+    
+    4. Criada a parceria o Coletivo deve ser informado das ações e rumos que cada
+       projeto toma caso afetem o Coletivo, assim como o Coletivo se compromete a
+       informar a parte hospedada de qualquer venha a atingi-la.
+    
+    5. Os termos da parceria devem estar claros no sentido de um comprometimento de
+       ambos os grupos no suporte, manutenção, e desenvolvimento dos sitios e afins
+       que venham a ser criados por conta da hospedagem.
+    
+    6. A parte hospedada se responsabiliza pelo conteúdo do sitio, não cabendo ao
+       Coletivo sofrer as consequências jurídicas de conteúdo impróprio ou ilegal. No
+       entanto, o Coletivo fará o máximo possível para proteger a identidade e a
+       privacidade da parte hospedada.
+    
+    7. As relações devem se dar de maneira mais transparente possível, não
+       existindo informação encoberta ou deturpada por ambas as partes.
+    
+    8. As relações tem como finalidade a solidariedade no conhecimento, a
+       complementariedade nas ações e nas trocas entre os grupos, devendo ser
+       imprescíndivel maneiras de ensino-aprendizagem mútuos e de políticas que unam
+       os grupos em prol de uma mudança sócio-política.
+    
+    9. Coletivo se compromete a informar a parte hospedada ao menos em linhas
+       gerais sobre os critérios e políticas de privacidade e segurança das
+       plataformas de hospedagem utilizadas pela parte hospedada.
+    
+    10. Hospedagens de movimentos sociais com atividades sensíveis no país são
+       encaminhadas, quando possível, a plataformas hospedadas no estrangeiro. 
+    
+    11. A hospedagem consiste em cooperação e não prestação de serviços.
+
+[Versão inglesa](/english/hosting/policy).
diff --git a/docs/atividades/provedor/hospedagem/recusa.md b/docs/atividades/provedor/hospedagem/recusa.md
new file mode 100644
index 0000000..6dfa6e3
--- /dev/null
+++ b/docs/atividades/provedor/hospedagem/recusa.md
@@ -0,0 +1,28 @@
+# Modelo de carta de recusa de hospedagem
+
+Este é um modelo de carta para recusa de hospedagem, no caso de projetos que
+não concordamos. Para evitar mal entendidos, é importante termos um carta
+ponderada e bem esclarecedora.
+
+    Olá $requisitante,
+    
+    Infelizmente não poderemos hospedar o projeto que você requisitou porque:
+    
+      - Consideramos que ele não se enquadra nos princípios éticos que adotamos[1].
+    
+      - E/ou então consideramos que ele se enquadra nos tipos de projetos com os
+        quais mantemos uma postura crítica[2].
+    
+    Acreditamos que não exista uma única forma de luta e muito menos que a nossos
+    princípios éticos e as nossas críticas representem o ponto de vista "correto".
+    Nosso ponto de vista apenas representa as conclusões que chegamos após muita
+    discussão. Tentamos apenas nos manter coerentes com o que acreditamos e é por
+    isso que não podemos efetuar a sua requisição.
+    
+    Não queremos de modo algum que isso signifique que estamos desmerecendo a
+    atuação do seu projeto ou as coisas que você acredita.
+    
+    [1] Vide http://encontro.sarava.org/Principal/ConjuntoDePrincipiosEticos
+    [2] Vide http://wiki.$dominio
+
+[Versão inglesa](/english/hosting/refusal).
diff --git a/docs/atividades/provedor/hospedagem/termo.md b/docs/atividades/provedor/hospedagem/termo.md
new file mode 100644
index 0000000..6826af3
--- /dev/null
+++ b/docs/atividades/provedor/hospedagem/termo.md
@@ -0,0 +1,105 @@
+# Termo de Comprometimento de Hospedagem
+
+    Olá :)
+    
+    Termo de Comprometimento de Hospedagem
+    --------------------------------------
+    
+    Discutimos e estamos de acordo em oferecer hospedagem conforme sua requisição.
+    Agora, para que possamos efetivamente manter a hospedagem, é preciso:
+    
+      1. Apresentarmos qual é o nosso comprometimento com relação a essa hospedagem.
+      2. Que você e/ou seu grupo concordem com o presente termo de compromisso e com
+         a nossa Política de Hospedagem.
+    
+    Estes são os termos de compromisso mútuo, onde explicitamos qual será nosso
+    comprometimento com a hospedagem em questão pelo qual a parte hospedada precisa
+    concordar para que seja possível manter tal relação.
+    
+    Caso você concorde com os termos desta carta e aceite nossa Política de
+    Hospedagem, basta responder afirmativamente que sua hospedagem será iniciada
+    logo que possível. :)
+    
+    Nosso comprometimento
+    ---------------------
+    
+    Por essa hospedagem, nos comprometemos a manter a hospedagem em funcionamento.
+    A manutenção da hospedagem ocorre através de trabalho voluntário e responsável.
+    
+    A infra-estrutura utilizada para hospedagem é estável, porém sujeita
+    a eventuais intempéries da rede ou mesmo a problemas mais graves.
+    
+    Por isso, a hospedagem pode ficar fora do ar de vez em quando. Estamos sempre
+    atentos e prezamos pela segurança e integridade dos dados hospedados. Porém,
+    por diversos motivos, não podemos garantir a total disponibilidade ou mesmo a
+    eternidade destes dados.
+    
+    Nos comprometemos, na medida do possível, a manter cópias de segurança dos
+    dados contidos em nossa infra-estrutura. No entanto, pedimos a você que
+    mantenha, também na medida do possível, cópias de seus arquivos.
+    
+    Nosso grupo é formado por pessoas que desempenham uma série de tarefas.  As
+    atividades mais importantes e cruciais, como a hospedagem, dependem de várias
+    tarefas e cada uma delas está associada a um grupo de trabalho de pessoas
+    responsáveis pela sua realização.
+    
+    Mesmo assim, pessoas podem deixar de trabalhar num dado grupo de trabalho e
+    eventualmente alguma tarefa não possa mais ser realizada por falta de um mínimo
+    de pessoas responsáveis por ela.
+    
+    É nesse sentido que garantimos o funcionamento e a realização da hospedagem: de
+    acordo com a força de trabalho disponível no nosso grupo. Por isso, é possível
+    que, no futuro, aconteça de termos que encerrar a hospedagem numa dada
+    plataforma.  Mas, se o fizermos, garantimos que não será da noite para o dia e
+    daremos tempo suficiente para que você e seu projeto possam migrar seus dados
+    para outro local.
+    
+    Nos comprometemos também a informar, mediante solicitação, nossos procedimentos
+    de acordo com nossa política de transparência. Tais procedimentos variam desde
+    características de privacidade e segurança das plataformas utilizadas como
+    também da situação do nosso coletivo.
+    
+    Como nossos procedimentos podem variar ao longo do tempo, convém a você nos
+    solicitar as descrições de procedimentos conforme julgar necessário.
+    
+    Temos nossas limitações mas na medida do possível manteremos as coisas
+    funcionando. :)
+    
+    Seu comprometimento
+    -------------------
+    
+    Esperamos de você e do seu projeto que use o recurso oferecido com sabedoria.
+    Não peça sítios e ferramentas que você deixará abandonadas e, caso você instale
+    seu próprio programa, tenha a responsabilidade de deixá-lo atualizado, uma vez
+    que brechas de segurança no seu espaço podem comprometer outros projetos
+    hospedados.
+    
+    Não se esqueça que a manutenção de um sistema de múltiplos projetos é bastante
+    trabalhosa e dificil de manter segura e por isso pedimos a colaboração de todo
+    mundo. Se puder nos comunicar quando for instalar algum software no seu espaço,
+    ficaríamos muito agradecidos/as :)
+    
+    Interfaces de comunicação e compartilhamento
+    --------------------------------------------
+    
+    Um possível espaço de interação entre os projetos é a Lista da Vizinhança[1]
+    (inscrição apenas para emails seguros, entre em contato para detalhes).
+    Cultive-a! Ao hospedarmos grupos e indivíduos, torcemos para que estes também
+    tornem-se responsáveis por zelar por tais espaços de convivência.
+    
+    Nossa vizinhança é também um local de articulação de rede, onde todos os grupos
+    e indivíduos que compartilham da estrutura por nós mantida se comunicam.
+    
+    Se os temas e estudos com os quais nos preocupamos também os/as inspiram, nós
+    os/as convidamos a participar dessas discussões. Para evitar a centralização
+    das discussões, propomos que vocês os discutam coletivamente, em seus projetos
+    e/ou grupos, tornando público os processos e resultados de tais discussões.
+    Para nós é fundamental tentar construir uma metodologia que possibilite a
+    disseminação pública de tais discussões.
+    
+    [1] $endereco_da_lista_da_vizinhanca
+    
+    Em solidariedade,
+    Coletivo $grupo
+
+[Versão inglesa](/english/hosting/terms).
diff --git a/docs/atividades/provedor/mensagens.md b/docs/atividades/provedor/mensagens.md
new file mode 100644
index 0000000..0dc5495
--- /dev/null
+++ b/docs/atividades/provedor/mensagens.md
@@ -0,0 +1,3 @@
+# Mensagens
+
+Templates para mensagens.
diff --git a/docs/atividades/provedor/mensagens/certs.md b/docs/atividades/provedor/mensagens/certs.md
new file mode 100644
index 0000000..34dad96
--- /dev/null
+++ b/docs/atividades/provedor/mensagens/certs.md
@@ -0,0 +1,28 @@
+# Informe: mudança de certificado
+
+De acordo com a política[1] de gestão de certificados X.509 usados nas
+comunicações TLS/HTTPS e dada a proximidade do vencimento do certificado atual,
+o `$coletivo` gerou um novo certificado SSL validado por
+`$certificate_authority`.
+
+A assinatura SHA1 do novo certificado é
+
+    SHA1 Fingerprint=$fingerprint
+
+Detalhes sobre o certificado estão em https://www.sarava.org/certs
+
+Tal informação pode ser verificada nas informações de segurança do seu
+navegador ao acessar um sítio com conexão segura. Detalhes a respeito podem ser
+encontrados no Manual de Criptografia[2].
+
+O certificado é válido para o domínio sarava.org e todos os seus subdomínios.
+Assim, está sendo utilizada conexão segura por padrão na maioria dos
+subdomínios de `$dominio` (por exemplo `www.$dominio`).
+
+No entanto, alguns sítios ainda podem estar sem conexão criptografada ou
+oferecerem links internos utilizando http.
+
+Em caso de dúvidas, basta entrar em contato :)
+
+[1] https://protocolos.fluxo.info/organizacao/comunicacao/cert/
+[2] https://manual.fluxo.info/criptografia/internet
diff --git a/docs/atividades/provedor/mensagens/downtime.md b/docs/atividades/provedor/mensagens/downtime.md
new file mode 100644
index 0000000..d8f9add
--- /dev/null
+++ b/docs/atividades/provedor/mensagens/downtime.md
@@ -0,0 +1,37 @@
+# Modelo de informe de downtime
+
+Português
+---------
+
+Estamos com uma queda inesperada de um de nossos servidores.
+
+Assim, alguns serviços ficarão inacessíveis nas próximas horas.
+
+    Servidor          : servidor.example.org
+    Problema          : não identificado
+    Tempo estimado    : 72 horas
+    Serviços afetados :
+      - Todas as listas de discussão.
+      - Contas de email.
+      - Todos os vservers hospedados para terceiros/as.
+      - Todos os sites hospedados nesse servidor.
+
+Outros serviços e servidores não estão afetados.
+
+English
+-------
+
+We're having an unexpected downtime in one of our servers.
+
+Then, some services will be unreachable in the next hours.
+
+    Server            : servidor.example.org
+    Problem           : N/A
+    Expected downtime : 72 hours
+    Services affected :
+      - All mailing lists.
+      - Email accounts.
+      - All third-party hosted vservers.
+      - All websites hosted in the server.
+
+Other servers and services are unaffected.
diff --git a/docs/atividades/provedor/servidor.md b/docs/atividades/provedor/servidor.md
new file mode 100644
index 0000000..b1415af
--- /dev/null
+++ b/docs/atividades/provedor/servidor.md
@@ -0,0 +1,72 @@
+# Administração do $servidor

+

+Este processo estabelece os critérios de administração do `$servidor`,

+doravante mencionado como `$servidor`, canalizador de fluxos ou simplesmente

+como servidor.

+

+# Classes RSP

+

+O servidor deve estar configurado de acordo com as seguintes classes do

+[Resource Sharing Protocol](https://rsp.fluxo.info):

+

+* `$classe` - `$classe_versao`.

+

+# Política de Administração

+

+0. Criação de Usuários:

+   a. Qualquer integrante do Coletivo pode ter uma conta no servidor, mas caso

+      tenha deve zelar pela segurança da mesma e concordar com a presente política.

+   b. A criação de usuários no servidor deve ser comunicada ao Coletivo e

+      seguir eventuais procedimentos existentes.

+   c. A senha da conta no servidor não pode ser compartilhada com outras contas

+      e deve ser razoavelmente forte.

+   d. Em caso de perda ou roubo de senha, o Grupo de Trabalho do servidor deve

+      ser contatado o quanto antes.

+

+1. Configuração: ao instalar ou efetuar qualquer tipo de configuração na máquina, procure:

+   a. Adicionar, se possível e/ou necessário, a configuração em sistema de

+      gestão servidores que o Coletivo utiliza.

+   b. Documentar os procedimentos utilizados ou informe ao Grupo de Trabalho do servidor.

+

+3. Comunicação: na medida do possível, comunique o Grupo de Trabalho do

+   servidor sobre alterações feitas na sua configuração configuração.

+

+# Quota

+ 

+O Coletivo alocará para si, em princípio, um limite garantido de `$disco` de

+espaço em disco no servidor. Toda a quantidade adicional de disco existente no

+servidor pode ser disponibilizada para outros grupos afins, mediante processo

+formal e sem garantias de backup.

+

+Quotas de uso de banda, processamento e memória ficam a cargo do Grupo de

+Trabalho do servidor ou de todo o Coletivo conforme necessidade ou mediante

+requisição.

+

+# Responsabilização

+

+Cabe ao Grupo de Trabalho formado pelas pessoas responsáveis por este processo

+seguir a política de administração e ainda:

+

+* Zelar para que o servidor possua o nível de segurança, privacidade e

+  estabilidade escolhidas.

+* Cuidar para que o downtime do servidor não passe de `$downtime`.

+* Efetuar as atualizações de softwares necessárias para o funcionamento básico

+  do servidor.

+

+A responsabilização neste processo não implica o compromisso com a

+administração de todas as camadas, aplicações, configurações e dados que

+existam ou possam existir no servidor, mas apenas com o funcionamento básico do

+servidor.

+

+# Dependências

+

+A realização deste processo depende da realização dos seguintes processos: 

+

+* `$dependencia`.

+

+# Sobre este texto

+

+O texto deste processo foi redigido utilizando o [Template para Administração

+de Servidor](/provedor/servidor). No caso de alterações que não dizem respeito

+apenas ao Grupo e que possam enriquecer tal template, favor submetê-las também

+upstream, isto é, ao texto do template. 

diff --git a/docs/atividades/provedor/sistemas.md b/docs/atividades/provedor/sistemas.md
new file mode 100644
index 0000000..5de3e67
--- /dev/null
+++ b/docs/atividades/provedor/sistemas.md
@@ -0,0 +1,64 @@
+# Configuração de sistemas padronizada e centralizada
+
+O presente processo estabelece o funcionamento de uma configuração de sistemas
+padronizada e centralizada. Levando em conta que o Coletivo pode lidar com
+muitas camadas de canalização informacional, cada um com diversos serviços
+configurados, backups locais e remotos e outras especificidades, torna-se
+interessante desenvolver um esquema de configuração centralizada, de forma a
+tornar fácil a manutenção, replicação e substituição dos ambientes assim como o
+compartilhamento de configurações com outros grupos.
+
+## Divisão de configuração e compartilhamento
+
+A configuração dos sistemas é dividida da seguinte forma:
+
+1. Especificação de camadas via [Resource Sharing Protocol
+   (RSP)](https://rsp.fluxo.info) de acordo com as necessidades e possibilidades
+   do Coletivo.
+2. Configuração efetiva dos sistemas através de aplicação especializada.
+
+## Compartilhamento de configurações
+
+No que concerne ao compartilhamento das configurações, a seguinte divisão é
+utilizada:
+
+1. Repositório privado, de acesso restrito ao Coletivo e contendo informações e
+   configurações cuja publicização é prejudicial ou desnecessária do Coletivo.
+2. Repositório público de configurações, denominado de
+   [http://padrao.sarava.org Padrão Saravá], contendo as configurações cuja
+   publicização auxilia no intercâmbio com outros grupos.
+
+Ambos os repositórios devem utilizar controle de versão e o Coletivo ainda é
+encorajado a utilizar configurações disponibilizadas por outros grupos, unindo
+assim esforços para a economizar trabalho.
+
+## Implementação
+
+A configuração efetiva deve ser obtida através do uso de um sistema como o
+[Puppet](http://puppetlabs.com), por ter diversos módulos disponíveis, uma
+linguagem de configuração bastante flexível e uma comunidade próxima que já o
+utiliza.
+
+As seguintes características de implementação devem ser satisfeitas:
+
+1. O repositório e o servidor `puppetmaster` devem rodar a partir de uma
+   instância cuja configuração de camadas é a mais segura do Coletivo e os dados
+   devem estar disponíveis somente via conexão segura.
+2. O repositório '''deve''' ter backups em diversos locais.
+3. O controle de versão utilizado para os módulos e demais configurações do `puppet` é o `git`.
+4. O `puppet` deve estar rodando no maior número possível de camadas do
+   Coletivo e obtendo suas configurações do `puppetmaster`.
+
+## Responsabilização
+
+É tarefa do Grupo de Trabalho de Configurações, composto pelas pessoas
+responsáveis pelo presente processo:
+
+1. Manter o máximo possível de configurações de sistemas do Coletivo segundo os
+   critérios estabelecidos no presente processo.
+2. Realizar auditoriais periódicas (com base anual) seguida relatório e
+   atualização da configuração dos sistemas conforme necessário.
+3. Manter um [padrão de configuração](https://padrao.fluxo.info) atualizado e
+   em funcionamento.
+4. Alterar, na medida do possível, a configuração dos sistemas e documentações
+   relacionadas conforme solicitações do Coletivo.
diff --git a/docs/atividades/provedor/sistemas/dns.md b/docs/atividades/provedor/sistemas/dns.md
new file mode 100644
index 0000000..14404d5
--- /dev/null
+++ b/docs/atividades/provedor/sistemas/dns.md
@@ -0,0 +1,19 @@
+# Administração de configurações de DNS dos domínios do Coletivo
+
+Este processo estabelece as linhas gerais para a administração de configurações
+DNS dos domínios do Coletivo.
+
+# Tarefas
+
+Cabe ao Grupo de Trabalho formado pelas pessoas responsáveis pelo presente
+processo:
+
+1. Manter a configuração de DNS dos domínios do observando os critérios de
+   segurança cabíveis.
+2. Atender as requisições do Coletivo de mudanças de configuração de DNS.
+
+## Dependências
+
+A realização deste processo depende da realização dos seguintes processos:
+
+* [Gerenciamento de domínios](/provedor/sistemas/dominios).
diff --git a/docs/atividades/provedor/sistemas/dominios.md b/docs/atividades/provedor/sistemas/dominios.md
new file mode 100644
index 0000000..a002e5b
--- /dev/null
+++ b/docs/atividades/provedor/sistemas/dominios.md
@@ -0,0 +1,41 @@
+# Gerenciamento de domínios
+
+Os domínios utilizados pelo Coletivo constituem seu ''namespace'' no qual podem
+definir endereços de acesso público e privado. Sendo indispensáveis para a
+autonomia básica do Coletivo e para a possibilidade de hospedagem de outros
+grupos, o gerenciamento de domínios constitui um processo de garantia dessa
+autonomia, especialmente se levado em conta que o DNS é um sistema
+centralizado, pouco transparente, anti-democrático e de tendência
+centralizante.
+
+O presente processo estabelece um grupo de trabalho para o gerenciamento de
+domínios, cujas tarefas envolvem:
+
+1. Renovação dos domínios com '''antecedência''' ao prazo de vencimento da
+   mesma, solicitando ao grupo de contabilidade os gastos necessários para cumprir
+   tal tarefa. 
+2. Aplicação de política de privacidade e segurança à configuração dos
+   domínios, incluindo auditoria periódica para a verificação dessas
+   configurações.
+3. Registro de novos domínios conforme a necessidade e formalização pelo Coletivo.
+4. Manter o Coletivo informado sobre essas tarefas.
+
+## Responsabilização
+
+As pessoas responsabilizadas por esse grupo de trabalho precisam ter condições
+de realizar operações financeiras internacionais com cartão de crédito.
+
+## Domínios do Coletivo
+
+Os domínios do Coletivo são:
+
+* domínio1
+* domínio2
+
+Vale observar que:
+
+1. Outros domínios podem ser adicionados na lista mediante procedimento formal
+   para a alteração da mesma.
+2. Por esse processo fica automaticamente aprovado o gasto de recursos
+   financeiros do Coletivo para o pagamento da renovação/registro dos domínios do
+   Coletivo.
diff --git a/docs/atividades/travel/README.md b/docs/atividades/travel/README.md
new file mode 100644
index 0000000..0d4ec11
--- /dev/null
+++ b/docs/atividades/travel/README.md
@@ -0,0 +1,19 @@
+# Viagens
+
+Templates para viagens. Veja também [The Travel Lite Strategy](https://blog.fluxo.info/travel/lite).
+
+## Dicas
+
+* Para não perder coisas durante as viagens, mantê-las sempre agrupadas num
+  mesmo local.
+* Se possível, deixe sempre mala(s) sempre prontas e um procedimento padrão
+  para viagens ou evacuação.
+* Proteja seus pertences, não vacile!
+* Roupas:
+    * Para lavar a pouca roupa, use:
+      * [Vodca](http://www.tiosolid.com/vodka-as-10-outras-utilidades-alm-de-beber) ou outra bebida.
+      * Álcool gel, que pode ser mais barato e fácil de encontrar.
+    * Para minimizar a lavagem de roupas, deixe-as tomando ar após o uso.
+    * Camisetas podem ser penduradas de cabeça pra baixo para que o ar circule
+      na região das axilas, evitando a formação de colônias de bactérias.
+    * Pendurar camisas e camisetas do avesso em cabides.
diff --git a/docs/atividades/travel/checklist.md b/docs/atividades/travel/checklist.md
new file mode 100644
index 0000000..2817abb
--- /dev/null
+++ b/docs/atividades/travel/checklist.md
@@ -0,0 +1,3 @@
+# Checklist
+
+Checklists de viagem.
diff --git a/docs/atividades/travel/checklist/basico.md b/docs/atividades/travel/checklist/basico.md
new file mode 100644
index 0000000..9f9be3d
--- /dev/null
+++ b/docs/atividades/travel/checklist/basico.md
@@ -0,0 +1,16 @@
+# Checklist básico
+
+Micro kit de ferramentas
+------------------------
+
+* Clipes de papel.
+* Lâmina de barbear.
+* Elásticos.
+* Isqueiro?
+
+Kit básico
+----------
+
+* EPI.
+* Escova de dentes.
+* Fio dental.
diff --git a/docs/atividades/travel/checklist/carteira.md b/docs/atividades/travel/checklist/carteira.md
new file mode 100644
index 0000000..f824f48
--- /dev/null
+++ b/docs/atividades/travel/checklist/carteira.md
@@ -0,0 +1,13 @@
+# Carteira cypherpunk
+
+* Band-aid.
+* Kit reparos de bike.
+* Limpador interdental plástico.
+* Telefones de emergência.
+* Memórias e adaptador, incluindo [Bootless](https://bootless.fluxo.info) e [Tails](https://tails.boum.org).
+* Fingerprints digitais.
+* Saco zip para coletas.
+* Régua de papel (mini fita métrica).
+* Palheta.
+* [Ficha de saúde](/pessoal/saude).
+* Modelo de Habeas corpus.
diff --git a/docs/atividades/travel/checklist/completa.md b/docs/atividades/travel/checklist/completa.md
new file mode 100644
index 0000000..68449cc
--- /dev/null
+++ b/docs/atividades/travel/checklist/completa.md
@@ -0,0 +1,20 @@
+# Checklist Completa para Viagens
+
+* Itens básicos da Checklist Mínima.
+* Máquina fotográfica, capa, cabo, bateria sobressalente, carregador, memória
+  sobressalente e adaptador de memória.
+* Canivete.
+* Saco de dormir.
+* Roupas (1 semana).
+  * Camisetas.
+  * Calças.
+  * Blusas.
+  * Camisa social.
+  * Roupas íntimas.
+  * Meias.
+  * Pisantes.
+  * Cintos.
+  * Verão:.
+    * Bermudas.
+    * Havaianas.
+    * Calção de banho.
diff --git a/docs/atividades/travel/checklist/expedicao.md b/docs/atividades/travel/checklist/expedicao.md
new file mode 100644
index 0000000..0f69b16
--- /dev/null
+++ b/docs/atividades/travel/checklist/expedicao.md
@@ -0,0 +1,23 @@
+# Checklist para Expedições
+
+Equipamentos pequenos e úteis para expedições científicas:
+
+* Itens da checklist de fuga.
+* Placa solar carregadora ou manivela.
+* Kit médico.
+* Ração sem cozimento.
+* Saco zip para amostras.
+* Sacos para coleta de rejeitos.
+* Saco impermeável.
+* Serra de dedo/mão circular de sobrevivência em aço.
+* Pederneira, apito, bússola, isqueiro.
+* Purificador de água.
+* Tela mosquiteira e repelente de insetos.
+* Saco de dormir tipo múmia/sarcófago e capa impermeável.
+* Isolante térmico.
+* Rede leve com proteção mosquiteira.
+* Botas.
+* Rádio.
+* Relógio.
+* Espelho.
+* Tesoura.
diff --git a/docs/atividades/travel/checklist/fuga.md b/docs/atividades/travel/checklist/fuga.md
new file mode 100644
index 0000000..d5601df
--- /dev/null
+++ b/docs/atividades/travel/checklist/fuga.md
@@ -0,0 +1,9 @@
+# Mala de fuga
+
+Incluindo:
+
+* Água.
+* Paracord.
+* Troca de roupa.
+* Papel higiênico.
+* Álcool potável (para chapar, esquentar, relaxar e lavar a roupa)?
diff --git a/docs/atividades/travel/checklist/minima.md b/docs/atividades/travel/checklist/minima.md
new file mode 100644
index 0000000..c070b68
--- /dev/null
+++ b/docs/atividades/travel/checklist/minima.md
@@ -0,0 +1,57 @@
+# Checklist Mínima para Viagens.
+
+* Documentos:
+  * Micro-pasta para panfletos, papéis e documentos.
+  * Passaporte(s) (com capa) e xerox.
+  * Passagens.
+  * Saldo/extrato bancário.
+  * Seguro saúde.
+  * Cartas de convite e/ou reservas de hospedagem.
+  * Carteira de alberguista.
+  * Carteira de motorista nacional e internacional.
+  * Registro de equipamentos na Receita Federal.
+  * Lista de Contatos.
+  * Esta checklist.
+* Finanças:
+  * Dinheiro e comprovantes de câmbio.
+  * Cartões de crédito e débito internacional.
+  * Cartões de transporte do local de destino.
+* Equipos:
+  * Corrente de pescoço para prender chaves.
+  * Óculos (de sol e de leitura).
+  * Caderno de notas, grafite, lapiseira.
+  * Cartões de visita.
+  * Smartphone com:.
+    * Mapas offline.
+    * Todos os ingressos, tickets etc necessários para a viagem.
+    * Carregador USB, cabo USB e fones de ouvido.
+  * Laptop.
+  * Tablet.
+  * Playlist / músicas!
+* Micro-mala de higiene:
+  * Remédios.
+    * Analgésico.
+    * Anti-térmico.
+    * Esterilzador de água.
+    * Protetor solar
+    * Pomada medicinal (Tiger Balm, Arnica, etc).
+  * Mini-shampoo, mini-condicionador e mini-sabonete OU sabão de côco em pedra (corpo e roupas).
+  * Pasta de dentes, escova e fio dental.
+  * Mini-[pedra de allumbre](https://eswikipedia.org/wiki/Alumbre)..
+  * Máscaras PFF2.
+  * Álcool gel.
+* Roupas (1 semana):
+  * Toalha atlética.
+  * Capa de chuva.
+  * 3 roupas íntimas.
+  * 2 pares de meias.
+  * Verão:
+    * 2 camisetas dry fit.
+  * Inverno:
+    * Palmilhas isolantes.
+    * 2 conjuntos de segunda pele.
+    * Jaco.
+    * [Polar](http://enwikipedia.org/wiki/Polar_fleece Fleece)..
+    * Par de luvas.
+    * Cachecol.
+    * Gorro.
diff --git a/docs/atividades/travel/checklist/roadwarrior.md b/docs/atividades/travel/checklist/roadwarrior.md
new file mode 100644
index 0000000..1a0623f
--- /dev/null
+++ b/docs/atividades/travel/checklist/roadwarrior.md
@@ -0,0 +1,21 @@
+# RoadWarrior
+
+Bill Of Materials - Road Warrior - To be used in the field.
+
+* Laptops e bastante bateria.
+* Micro SD Cards e pendrives.
+* HDs de 2.5'' slim para diversos sistemas: Qubes, OpenBSD, etc.
+* Smartphone de testes.
+* Chaves Torx para smartphones.
+* 32 and 64 bit ISOs: debian, ubuntu, tails, kali.
+* LAN/WLAN router, preferably with OpenWRT.
+* Réguas de luz.
+* Adaptadores de tomada.
+* Hub USB 3.0 com boa fonte.
+* Kit de ferramentas.
+* Discos externos.
+* Pendrives.
+* Cartões microSD e adaptadores.
+* SIM cards.
+* Adaptador VGA para datashow HDMI.
+* [Material para oficinas](https://autodefesa.fluxo.info/grupos/oficina.html#material-de-apoio).
diff --git a/docs/atividades/travel/checklist/trampo.md b/docs/atividades/travel/checklist/trampo.md
new file mode 100644
index 0000000..16f5c38
--- /dev/null
+++ b/docs/atividades/travel/checklist/trampo.md
@@ -0,0 +1,13 @@
+# Checklist do Trampo
+
+Itens pessoais pra deixar na firma ou oficina de trabalho.
+
+* Higiene básica:
+  * Escova de dentes
+  * Pasta de dentes
+  * Fio dental
+  * Palitos de dentes não-descartáveis
+* Equipos:
+  * Protetor auricular
+  * Dinheiro reserva
+  * Carregadores de bateria
diff --git a/docs/atividades/travel/checklist/urbano.md b/docs/atividades/travel/checklist/urbano.md
new file mode 100644
index 0000000..4349bfc
--- /dev/null
+++ b/docs/atividades/travel/checklist/urbano.md
@@ -0,0 +1,24 @@
+# Urbenauta
+
+Kit verão
+---------
+
+* Camiseta dry fit ou sem camisa.
+* Calção de banho.
+* Sacola zip grande.
+* Cycling overshoes.
+
+Kit inverno
+-----------
+
+* Kit verão.
+* Corta vento.
+* Manteiga de cacau.
+
+Mochila
+-------
+
+* Kit básico.
+* Capa de chuva para mochila.
+* Kit chuva verão ou inverno.
+* Sacola dobrável para compras.
diff --git a/docs/atividades/travel/preparacao.md b/docs/atividades/travel/preparacao.md
new file mode 100644
index 0000000..3c79693
--- /dev/null
+++ b/docs/atividades/travel/preparacao.md
@@ -0,0 +1,34 @@
+# Preparação Doméstica
+
+* Emitir avisos de viagem, ligar resposta automática de férias e fornecer
+  contatos de emergência a partes interessadas, por exemplo:
+  * Família.
+  * Amigos.
+  * Clientes.
+  * Contador.
+  * Grupos e projetos.
+* Contabilidade:
+  * Adiantar pagamentos.
+  * Situação de cartão de crédito.
+  * Colocar contas em débito automático.
+  * Fechar operações comerciais desnecessárias (empresas, contas, etc).
+* Combinar cuidadores/as para:
+  * Animais domésticos e públicos.
+  * Casas e escritórios (caseiro ou visitas periódicas).
+  * Tarefas administrativas.
+  * Procurações e demandas legais, administrativas e contábeis.
+* Manutenção preventiva em equipamentos, por exemplo:
+  * Sincronizar arquivos.
+  * Limpar servidores.
+  * Checar nobreaks.
+  * Backups e redundância.
+  * Dosagem de cloro em mini-estação de tratamento de água.
+  * Suplente para administração de datancenters e outras instalações.
+* Pessoal:
+  * Preparação do TPC.
+  * Declaração Canária.
+  * Modo nomail em listas.
+  * Cortar cabelo.
+  * Trancar matrículas em cursos.
+  * Guardar pertences. 
+  * Checar vistos e documentação.
diff --git a/docs/english/README.md b/docs/english/README.md
new file mode 100644
index 0000000..8a8e033
--- /dev/null
+++ b/docs/english/README.md
@@ -0,0 +1 @@
+# English Templates
diff --git a/docs/english/network.md b/docs/english/network.md
new file mode 100644
index 0000000..3793d5a
--- /dev/null
+++ b/docs/english/network.md
@@ -0,0 +1,80 @@
+# Principles and process for a network of collectives
+
+Originally [Network intentions and process letter](https://rectech.sarava.org/publico/processo).
+
+About
+-----
+
+The `$network` network is a forum of anti-capitalist, anti-fascist, anti-sexists,
+anti-homophobic and anti-racists tech collectives that rejects any form of
+social domination and prejudice.
+
+The goal of the forum is to allow interchange, mutual aid and cooperation among
+collective members and also to be a public interface for debates.
+
+Then, `$network` is not a collective but a network.
+
+How it works
+------------
+
+The network by default is in a dormant state until be activated, when for example
+some collective(s) suggest an activity, meeting or cooperation.
+
+Membership process
+------------------
+
+Membership in the `$network` network is restrictet to collectives that comply with
+afinity, trust and commitment to the network. New collectives can join the network
+after positive decision making process and if they agree with this letter.
+
+Once inside the network, collectives can determine which of its members has to
+be subscribed or unsubscribed from the `$network` network communication platforms.
+
+When joining on the `$network` network communication platforms, each individual has
+to present her or himself and state that will act in a constructive way,
+otherwise will be subjected to unsubscription.
+
+Decision making process
+-----------------------
+
+No person or group can take decisions that affect the network autonomy before
+consulting the network and getting a positive consensus.
+
+Decisions in the network are based on proposals that have to be sent to the
+network's closed discussion list.
+
+The minimum deadline for decisions is two weeks up to postponing and the
+decisions are taken by consensus. If a collective doesn't manifests about a
+proposal it will be considered that the collective agrees with the proposal.
+
+Privacy
+-------
+
+The `$network` network is semi-public, i.e, part of it's communication and
+organization is restricted to the member collectives while other part is public
+and open to any group or person.
+
+Informations that flows in private communication instances needs authorization
+to be shared in public media (declassification).
+
+It's a choice of each member to stay or not as a private member.
+
+Communication interfaces
+------------------------
+
+The `$network` network has the following communication instances:
+
+  - Closed list with archives restricted to its members.
+  - Moderated announcement list with open subscription and open archives.
+  - Collaborative web platform.
+
+Such interfaces are hosted by member or trusted collectives and it's access and
+existence are crucial to the maintenance of the network memory.  Then, it's
+imprescindibile to the network to have backups of these platform when needed.
+
+About this text
+---------------
+
+This process was based on the "Template for Network Intentions and process letter v1.0".
+License for the document: GNU Free Documentation License:
+http://www.gnu.org/copyleft/fdl.html
diff --git a/docs/english/organization.md b/docs/english/organization.md
new file mode 100644
index 0000000..0702bd8
--- /dev/null
+++ b/docs/english/organization.md
@@ -0,0 +1,233 @@
+# Collective Action Protocol

+

+The protocol was written to make possible a generic adoption by groups but at

+the same time it attempt to solve specific problems that aren't necessarily

+shared by a gvin group. Then, it's not intended to be "The Collective Protocol"

+but instead a suggestion about how to shape a collective protocol.

+

+Suggestion is to read it as how could a collective protocol look like instead a

+sugestion of adoption, especially because usually the needs for a process are

+different as here we're trying to solve a different set of problems.

+

+The Collective Action Protocol seems to be both a stateless (at it's informal

+part) and stateful (at it's formal part) protocol. It has some inspiration

+from:

+

+* Games, altough it's unknow how a parallel with game theory could be traced

+  (could this protocol be considered a game where the objective is a win-win

+  outcome attempting to maximize the collective effort?).

+* Free and open source software development processes (although this protocol

+  makes the 'benevolent dictator' obsolete as behaviour, purpose and telealogy

+  turns to be mean properties emerging internally from the processes and

+  peoples' wishes and mutual relationship). It can be thought as a social

+  software (culture).

+* Ways labor division can be organized to better fill collective needs and

+  autonomy while encouraging people to work together.

+

+Characteristics

+---------------

+

+For sinthetic purposes, most of the discussion was split from the protocol

+text. Perhaps this compression let a lot of helpful information to be missing,

+so here comes a list of the main properties this protocol tries to achieve:

+

+* Resilience, robustness and failover.

+* Ensure some collective autonomy is guaranteed (through formal process having

+  responsibility attached) while not blocking the self-organizing efforts using

+  to kinds of processes (formal and informal). This means in some way to

+  overcome the [The Tyranny of

+  Structurelessness](http://en.wikipedia.org/wiki/Tyranny_of_Structurelessness)

+  while not failing back to over-structuration, bureaucracy, etc and at the

+  same time tries to deal with apathy and missparticipation.

+* For formal processes, splits decision-making (i.e, the step where the

+  collective evals if a given proposal is pertinent an deserves the collective

+  moral support) from the resposibility assignment (step where people actually

+  volunteer to do the tasks) in a way that just formal processses that are

+  under responsibility can be counted as processes that will very probably

+  happen, so if in the proposal/discussion/decision steps just the content of

+  the proposal is evalued, the responsibility assignment is a filter where just

+  processes that finds people to achieve them are able to pass.

+* Leting a process be also a registry eases the integration with a ticket system.

+

+Limitations

+-----------

+

+Some limitations of the protocol are:

+

+* Not sure whether it's scalable. Maybe it was set for usage inside a small

+  affinity group so it might not fit to big groups where people has not

+  affinity between themselves.

+* It does not deal with connections/disconnections, i.e, the protocol do not

+  define how someone joins or leaves the group.

+* As all protocols depends on it's usage, it is not a guarantee by itself that

+  things are going to happen in the collective. The protocol just states how

+  the energy is spent in the collective process but have no influence in the

+  desire to act or not to act.

+* It does not state what are the communication channels (both for formal and

+  informal communications) and how they should be used. In fact, as this really

+  varies a lot from collective to collective so it was chosen to leave that

+  specific communication structure out of the Collective Action Protocol so it

+  would be easier to share and have another protocol taking care of

+  informational channels.

+

+Formality and informality

+-------------------------

+

+In this protocol, what is a formal and what is an informal process really

+depends in how the collective wants to extend it's autonomy, so it's not a

+thing defined withing the protocol. Examples of formal and informal processes

+can be:

+

+* Informal processes: meetings, dinners, researching, write texts, code, talk

+  with people, wikifarming and everything else that the collective thinks that

+  does not changes the collective autonomy.

+* Formal processes: the main activities the group is commited to do and what is

+  crucial for them to happen and to keep the collective autonomy.

+

+Collective Action Protocol

+--------------------------

+

+* Version: 0.1.

+* Raw english translation version (related to protocol version): 0.1.

+* License: Sarava Content Distribution License (no translation for now :/)

+

+Processes and autonomy 

+----------------------

+

+Everything that happens in the Collective is a process. Processes has different

+manifestations but are mainly fluxes and the registry of these fluxes

+(memory/information).

+

+There are two kinds of processes:

+

+* Formal processes

+    * Shape/form predefined by collective consensus AND

+    * Needs/use the collective autonomy THUS

+    * Needs to be followed by a minimum responsabilization so the process do

+      not fail

+

+* Informal processes

+  * Shape/form not needed to be predefined AND

+  * Do not need/use the collective autonomy THUS

+  * Do not need to be under the resposability of someone, i.e, an informal

+    process that do not happen doesn't affect the collective autonomy

+

+Activities without information in the collective cannot be considered by

+processes (formal or informal) as these activities do not have information

+equality/isonomy in the collective. To have information about a process is a

+requisite for participation and then an activity without information inside the

+collective cannot be considered as process.

+

+The basic autonomy of the Collective, i.e, the minimum autonomy that allows

+it's existence according to this protocol is the existence of secure and

+private communication channels that allows the existence of collective

+processes (formal or informal). Without these channels, the basic collective

+autonomy is seriously damaged as well as the application of this protocol. All

+aditional autonomy in the collective (i.e, autonomy that is not contained in

+the basic autonomy) should be defined with formal processes.

+

+A collective member act inside the collective when use it's resources or the

+collective name. By the other hand, a collective member act outside of the

+collective when do not use such resources or the collective name. Collective

+members do not make actions (inside or outside the collective) that

+consciouslly can cause damage to the collective autonomy.

+

+Formal processes

+----------------

+

+Each formal processs is an instance of the following state diagram:

+

+       .------------------->-----------------.

+      /  .----------<--------------<-------.  \

+     |  '                                   \  \

+     |  |               .------>-----.       \  \

+     |  |              |              \       \  \

+    Proposal -----> Discussion ->-.    \       \  \

+       |  ^            |           \    \       \  \

+       |  |            |            \    \       \  \

+       |   `----<-----'             |     \       \  \

+       |                            |      |       \  \

+        `------>----- Decision --<--'      |        \  \

+                         | |               |         \  \

+                         | |               |          | |

+    Responsibility --<---' '------> Archiving --->---'  ;

+      Assignment --------->---------' ^    \           /

+        ^  |              ___________/      `---<-----'

+        |   \           .'

+        |    `--> Achievement ->--.

+        |           |  |           \

+        |           |  |           /

+         `----<-----'   `-----<---'

+

+* Proposal: step where an idea of a formal process is presented to the

+  collective. The idea -- or description -- can come for the Archive, from a

+  previous Discussion, from an informal process that needs to be formalized or

+  from a person or group from inside or outside the collective. General

+  recomendation is to give a good explanation of the idea containing: deadline

+  sugestion, process life cycle, responsibility assignment criteria and

+  deadline and recomendations for emergencies (when appliable).

+

+* Discussion:

+    * It's not a mandatory step, but has importance anyway.

+    * Changes to proposals make the formal process go back to the Proposal

+      state. Proposals that do not follow to the Decision step or do not get

+      changes until it's deadline should be archived.

+    * Changed proposals that come from outside the collective or that have

+      external groups or persons participation should be sent back also to the

+      external group/person, despite these persons/groups do not participate in

+      the internal discussion at the collective. If these external

+      people/groups agree with the changed proposal, then the formal process

+      proceeds with the discussion using the changed proposal. If that doesn't

+      happen, i.e, these external people/groups don't agree with the changed

+      proposal, then the formal process is archived (except if the external

+      parties provide another changed proposal or more arguments to the

+      discussion).

+

+* Decision:

+    * Through consensus and the active participation depends in following the

+      information required by the proposal.

+    * If there's no consensus about the decision of a proposal it's

+      automatically blocked with the possibility to extend it's deadline.

+    * Silence regarding a proposal is considered as an agreement.

+    * Deadline: general recomendation is to set deadlines relative to the

+      average time needed by active people in the collective to take into

+      account, discuss, make changes and ask for eventual postponing. Processes

+      are elegible to postponing or advance it's deadline with an explicitly

+      request from someone from the collective. If there's no such request, the

+      initial deadline is assumed.

+    * Approvals from proposals coming from outside the collective or that have

+      external people/groups involved are communicated about the approval just

+      after the responsibility assignment.

+

+* Responsibility assignment

+    * Concerns the minimization of points of failure.

+    * Responsibilization is a volunteer action but requires the submission of a

+      commitment/responsibilization term affirming that the person:

+        * Has knowledge about the procedure in question.

+        * Is gonna achieve it under the estimated deadline and is gonna keep

+          the collective informed about the task.

+        * Will inform the collective in a reasonable timeframe if cannot

+          continue to be involved with the process so the collective can keep

+          the process going, assign new responsibilities or finnish it and send

+          to the archive.

+    * Non-accomplishment with a process compromises the ability of someone to

+      be responsible for other tasks.

+    * Formal processes that are approved but, after the responsibility

+      assignment deadline, have unsufficient responsibilization assigned,

+      should be sent to the archive. Proceesses in the archive were previously

+      approved cannot be sent back directly to the responsibilty assigment and

+      should instead go to the proposal step.

+    * In case of proposals coming from outside the collective or that have

+      external people/groups involved, these people/groups should be informed

+      of the approval just after the responsibility assignment, i.e, at the end

+      of this step.

+

+* Achievement

+    * Just formal processes with sufficient responsibility assignment can go to

+      the achievement step. Processes that were already achived goes to the

+      archive.

+    * Formal processes that were not achieved in the deadline should come back

+      to the Responsibility assignment step. In a similar way, processes whose

+      assigned people cannot doing it should come back to the Responsibility

+      assignment step if the number of assigned people is smaller than the

+      required.

diff --git a/docs/english/provider/README.md b/docs/english/provider/README.md
new file mode 100644
index 0000000..44fc700
--- /dev/null
+++ b/docs/english/provider/README.md
@@ -0,0 +1 @@
+# Internet Services Provider
diff --git a/docs/english/provider/hosting/README.md b/docs/english/provider/hosting/README.md
new file mode 100644
index 0000000..6d34898
--- /dev/null
+++ b/docs/english/provider/hosting/README.md
@@ -0,0 +1 @@
+# Hosting
diff --git a/docs/english/provider/hosting/letter.md b/docs/english/provider/hosting/letter.md
new file mode 100644
index 0000000..5bfaff4
--- /dev/null
+++ b/docs/english/provider/hosting/letter.md
@@ -0,0 +1,59 @@
+# Hosting Letter

+

+    $collective Hosting Letter

+    --------------------------

+    

+    $collective is part of an intersection of various groups that discuss politics and

+    technology in different ways. We work with internet servers turned to various

+    cooperative goals. Then, our ideia is to colaborate with groups/projects that

+    are part of mutual and multiple aid and support.

+    

+    $collective is an autonomous project kept by a collective of volunteers. One of our

+    main goals is the collective creation of public spaces, common areas with projects and

+    groups that intend to enforce and straighten coexistence.

+    

+    Our intention is not just offer a "hosting service" and then we're not available

+    for groups that just want such thing. We want that groups we host colaborate with

+    the construction of a neighborhood, a rhizome, meaning that technology doesn't have to be

+    a barrier, but exactly the opposite. As technology is also a social construction,

+    its purposes, its configurations and the processes it interferes with can't

+    impose themselves independently of the choices made by the social groups where it's used.

+    

+    The internet is not only an environment of cooperation, but also of apropriation and

+    exploitation of common goods. We understand that it just turns essentially into a

+    public space when people can control their production and access means, things that

+    don't happen on corporate and governmental spaces. Because of this we try to

+    create public spaces, non-corporative and non-governmental and we hope that

+    groups we host colaborate to the construction of such spaces.

+    

+    During the construction of these kind of spaces, we make discussions where we try to

+    discover themes such as culture, society, technology, activism, social change

+    and many others. Such a research, when possible, is shared pubicly.

+    

+    We research the political implications of technology and develop systems and

+    instruments using different political values. We also keep a political dialogue

+    in the logics of theory/practice.

+    

+    So, one of our proposals is to collectivelly establish a network of mutual

+    support among groups and individuals interested in sharing the same physical

+    structure to share their knowledges, activities and researches.

+    

+    We attempt then to break the relation between service provider/clients,

+    because we're not service providers and the groups/individuals we host are not

+    our clients.  We both make part of the same collaboration network where diverse

+    interests converge towards mutual empowerment. And who knows if such way of

+    organizing things won't spread to other parts of society.

+    

+    Thinking about knowledge distribution and with an incentive to new groups

+    interested in keeping their own server infrastructure, we try to share the most of

+    our organization scheme.

+    

+    And remember: for us, $collective is not just a hosting system or a service provider.

+    

+    Interesting links:

+    

+     - Researches available: http://wiki.$domain

+     - Configurations and operational procedures: http://padrao.$domain

+    

+    In solidarity,

+    $collective Group

diff --git a/docs/english/provider/hosting/policy.md b/docs/english/provider/hosting/policy.md
new file mode 100644
index 0000000..554627e
--- /dev/null
+++ b/docs/english/provider/hosting/policy.md
@@ -0,0 +1,45 @@
+# Hosting Policy

+

+    $collective Group Hosting Policy

+    --------------------------------

+    

+    1. The Collective reserves to istelf the power to host or discontinue the

+       hosting of any group or individual according to the ethical, political and

+       practical principles of the Collective.

+    

+    2. In the case of hosting discontinuation for a given group, the Collective

+       commits itself to inform the hosted part with sufficient time and to make

+       available the hosted data.

+    

+    3. Groups and individuals are just hosted by the Collective if they want to

+       have a mutual relation of resources and activity sharing.

+    

+    4. Once the hosting partnership is created, the Collective must be informed of

+       actions and ways the hosted part is taking if those affects the Collective. By

+       the other hand, the Collective commits to inform the hosted part of anything

+       that can affect it.

+    

+    5. The terms of partnership must be clear in the sense of the commitment

+       between both sides on support, maintenance and development of the host and

+       sites.

+    

+    6. The hosted part is responsible for the hosted content and the Collective

+       cannot suffer legal consequences of improper or illegal content. Anyway the

+       Collective will make everything possible to protect the identity and privacy of

+       the hosted part.

+    

+    7. The relations should be established as transparently as possible, avoiding

+       hidden or manipulated information by both parts.

+    

+    8. The relations have the purpose of solidarity on knowledge, complementarity

+       on actions and exchange among groups, being vital to achieve ways of mutual

+       teaching-learning and develop policies that unite groups towards social and

+       political changes.

+    

+    9. The Collective commits itself to inform at least in general ways its

+       security and privacy policies on the hosting platforms.

+    

+    10. Hosting of social movements with sensitive content are kept, when possible,

+        hosted on platforms abroad.

+    

+    11. The hosting consists in cooperation and not in service providing.

diff --git a/docs/english/provider/hosting/refusal.md b/docs/english/provider/hosting/refusal.md
new file mode 100644
index 0000000..7cd4648
--- /dev/null
+++ b/docs/english/provider/hosting/refusal.md
@@ -0,0 +1,22 @@
+# Refusal hosting letter

+

+    Hi $requisitante,

+    

+    Unfortunatelly we can't host the project you requested because:

+    

+      - We think it doesn't match the etical principles we adopt[1].

+    

+      - And/or we consider it matches the kind of projects we have a critical

+        position with[2].

+    

+    We believe that there's not just one way to fight. We also don't believe that

+    our etical principles and our criticisms represent the "right" viewpoint.

+    Our viewpoint just reflect the conclusions we got after a lot of discussions.

+    We try just to be coherent with what we believe and that's the reason why we

+    can't accept your request.

+    

+    We don't want for this statement to mean that we want to give no value for

+    the thing your project do or about what do you believe.

+    

+    [1] See http://encontro.fluxo.info/Principal/ConjuntoDePrincipiosEticos

+    [2] See http://wiki.$dominio

diff --git a/docs/english/provider/hosting/terms.md b/docs/english/provider/hosting/terms.md
new file mode 100644
index 0000000..91b5f3f
--- /dev/null
+++ b/docs/english/provider/hosting/terms.md
@@ -0,0 +1,92 @@
+# Hosting Terms

+

+    Hi :)

+    

+    Agreement on Hosting

+    --------------------

+    

+    We discussed and we agree to offer hosting as you requested. Now, in order for we to

+    effectivelly maintain this hosting, we need to:

+    

+      1. State what is our commitment  in relation to this hosting.

+      2. That you and/or your group agree with the present term of agreement and

+         with our Hosting Policy.

+    

+    These are mutual commitment agreements, where we explain what is our commitment

+    with the hosting and that the hosted part needs to agree so we can keep such

+    relation.

+    

+    In case you agree with the terms of this letter and accept our Hosting Policy,

+    just reply saying so and the hosting will start as soon as possible. :)

+    

+    Our commitment

+    --------------

+    

+    We commit ourselves to keep the hosting working. The hosting maintenance

+    happens through volunteer and responsible work.

+    

+    The used infra-structure is stable, but subject to eventual power and network

+    outages or even more sensitive problems.

+    

+    Then, sometimes hosting can go offline. We will always be allert and we care

+    for security and integrity of the hosted data. But, for a lot of reasons, we

+    cannot garantee the total availability or even the eternity of such data.

+    

+    We commit ourselves as much as possible to keep security copies of the data we

+    host. But we ask for you to also arrange, as much as possible, backup copies of

+    your data.

+    

+    Our group is composed by people that do a lot of tasks. The most important and

+    sensitive tasks, such as hosting, are dependent to other taks and each one is

+    associated to a workgroup of responsible persons.

+    

+    It may happen that someone leaves a workgroup and eventually some tasks will lack

+    commited people to get them accomplished. It's on this sense that we garantee

+    hosting: according to the available workforce at our group. It's possible that,

+    in the future, something happens and we stop hosting in a given platform.

+    But, if we do so, we garantee that it won't happen from night to day and we'll

+    give enough time for you and your project to migrate the data somewhere else.

+    

+    We also have the commitment to inform, when you ask, our procedures according to

+    our accounting policy. Such procedures vary from privacy and security policies

+    to choices of platforms and our group's situation.

+    

+    As our procedures can change with time, we recommend you to ask for procedures

+    descriptions when you feel necessary.

+    

+    We have our limitations but we'll keep things working as much as we can. :)

+    

+    Your commitment

+    ---------------

+    

+    We hope that you and/or your project use the offered resource with wisdom.

+    Don't ask for websites and tools if you will abandon them. If you install your own

+    programs, please have the responsibility to keep it up-to-date as security holes at

+    your place can compromise other hosted projects.

+    

+    Please don't forget that the maintenance of multiple projects needs a lot of work

+    and is difficult to keep secure. Then we ask for everyone's collaboration. We would be

+    very pleased if you informed us about your plans to install tools in your space. :)

+    

+    Sharing interfaces

+    ------------------

+    

+    A possible space for interactions among projects is the Neighborhood Mailing

+    List[1] (subscription just for sufficiently secure mail accounts, get in touch for

+    more information). When we host groups and individuals, we hope that they will also

+    be responsible in what comes to taking care of such spaces.

+    

+    Our neighborhood is also a place for articulations, where all groups and

+    individuals sharing the same infra-structure can communicate between

+    themselves.

+    

+    If the subjects we research are inspiring for you too, we invite you to

+    participate in such discussions. To avoid centralization, we propose you to

+    collectivelly discuss with your group and publish the conclusions you

+    get. For us it is fundamental to try to build a metodology that makes possible the

+    dissemination of such discussions.

+    

+    [1] $neighborhood_mailing_list_address

+    

+    In solidarity,

+    $grupo Collective

diff --git a/docs/index.md b/docs/index.md
new file mode 100644
index 0000000..1804be2
--- /dev/null
+++ b/docs/index.md
@@ -0,0 +1,11 @@
+# Protocolos, Procederes e Templates Sociotécnicos
+
+**Blueprints, boilerplates, modelos, listas, templates! Prontos para usar e se organizar!**
+
+Este é um repositório de protocolos e templates de gestão pessoal e coletiva.
+
+Ele contém procedimentos, comportamentos e regras simples que, quando
+combinados, contribuem para a emergência (no sentido de emergir) de padrões
+complexos de organização coletiva.
+
+São pequenas máquinas que aumentam a fluidez e a organização de grupos sociais.
diff --git a/docs/pessoal/README.md b/docs/pessoal/README.md
new file mode 100644
index 0000000..339216c
--- /dev/null
+++ b/docs/pessoal/README.md
@@ -0,0 +1,9 @@
+# Protocolos pessoais
+
+Isso varia de pessoa para pessoa, mas em resumo a ideia aqui é a seguinte:
+experimente formas de se organizar e não se prenda a esquemas prontos e
+fechados; descarte os modelos que não funcionam, melhore o que estiver
+funcionando e adote novos até encontrar algo que sirva!
+
+Não se prenda a regras e esquemas quando eles não funcionem, o que vale
+inclusive para esta regra :P
diff --git a/docs/pessoal/basico.md b/docs/pessoal/basico.md
new file mode 100644
index 0000000..b27dd48
--- /dev/null
+++ b/docs/pessoal/basico.md
@@ -0,0 +1,93 @@
+# Necessidades básicas
+
+* Baseline vital.
+* A vida não é quadrada e isto é um modelo.
+* O dia é curto demais para que a lista seja completada.
+* Este é um roteiro para estar bem e fazer o bem todos os dias.
+* Evitando cansaço, ansiedade e mal uso de recursos.
+* Para ser [ético](/etica/pessoal).
+
+Metodologia
+-----------
+
+* Em ordem de realização e escala de tempo padrões.
+* Resolver prioridades em ordem de importância!
+* É mais importante atacar um pouco de cada prioridade do que focar
+  demasiadamente em apenas algumas delas.
+* É preciso estar bem para poder fazer o bem.
+* Apesar da ordem acima, as pessoas sempre vem antes. Se algum prezado/a
+  estiver precisando, a ordem das prioridades muda temporariamente.
+* Prioridades de mais importância devem ser realizadas em escala de tempo menor
+  (segundos, minutos, horas),
+  enquanto que prioridades mais baixas devem ser realizas em escala de tempo
+  maior (dias, semanas, meses, anos).
+
+Exemplo de rotina diária ideal
+------------------------------
+
+Especificidades na lista de tarefas/calendário.
+
+* Descanso     (8:00).
+* Higiene      (0:30).
+* Alimentação  (1:00).
+* Exercícios   (1:00).
+* Organização  (0:30).
+* Subsistência (8:30).
+* Existência   (5:00).
+
+Checklist de necessidades
+-------------------------
+
+0. Ambientais (0:00):
+    * Ar (CNTP).
+    * Chão.
+    * Iluminação (conforme ocasião).
+1. Circadianas (8:00):
+    * Sono.
+    * Descanso.
+2. Fisiológicas (1:00):
+    * Água.
+    * Alimentação, mastigando bastante.
+    * Purgas!
+    * Estética e higiene:
+        * Banho.
+        * Bucal.
+        * Roupa limpa.
+        * Limpeza do rosto.
+        * Pelos aparados.
+        * Unhas lixadas.
+        * Bronze.
+3. Comportamentais (1:00):
+    * Meditação.
+    * Exercícios físicos:
+        * Postura.
+        * Alongamento.
+        * Exercícios oculares.
+        * Ciclismo.
+        * Musculação.
+4. Estratégicas (0:30):
+    * Organização!
+    * Informações táticas (tempo, trânsito, emergências).
+5. Subsistência:
+    * Trabalho (6:00).
+    * Estudo (2:00).
+    * Casa (0:30).
+6. Existência:
+    * Social.
+    * Família.
+    * Cultura.
+    * Atividades apaixonantes.
+    * Auto-análise.
+
+Referências
+-----------
+
+* Balance: trouble to change context or change it too often.
+* Dose de estoicismo, ascetismo e frugalidade.
+* [Erich Fromm's eight basic needs](https://en.wikipedia.org/wiki/Erich_Fromm#Psychological_theory).
+* [Maslow's hierarchy of needs - Wikipedia, the free encyclopedia](https://en.wikipedia.org/wiki/Maslow%27s_hierarchy_of_needs).
+* [Seis chaves para ser feliz, segundo a Universidade de Harvard](http://brasil.elpais.com/brasil/2015/06/16/ciencia/1434480172_001091.html)
+* [A lição de Epicteto: aceitar os fatos é um passo essencial para a serenidade](http://www.diariodocentrodomundo.com.br/aceitar-os-fatos-e-um-passo-essencial-para-a-felicidade/).
+* [Zen to Done](http://lucasteixeira.com/ztd/).
+* [Comunidade Portuguesa de Ginástica Ocular](http://ginasticaocular.net/).
+* [Como Exercitar seus Olhos: 9 Passos (com Imagens)](http://pt.wikihow.com/Exercitar-seus-Olhos).
diff --git a/docs/pessoal/etica.md b/docs/pessoal/etica.md
new file mode 100644
index 0000000..73d7cf6
--- /dev/null
+++ b/docs/pessoal/etica.md
@@ -0,0 +1,124 @@
+# Ética Pessoal
+
+Motivação
+---------
+
+Código é lei? Código pode também ser ética. Se existem
+[protocolos](https://protocolos.fluxo.info) e [códigos de
+conduta](https://www.debian.org/vote/2014/vote_002) atuando no nível de grupos,
+é importante também haver procedimentos de auxílio para relações em nível
+individual.
+
+Pressupostos
+------------
+
+* Como cantou Daminhão Experiência, "O mundo foi bem feito / todo mundo tem
+  defeito".
+* Saber quando pisar dentro e fora do quadrado.
+* Noções básicas de postura social.
+
+Cuidados
+--------
+
+Não é a intenção deste breve guia:
+
+* Se transformar numa rocha inalterável e inflexível de como as relações
+  humanas devem ser.
+* Criar um protocolo que dificulte relações e deixe as pessoas apartadas.
+
+Este guia é mais uma referências de aspectos a serem pensados em relações com pessoas.
+
+Objetivos
+---------
+
+Grosso modo:
+
+* Calma.
+* Alegria.
+* Agilidade.
+* Sangue-bonismo.
+* Companheirismo.
+* Solidariedade, fraternidade, alteridade, autruísmo.
+
+Pisando no quadrado
+-------------------
+
+Este é um checklist de procedimentos e código de conduta. Você tem uma ideia de
+como se portar em cada um desses items?
+
+* Comunicação implícita e explícita:
+    * O que pode ser assumido de antemão.
+    * O que não pode ser assumido de antemão.
+* Separação entre aspectos da vida:
+    * Profissional, político e pessoal.
+    * Amizades e afinidades.
+    * Público e privado.
+* Lidando com conhecimento:
+    * Criando um canal e um encorajamento explícito para contatos, sugestões e críticas.
+    * Fomentando a formação e a inclusão de mais pessoas no ativismo técnico e na difusão do conhecimento.
+    * Tendo uma melhor comunicação com grupos e pessoas próximas.
+    * Definir melhor e de forma pública o funcionamento e a participação.
+* Relacionamento:
+    * [Alteridade](http://www.revolucoes.org.br/v1/conferencia/alteridade).
+    * Generosidade.
+    * Alimentação.
+    * Liberdade de associação e de não-associação, tanto para propósitos gerais quanto específicos.
+    * Responsabilidade e zelo.
+    * Buscar facilitar as relações e situações, ao invés de dificultar a fluidez dos relacionamentos.
+    * Comportamentos evitados: trolling, bullying, spamming, etc.
+    * Gentileza gera gentileza.
+    * Proceder: humildade, respeito, responsa.
+    * Assiduidade, pontualidade e atrasos.
+    * Política de assinatura de chaves.
+    * Participação em debates e discussões.
+    * Favores e reciprocidade.
+    * Fidelidade (compromisso) e lealdade (espontâneo).
+    * Sobre a confiança (contextual e total) e a alteridade.
+    * Pronomes de tratamento e linguagem inclusiva.
+    * Discussão, facilitação, opiniões (e mudança de opiniões), respeito a rodadas e falas:
+        * Discussão de temas em geral.
+        * Discussão periódica da relação.
+    * Comunicação mediada (virtual):
+        * [Netiqueta](https://tools.ietf.org/html/rfc1855).
+        * Lei de [Postel](https://en.wikipedia.org/wiki/Jon_Postel): "Be
+          liberal in what you accept, and conservative in what you send".
+        * Como lidar com ausência de resposta.
+        * Como a ausência de resposta é interpretada.
+        * Assuntos públicos, semi-públicos e privados: como lidar com mensagens
+          privadas evitando concentração de informação e canais laterais que
+          possam prejudicar organizações horizontais.
+        * Emoticons, cordialidade e polidez.
+        * Quando assinar comunicação, quando não assinar, modo anônimo.
+    * Comunicação ao vivo:
+        * Pronomes.
+        * Cumprimentos (aperto de mão, beijo, saudação).
+* Sistematizando formas de lidar com situações diversas:
+    * [Defence mechanisms](https://en.wikipedia.org/wiki/Defence_mechanisms).
+    * Círculo Restaurativo.
+    * Comunicação não-violenta.
+    * Linguagem inclusiva.
+    * Situações críticas: como não reproduzir instituições burguesas (tribunal,
+      prisão, manicômio) ou arcaicas (ostracismo, linchamento, etc)?
+    * Facilitação e resolução de conflitos.
+        * [Conflito e Consenso](https://docs.indymedia.org/Local/CmiBrasilConflitoConsenso).
+        * [Conflict resolution](https://simple.wikipedia.org/wiki/Conflict_resolution).
+    * Referências
+        * [General Resolution: code of conduct](https://www.debian.org/vote/2014/vote_002), [Anti-harassment team - Debian](https://wiki.debian.org/AntiHarassment).
+        * [Código de Conduta da SquatConf](https://github.com/squatconf/organisation/blob/master/code_of_conduct.md#squatconf-code-of-conduct).
+        * [Código de Conduta do Mediawiki](https://www.mediawiki.org/wiki/Code_of_Conduct).
+        * [Código de Conduta do Projeto Tor](https://gitweb.torproject.org/community/policies.git/tree/code_of_conduct.txt).
+        * [Contributor Covenant: A Code of Conduct for Open Source Projects](http://contributor-covenant.org/).
+        * [Universal Declaration of Human Rights | United Nations](http://www.un.org/en/universal-declaration-human-rights/index.html).
+
+Exemplo
+-------
+
+Subconjunto de baixa complexidade necessária:
+
+0. Saúde é o que interessa!
+
+1. Não importa o que aconteça, duas coisas precisam ser constantes na vida:
+   estudar e se exercitar (circuito do aprendizado e da experiência).
+
+2. De resto, não leve nada a sério mas sempre se engaje! Que venha a farra, a
+   alegria e a solidariedade/generosidade!
diff --git a/docs/pessoal/organizacao.md b/docs/pessoal/organizacao.md
new file mode 100644
index 0000000..ee04bc1
--- /dev/null
+++ b/docs/pessoal/organizacao.md
@@ -0,0 +1,254 @@
+# Organização
+
+Se a [modelagem de ameaças](https://plano.autodefesa.org)
+é a mãe da segurança, organização é a mãe de tudo!
+
+Uma fala sobre organização (processos, metodologias, etc) para coletivos
+técnicos radicais. Apenas aspectos organizacionais entre pessoas será abordado,
+como tomada de decisões, responsabilização, realização, etc, deixando aspectos
+técnicos para outras falas.
+
+## Introdução
+
+    Se você está panguando, o problema é seu.
+    Se você quer deixar de panguar, o problema é nosso.
+
+    --- Atarefados Anônimos
+
+* Houve uma época em que acreditava que a computação ajudaria as pessoas a se
+  organizarem.
+
+* Mas hoje fico impressionado no nível de desorganização de grupos e pessoas.
+
+* Em parte, porque a capacidade de se organizar foi transferida para as
+  máquinas corporativas que escolhem qual e que informação as interagirão.
+
+* Ao mesmo tempo, a desorganização é a forma mais sutil de opressão, já que
+  dificilmente as pessoas enxergam a desorganização como causada por fatores
+  externos: "estou desorganizado/a" é uma fase comum que atribui a culpa às
+  pessoas.
+
+* Mas sim, a organização é uma tarefa nossa. Avante!
+
+## Formas de organizar as atividades
+
+Um exemplo:
+
+* Dividir as atividades em projetos/grupos/organizações:
+  * Cada uma delas possui uma pasta no meu computador pessoal.
+  * Cada nível de uma estrutura de pasta possui itens de uma mesma categoria.
+* Cada um desses projetos possui seu próprio sistema de gestão de tarefas (de
+  um simples arquivo TODO até um sistema de tickets).
+* Possuo um calendário com agendador de tarefas integrados:
+  * Procuro deixá-lo o mais vazio possível em termos de compromissos e tarefas.
+  * Cada projeto pode ter seu arquivo de calendário / categoria próprios.
+  * A mesma paridade pode ser feita com pastas de email.
+  * O calendário possui um lembrete básico para que eu dê uma olhada nas pendências
+    de todos os projetos.
+  * Deixo no calendário apenas as tarefas mais importantes e as menos importantes seguem
+    nas listas de tarefas de cada projeto.
+  * Projetos com poucas tarefas e eventos ou que façam parte de uma mesma categoria podem
+    ser agrupados nas pastas de email e de calendário.
+* Possuo coletores auxiliares de lembretes e ideias, em geral cadernos de notas ou papéis
+  na carteira, mas estes devem ser "sincronizados" assim que possível, isto é, seu conteúdo
+  transcrito para os projetos correspondentes.
+* Tenho mania de anotação. Lembrei de algo, tento anotar na hora e no local certo, o que ocorreu
+  inclusive com esta nota ;)
+
+Alguns projetos podem ser considerados universais, isto é, serem adotados por
+pessoas indiferentes de suas atividades principais. São eles:
+
+* [Templates](https://git.fluxo.info/templates.git): pode ser entendido como um
+  metaprojeto, agregando receitas de como se começar um novo projeto.
+* Logística: é um projeto que gerencia o estoque.
+
+## Pragmática
+
+Trabalho reprodutivo, atividades básicas, baseline, constância:
+
+* Homeostase.
+* Logística.
+* Inventário.
+* Auditoria.
+* Rotina.
+* Regulação.
+* Regularidade.
+* Prática.
+* Pragmatismo.
+* Prosa.
+
+Técnica, simplexidade: garante que o baseline tenha carga mínima; linha de base
+operacional.
+
+## Formas de organizar o tempo
+
+Percepções:
+
+* Percebo que existe uma inércia mental, digamos um período até que entremos no
+  contexto de uma dada atividade.
+
+* Analogamente, existe um período para aquisição de concentração.
+
+Assim:
+
+* Tento organizar as atividades em slots com período suficiente para entrar no
+  contexto e adquirir concentração.
+
+* Tento minimizar as saídas a fornecedores.
+
+## A mecânica da agenda
+
+* Coletores, agendas e listas de tarefas são buffers de armazenamento de desejos ou intenções
+  de realização. São escalonadores de atividades.
+* Arquivos são listas de atividades que nunca ou já ocorreram mas que não compõe a lista atual
+  de intenções de realização.
+* ChangeLogs são locais de descrição de tarefas que ocorreram.
+
+A vida de um evento:
+
+* Eventos singulares: ocorrem uma vez e são automaticamente são arquivados.
+* Eventos recorrente ou multi-etapas: após a iteração atual devem ter sua
+  próxima ocorrência agendada.
+
+Exemplos:
+
+* Eventos singulares: encontrar alguém numa data e local específicos.
+* Eventos recorrentes: checagem de inventário, auditoria em sistemas.
+* Eventos multi-etapas: tirar um documento.
+
+## Coleções de tarefas e listas contextuais
+
+Vamos começar fazendo prática e depois a teoria!
+
+* Coletores e gestores pessoais
+  * Caderno
+  * Post-it: que bagunça!
+  * Agenda impressa e digital
+  * Email e a caixa de saída
+
+* Coletores e gestores coletivos
+  * Lista de discussão: as tarefas se perdem!
+  * Sistemas de tickets
+
+* Relação entre caderno, email, sistema
+
+* Acumulação: guardar o trabalho organizativo e material feito hoje para usá-lo no futuro.
+
+## Topologia
+
+* Desenvolvimento e Operação
+* Upstream e downstream: mover a solução para upstream
+* Ter mais informes do que questões da debater: divisões em Grupos de Trabalho
+  (GTs) ou comitês: desacoplamento.
+
+## Urgência e emergência
+
+* Urgências e emergências devem estar previstas na medida do possível.
+
+## Fluxos
+
+### A espiral de anéis
+
+Os dois momentos: homeostase e pesquisa:
+
+    (técnica)      (arte)
+    (automático)   (manual)
+    (produção)     (desenvolvimento)
+    homeostase ->- pesquisa
+       \             /  \
+        `------<----´    `-----> arquivamento
+        (incorporação)    `
+                            `--> descarte
+
+A produção pode consistir tanto de automatismo pessoais (corporificados)
+quanto na automação de sistemas para realização de tarefas constantes.
+
+### Método espirálico
+
+         (tática)               (estratégia)                     (logística)
+    |-- brainstorm --|--------- planejamento ----------------|-- realização --|
+
+
+    atividades imediatas:
+    ----------------------------->---------------------------------------------
+
+    atividades mediadas:
+
+                      .-->- descarte      --------<-------------
+                     /                  .´                      `.
+                    .--->- arquivamento -->--.       .----<-------.
+                   /                          `.    /              \
+     coletores ZTD -->-- agenda contextual (loop principal) ->- execução
+           \       \                            .                  /
+            \       `->- TODOs contextuais ->--´                  /
+             \                                                   /
+              ------------------<-------------------------------´
+
+## Distribuição de eventos
+
+* Quebrar tarefas grandes em tarefas menores.
+* Empirismo para determinar quantidade de tarefas para cada dia.
+* Recomendações ZTD, GTD, Pomodoro, etc.
+* A rotina não pode ser tornar uma camisa de força para a pessoa; a ideia é
+  justamente o contrário: que ela otimize o tempo o bem viver.
+
+### Documentação
+
+Cada processo pode ser composto por documentação pública ou privada:
+
+    documentação --->---- separação de especificidades -->--- documentação pública
+    privada               e dados sensíveis
+
+## Níveis
+
+* Pessoal: usando técnicas como:
+    * [Zen To Done (ZTD)][].
+    * [Pomodoro][].
+    * [Bullet Journal (BuJo)][].
+    * [Ultimate Study Method (USM)][].
+* [Coletivo](/coletivo)
+* Às vezes ajudamos mais os grupos se já estamos organizados/as, mas em muitas
+  situações é a atividade coletiva que nos organiza.
+
+[Zen To Done (ZTD)]: https://zenhabits.net/zen-to-done-ztd-the-ultimate-simple-productivity-system/
+[Pomodoro]: https://francescocirillo.com/pages/pomodoro-technique
+[Bullet Journal (BuJo)]: https://bulletjournal.com/
+[Ultimate Study Method (USM)]: http://www.ultimatestudymethod.com/
+
+## Problemas
+
+* Quais são os problemas a serem resolvidos?
+* Problemas que queremos/iremos resolver e aqueles que não resolveremos.
+* Fazer o que queremos X fazer o que é necessário.
+
+## Prazos
+
+* Temporalidade.
+* Otimismo pode prejudicar a estimativa de prazos.
+* Metas de pequeno, médio e longo prazo.
+* Lembrar das coisas.
+
+## Zeladoria rotativa
+
+Será que funciona?
+
+## Os frutos da organização
+
+* A quem cabe fruir o valor da organização?
+* Se tornar eficiente onde?
+* Ativistas como trabalhadores/as nos próprios movimentos.
+
+## Comunicação
+
+    Cohn's Law:
+            The more time you spend in reporting on what you are doing, the less
+            time you have to do anything.  Stability is achieved when you spend
+            all your time reporting on the nothing you are doing.
+
+Dicas básicas:
+
+* Comunicação direta, porém não ríspida.
+* Diferenças de contexto.
+* Lembrar que possivelmente os canais de comunicação serão também canais
+  históricos, ou seja, ajudarão pessoas no futuro a entender os grupos. Da
+  mesma forma, existe a preocupação com segurança.
diff --git a/docs/pessoal/saude.md b/docs/pessoal/saude.md
new file mode 100644
index 0000000..4117b96
--- /dev/null
+++ b/docs/pessoal/saude.md
@@ -0,0 +1,7 @@
+# Ficha médica / Medical record
+
+    Nome / Name                : José Bedeu
+    Tipo sanguíneo / Blood type: A+
+    Endereço / address         : Rua dos Parnasianos, 35
+                                 São Longuinho - RJ - 30353-129 - Brasil
+    Telefone / phone           : +55 12 0000 0000
diff --git a/docs/referencias.md b/docs/referencias.md
new file mode 100644
index 0000000..307e6ef
--- /dev/null
+++ b/docs/referencias.md
@@ -0,0 +1,3 @@
+# Referências
+
+* Usando RFCs: [How to Stop Endless Discussions](https://candost.blog/how-to-stop-endless-discussions/).
diff --git a/docs/site.css b/docs/site.css
new file mode 100644
index 0000000..6f90e2b
--- /dev/null
+++ b/docs/site.css
@@ -0,0 +1,15 @@
+.wy-menu-vertical li a {
+  color: #fff!important;
+}
+
+.wy-menu-vertical li.current a {
+  color: #000!important;
+}
+
+.wy-nav-content {
+  max-width: 100%;
+}
+
+.wy-side-nav-search {
+  background-color: inherit;
+}
diff --git a/docs/sobre.md b/docs/sobre.md
new file mode 100644
index 0000000..e86584b
--- /dev/null
+++ b/docs/sobre.md
@@ -0,0 +1,4 @@
+# Sobre
+
+* [Repositório](https://git.fluxo.info/templates).
+* [Licença](LICENSE).
diff --git a/docs/social/README.md b/docs/social/README.md
new file mode 100644
index 0000000..1cb7b4a
--- /dev/null
+++ b/docs/social/README.md
@@ -0,0 +1,5 @@
+# Protocolos sociais
+
+## Referências
+
+* [A guide to distributed teams – Increment: Teams](https://increment.com/teams/a-guide-to-distributed-teams/)
diff --git a/docs/social/coletivo/README.md b/docs/social/coletivo/README.md
new file mode 100644
index 0000000..05980c7
--- /dev/null
+++ b/docs/social/coletivo/README.md
@@ -0,0 +1 @@
+# Coletivo
diff --git a/docs/social/coletivo/basico.md b/docs/social/coletivo/basico.md
new file mode 100644
index 0000000..f10a998
--- /dev/null
+++ b/docs/social/coletivo/basico.md
@@ -0,0 +1,17 @@
+# Checklist Básico
+
+O que um grupo precisa em geral para funcionar:
+
+* Plataforma de comunicação.
+* Sistema de acompanhamento de tarefas.
+* [Protocolos](https://protocolos.fluxo.info) de operação!
+
+Fluxo de trabalho:
+
+* Reuniões periódicas de trabalho coletivo: pesquisa, desenvolvimento, implementação, manutenção e auditoria.
+
+Opcional:
+
+* Site e canais de contato públicos.
+* Licença de distribuição de conteúdo.
+* Termos de serviço e política de privacidade.
diff --git a/docs/social/coletivo/coletivo.md b/docs/social/coletivo/coletivo.md
new file mode 100644
index 0000000..d3b8219
--- /dev/null
+++ b/docs/social/coletivo/coletivo.md
@@ -0,0 +1,99 @@
+# Protocolo de Ação do Coletivo
+
+ * Versão: 1.0.
+ * Licença: LIMICS[1].
+
+O Coletivo `$coletivo` adota a versão 0.1 do "Protocolo de Ação Coletiva"[2],
+de modo que se tome por "Coletivo `$coletivo`" toda ocorrência da palavra
+"Coletivo" no referido texto.
+
+Instâncias de Comunicação
+-------------------------
+
+Conforme a atual configuração tecnológica do Coletivo $coletivo, as principais
+instâncias de comunicação utilizadas são:
+
+* Wiki/sistema de tickets fechado: `https://admin.$dominio`.
+* Lista de discussão: `$lista_de_discussao`.
+* Demais meios de comunicação que satisfaçam requisitos de privacidade e segurança.
+
+Processos e tickets
+-------------------
+
+A manifestação que os registros de processos assumem no Coletivo `$coletivo`
+são chamados de tickets ou requisições. Todos os processos devem ser tickets.
+Processos informais não precisam necessariamente ser tickets antes da sua
+realização, mas para que posteriormente possam ser considerados como processos
+precisam virar tickets (isto é, precisam de um mínimo de documentação).
+
+Formalidade e informalidade de instâncias
+-----------------------------------------
+
+Com relação à formalidade e informalidade das instãncias de comunicação, temos que:
+
+* Todas as instâncias de comunicação são informais ''a priori'' (isto é, se
+  nada mais for dito a respeito da forma de cada uma delas).
+* As instâncias formalizadoras (isto é, as instâncias onde deve ser informada
+  da proposição e aprovação de um processo para que o mesmo tenha validade
+  formal) são o sistema de tickets e a lista de discussão.
+
+Recomendação sobre jardinagem de discussões
+-------------------------------------------
+
+Levando em consideração que
+
+* É interessante manter um fluxo de emails baixo com mensagens pequenas para
+  que a lista de discussão possa ser bem usada especialmente em urgências.
+* Wiki e sistema de tickets são muito úteis para lidar com grandes quantidades
+  de informação, apesar de não serem muito bons para a obtenção de feedback
+  rápido.
+* No caso de pendências e tarefas, o sistema de tickets é mais confortável para
+  o acompanhamento de atividades.
+
+Recomenda-se que
+
+* Se possível, as discussões sejam originadas nos meios que lhes forem mais
+  propícios (alguma emergências se iniciam melhor com o envio de um email, onde
+  obtém melhor resposta).
+* Caso um meio se torne inadequado para a manutenção da discussão, que a mesma
+  seja transferida para um meio mais adequado mas que tal transferência seja
+  acompanhada pelo referenciamento mútuo em ambas as instâncias (na instância
+  onde ela deixar de ocorrer envia-se uma mensagem indicando para onde a
+  discussão está sendo encaminhada e nesta última se adiciona uma indicação
+  sobre onde a discussão veio.
+* Discussões que adquiram vulto sejam transformadas em processos informais (com
+  a criação de um ticket com respectivo link, se aplicável, para o local onde a
+  discussão está sendo realizada).
+
+Procedimento para Processos Formais
+-----------------------------------
+
+Além de obedecer ao fluxograma de processos formais detalhado no texto
+"Protocolo de Ação Coletiva", a proposição e a decisão de propostas formais
+devem ser realizadas da seguinte forma para serem válidas:
+
+* Para enviar uma proposta formal, primeiramente crie um ticket.
+* Em seguida, envie um email para a lista de discussão informando da proposta e
+  incluindo, pelo menos, o link do ticket.
+* A discussão e alteração da proposta pode ser feita apenas pelo ticket, pela
+  lista de discussão ou mesmo em instâncias informais, mas recomenda-se que se
+  utilize o ticket como agregador do maior número possível de informações
+  discutidas a respeito da proposta.
+* Discussões realizadas em instâncias informais não tem valor formal se não
+  forem documentadas e apresentadas como tal na lista de discussão, no ticket
+  ou eventual página wiki, observando a recomendação sobre jardinagem de
+  discussões.
+* Ao passar o prazo de decisão da proposta, é necessário  enviar um email de
+  comunicação à lista de discussão para que a decisão seja formalizada.
+
+Conforme o processo formal em questão for passando pelas etapas formais, o
+estado do ticket deve ser alterado pelas pessoas que se interessarem por
+fazê-lo. Se necessário, a proposta também pode ter ao menos uma página no wiki
+fechado, sendo possível usar o wiki para acompanhar diferentes versões de uma
+proposta, por exemplo.
+
+Referências
+-----------
+
+ * [1] [Licença de Manipulação de Informações do Coletivo $coletivo](/organizacao/comunicacao/license).
+ * [2] [Protocolo de Ação Coletiva](/organizacao/coletiva.
diff --git a/docs/social/coletivo/comunicacao.md b/docs/social/coletivo/comunicacao.md
new file mode 100644
index 0000000..1851790
--- /dev/null
+++ b/docs/social/coletivo/comunicacao.md
@@ -0,0 +1 @@
+# Comunicação
diff --git a/docs/social/coletivo/comunicacao/acl.md b/docs/social/coletivo/comunicacao/acl.md
new file mode 100644
index 0000000..e4a3490
--- /dev/null
+++ b/docs/social/coletivo/comunicacao/acl.md
@@ -0,0 +1,60 @@
+# Lista de acesso à participação
+
+O presente processo estabelece uma série de camdas de acesso e participação
+sobre fluxos informacionais realizadas em instâncias de comunicação mantidas
+pelo Coletivo com o objetivo de fortalecer relações de abertura e fechamento do
+Coletivo que garantam o máximo de modos de que pessoas de fora possam colaboram
+conosco (outsourcing) ao mesmo tempo em que garanta a proteção de informações
+sensíveis.
+
+Para isso, este processo se inspira no princípio de que quanto mais forem
+públicas as informações, atividades e participações desempenhadas pelo
+Coletivo, não só as chances de sustentabilidade aumentam como também as
+relações com o campo social se fortalecem. Por outro lado, não se pode ignorar
+a vigilância e o controle de massa que ameaçam a integridade e as atividades
+dos grupos e movimentos sociais.
+
+Uma forma de segmentar as atividades levando em conta a tensão entre a
+tendência de tornar tudo público com o cuidado de manter a integridade das
+atividades é dividi-las em grupos referentes à sua possibilidade de
+publicização e participação:
+
+1. Quais delas podem ser externalizadas pelo Coletivo, isto é, tornadas públicas com
+  a. Feedback de qualquer pessoa ou grupo.
+  b. Feedback apenas de pessoas conhecidas.
+  c. Feedback apenas de pessoas de dentro do Coletivo.
+2. Quais delas não podem ser tornadas públicas mas que podem ser compartilhadas
+   com pessoas e grupos próximos com
+  a. Feedback apenas de pessoas conhecidas.
+  b. Feedback apenas de pessoas de dentro do Coletivo.
+3. Quais delas precisam ser mantidas em sigilo dentro do Coletivo.
+
+Por feedback se entede por poder de leitura e escrita direta, sem necessidade
+de mediação do Coletivo. Obviamente que em atividades públicas podem ter
+contribuições de terceiros/as, mas tal contribuição pode ser direta (com
+feedback ativado) ou indireta, isto é, mediada pelo Coletivo.
+
+Assim, o Coletivo define a seguinte Lista de Camadas de Acesso à Informação ou
+Lista de Controle de Acesso (LCA ou ACL):
+
+1. Atividades públicas
+  a. Feedback de qualquer pessoa ou grupo.
+  b. Feedback apenas de pessoas conhecidas.
+  c. Feedback apenas de pessoas de dentro do Coletivo.
+2. Atividades vizinhantes
+  a. Feedback apenas de pessoas conhecidas e confiáveis.
+  b. Feedback apenas de pessoas de dentro do Coletivo.
+3. Atividades privadas: nossos processos internos.
+
+Em outras palavras, o Coletivo adota um modelo de três camadas que funciona
+como uma lista de controle de acesso (ACL) para diversas atividades que possam
+ser compartimentalizadas:
+
+* É uma lista de acesso definida por instância de comunicação, dizendo quem e
+  como se dá a participação numa dada instância.
+* Cada instância ocupa apenas um nível nessa lista. Como exemplo, uma dada
+  instância pode ter ACL ''1.c'', ou seja, ser uma instância de realização de
+  atividade pública mas apenas com feedback de pessoas do Coletivo.
+* Cabe aos processos que definem cada instância de comunicação atribuir um nível de acesso.
+
+Recomenda-se que as atividades sejam bem compartimentalizadas (no caso de utilizarem mais de uma instância) para que se consiga maximizar a publicização de atividades e proteger apenas os pontos sensíveis.
diff --git a/docs/social/coletivo/comunicacao/archive.md b/docs/social/coletivo/comunicacao/archive.md
new file mode 100644
index 0000000..2daa7f9
--- /dev/null
+++ b/docs/social/coletivo/comunicacao/archive.md
@@ -0,0 +1,24 @@
+# Armazenamento de documentos
+
+O armazenamento de documentos consiste no depósito organizado e seguro de
+documentos físicos (isto é, impressos) do Coletivo, consistindo nas seguintes
+tarefas:
+
+1. Manter os documentos do Coletivo (notas fiscas, contratos, acordos, etc)
+   armazenados em local protegido (de umidade, desgaste, mofo, incêndio, roubo,
+   etc) e observando a política de segurança da informação do Coletivo.
+
+2. Fornecer os documentos (ou cópias dos mesmos) ao Coletivo conforme
+   solicitação e zelando para que os mesmos retornem ao depósito ou se mantenham
+   em condições compatíveis de armazenamento. Os documentos devem ser fornecidos
+   num prazo de até '''uma semana''' (incluindo finais de semana e feriados) após
+   a solicitação.
+
+3. Manter cópias digitais (escaneadas ou fotografadas) dos documentos em
+   instância de comunicação fechada do Coletivo.
+
+Responsabilização
+-----------------
+
+Cada pessoa responsabilizada pelo armazenamento de documentos é denominada de
+''fiel depositária dos documentos do Coletivo''. 
diff --git a/docs/social/coletivo/comunicacao/backup.md b/docs/social/coletivo/comunicacao/backup.md
new file mode 100644
index 0000000..89863e8
--- /dev/null
+++ b/docs/social/coletivo/comunicacao/backup.md
@@ -0,0 +1,31 @@
+# Instâncias de comunicação de backup
+
+Este processo estabelece procedimentos para comunicação de backup para
+
+* Lista de email.
+* Bate-papo.
+
+Responsabilização
+-----------------
+
+O Grupo de Trabalho responsável por este processo deve manter uma lista de
+email e uma sala de bate-papo de [ACL](/coletivo/comunicacao/acl.html)
+nível 3 para participação -- isto é, canal de acesso apenas para pessoas
+do Coletivo -- para serem utilizados quando alguma das instâncias padrões
+estiverem com problemas.
+
+Os critérios de funcionamento dessas instâncias de backup são os mesmos para
+as instãncias usuais equivalentes.
+
+Recomenda-se também que, se possível, as pessoas do Coletivo possuam emails
+adicionais que satisfação a
+[Politica Política de segurança da informação](/coletivo/comunicacao/infosec.html)
+e que possam ser utilizados como backup.
+
+Dependências
+------------
+
+A realização deste processo depende da realização dos seguintes processos:
+
+* [Política de segurança da informação](/coletivo/comunicacao/infosec.html).
+* [ACL Lista de acesso à participação (ACL)](/coletivo/comunicacao/acl.html).
diff --git a/docs/social/coletivo/comunicacao/chat.md b/docs/social/coletivo/comunicacao/chat.md
new file mode 100644
index 0000000..7a96ef2
--- /dev/null
+++ b/docs/social/coletivo/comunicacao/chat.md
@@ -0,0 +1,51 @@
+# Bate-papo
+
+Este processo estabelece as linhas gerais para a administração dos sistemas de
+bate-papo utilizados pelo Coletivo. Tais sistemas permitem a comunicação
+praticamente em tempo real. Se utilizadas com critérios de segurança e
+privacidade, as salas de bate-papo podem desempenhar um ótimo papel para a
+comunicação rápida no Coletivo.
+
+Canais
+------
+
+Os seguintes canais são definidos como instâncias de comunicação informais do Coletivo:
+
+* `#$canal_aberto`: [ACL](/coletivo/comunicacao/acl.html) nível 1.a ou superior para
+  participação, ou seja, um canal de acesso público onde não se deve discutir
+  ou divulgar assuntos internos do Coletivo.
+
+* `#$canal_fechado`: [ACL](/coletivo/comunicacao/acl.html) nível 3 para participação,
+  isto é, canal de acesso apenas para pessoas do Coletivo, sem restrição de assuntos.
+
+* temporários, para o caso de pessoas do Coletivo precisarem conversar com terceiros/as
+  de modo privativo, com [ACL](/coletivo/comunicacao/acl.html) nível 2.a ou superior.
+
+Modos de configuração
+---------------------
+
+Os seguintes modos de configuração são requeridos para canais privativos:
+
+* Entrada restrita a membros do Coletivo.
+* Sem exibição na listagem de canais do servidor (no caso do IRC, modo +s e/ou +p).
+* Acesso via SSL ou outro métodos de criptografia assimétrica (IRC, SILC, etc).
+
+Responsabilização
+-----------------
+
+Cabe ao Grupo de Trabalho formado pelas pessoas responsáveis pelo presente
+processo manter o registro, a manutenção, a operação e a documentação
+relacionada aos canais de bate-papo do Coletivo, levando em consideração:
+
+* [Os critérios de segurança e privacidade](/coletivo/comunicacao/infosec.html).
+* O nível de acesso de cada um dos canais, não permitindo pessoas que não
+  tenham o devido acesso a participarem de determinados canais.
+* Que muito de ausência dos/as operadores do canal pode levar à perda do seu registro.
+
+Dependências
+------------
+
+A realização deste processo depende da realização dos seguintes processos:
+
+* [Política de segurança da informação](/coletivo/comunicacao/infosec.html).
+* [Lista de acesso à participação (ACL)](/coletivo/comunicacao/acl.html).
diff --git a/docs/social/coletivo/comunicacao/infosec.md b/docs/social/coletivo/comunicacao/infosec.md
new file mode 100644
index 0000000..ce06d8e
--- /dev/null
+++ b/docs/social/coletivo/comunicacao/infosec.md
@@ -0,0 +1,100 @@
+# Política de segurança da informação
+
+O presente processo estabelece uma série de definições e recomendações
+relacionadas à segurança da informação circulada por instâncias mantidas pelo
+Coletivo.
+
+Política de senhas e chaves
+---------------------------
+
+Recomenda-se que as pessoas participantes de instâncias de informação mantidas
+pelo Coletivo assumam uma política de senhas como a seguinte:
+
+1. Não utilizar a mesma senha para sistemas sensíveis.
+2. Não utilizar senhas frágeis.
+
+Recomenda-se ainda, que sejam utilizadas aplicações como as seguintes:
+
+* [http://web.monkeysphere.info Monkeysphere] para auxiliar na autenticação de sistemas remotos.
+* [http://point-at-infinity.org/ssss ssss], para o compartilhamento de senhas em sistemas sensíveis.
+* Programas como o [http://www.adel.nursat.kz/apg apg] para a geração de senhas fortes.
+* Programas como o [http://oss.codepoet.no/revelation/wiki/Home Revelation] ou
+  o [http://kedpm.sourceforge.net kedpm] para o armazenamento seguro de senhas.
+
+Emails suficientemente seguros
+------------------------------
+
+Define-se como uma conta de email suficientemente segura aquela que utiliza:
+
+1. [http://en.wikipedia.org/wiki/STARTTLS STARTTLS] nas transmissões para
+   outras contas de email suficientemente seguros.
+2. É acessada apenas através de conexão SSL, seja HTTPS, IMAPS, POPS ou SMTPS.
+3. Criptografia de disco para armazenamento de mensagens no servidor.
+
+A participação em instâncias de comunicação mantidas pelo Coletivo e que não
+são totalmente públicas requerem o uso de contas de email suficientemente
+seguros.
+
+Criptografia
+------------
+
+Recomenda-se que as pessoas participantes de instâncias de informação mantidas
+pelo Coletivo:
+
+1. Armazenem informações internas relacionadas ao mesmo apenas em volumes
+   criptografados. Se não tiverem condições de assim procederem com suas máquinas
+   pessoais, recomenda-se que armazenem tais informações apenas em instâncias de
+   comunicação do Coletivo que possuam transmissão e armazenamento criptografado
+   de dados.
+
+2. Utilizem o sistema OpenPGP de criptografia assimétrica para proteção,
+   integridade e verificação de procedência de dados sensíveis.
+
+3. Utilizem canais de comunicação criptografados sempre que possível e que não
+   utilizem canais não-criptografados para tratar remotamente de questões internas
+   ao Coletivo.
+
+Lista de recomendações e práticas sugeridas
+-------------------------------------------
+
+Por se tratar de uma questão complexa e sensível mas por contar com
+documentação dispersa, listas adicionais de recomendações e práticas sugeridas
+sobre segurança da informação podem ser anexadas ao presente processo.
+
+Eventualmente, recomenda-se que este processo seja atualizado para contemplar
+progressos neste campo.
+
+Criação de contas
+-----------------
+
+A criação de contas em sistemas mantidos pelo Coletivo deve obedecer o seguinte procedimento:
+
+1. Priorizar a escolha de senha pelo titular da conta sem que outra pessoa
+   precise conhecê-la, desde que possível.
+2. Enviar para o/a usuário:
+   a. Pedido de mudança de senha logo que consiga se autenticar nos sistemas em
+      questão, caso isso seja possível.
+   b. Fornecer fingerprints de chaves de criptografia utilizadas para o acesso da conta.
+   c. Se possível, as informações da conta utilizando criptografia e para uma
+      conta de email suficientemente seguro do/a usuário.
+   d. Uma cópia da lista de recomendações e boas práticas.
+
+Persistência de dados
+---------------------
+
+Informações armazenados num determinado nível de acesso ou segurança (exemplo,
+disco criptografado) devem, por padrão, permanecer nesse mesmo nível ou serem
+transferidas para um nível mais seguro, exceto quando constitui informação
+desclassificada e permitida para descer de nível.
+
+Telefone e outros meios de comunicação privada que não possuam segurança
+suficiente do conteúdo, da origem e do destinatário da informação devem ser
+considerados, para todos os efeitos, como meios de comunicação públicos e
+portanto não serem utilizados para veicular informações sensíveis.
+
+Dependências
+------------
+
+A realização deste processo depende da realização dos seguintes processos:
+
+* [ACL Lista de acesso à participação (ACL)](/organizacao/comunicacao/acl.html).
diff --git a/docs/social/coletivo/comunicacao/license.md b/docs/social/coletivo/comunicacao/license.md
new file mode 100644
index 0000000..a008e35
--- /dev/null
+++ b/docs/social/coletivo/comunicacao/license.md
@@ -0,0 +1,150 @@
+# Conjunto de Licenciamento Livre
+
+Originalmente em [Encontro: Cultura Livre e
+Capitalismo](https://encontro.fluxo.info/Principal/ConjuntoDeLicenciamentoLivre).
+
+## Seções das licenças
+
+Para contemplar inúmeros pontos de vista dos grupos e pessoas participantes
+deste espaço, a proposta de licença envolve as seguintes partes:
+
+1. Liberdades atribuídas ao/à licenciado/a
+2. Obrigações do/a licenciado
+3. Liberdades e obrigações atribuídas ao/à licenciante 
+
+## Liberdades atribuídas ao/à licenciado/a
+
+Atribui ao detentor/a da informação as seguintes liberdades:
+
+1. A liberdade de armazenar a informação.
+2. A liberdade de manipular a informação.
+3. A liberdade de distribuir a informação, modificada ou não. 
+
+## Obrigações do/a licenciado
+
+### Restrição obrigatória: "viralidade"
+
+Desde que esta licença acompanhe a informação.
+Restrição ética ou mercantil
+
+### As seguintes opções mutuamente exclusivas são possíveis para a montagem de uma licença:
+
+1. Contanto que o detentor da informação pactue com os princípios das mídias e grupos livres.
+2. Restrição comercial: Desde que para fins não-comerciais.
+3. Restrição de lucro: Desde que para fins não-lucrativos. 
+
+### Restrição de autoria e fonte
+
+As seguintes opções não-exclusivas são possíveis para a montagem de uma licença:
+
+1. Desde que o autor seja citado.
+2. Desde que a fonte seja citada. 
+
+### Restrição de distribuição
+
+Essa restrição obriga que a pessoa que utilizar a informação a:
+
+1. Caso ocorra uma modificação, distribuir a informação modificada.
+2. Ou, eventualmente, distribuir a informação para qualquer um dos usos que ela estiver sujeita. 
+
+Opcionalmente, uma das seguintes restrições de notificação podem ser utilizadas:
+
+1. Caso o conteúdo seja distribuído, a fonte deve ser notificada antecipadamente.
+2. Ou, caso o conteúdo seja distribuído, a fonte deve ser notificada
+   antecipadamente caso existam modificações. 
+
+## Liberdades e obrigações atribuídas ao/à licenciante
+
+As seguintes opções não-exclusivas são possíveis para a montagem de uma licença
+e apenas fazem sentido se a informação preserva autoria ou fonte:
+
+1. O/a autor/a pode a qualquer momento revogar o licenciamento da informação
+   para uma determinada pessoa ou entidade.
+2. O/a autor/a apenas pode licenciar sua informação sob a licença se ele
+   declarar que não relicenciará a informação. 
+
+## Licença do Conjunto de Licenciamento Livre
+
+Atribui ao detentor/a do texto do Conjunto de Licenciamento Livre as seguintes liberdades:
+
+1. A liberdade de armazenar o texto do Conjunto.
+2. A liberdade de manipular o texto do Conjunto, inclusive para criar novas licenças.
+3. A liberdade de distribuir o texto do Conjunto, modificada ou não. 
+
+### Obrigações do/a licenciado
+
+1. Desde que esta licença acompanhe a informação.
+2. Restrição de lucro: Este Conjunto de Licenciamento Livre e esta licença
+   podem ser utilizados apenas para criar licenças e licenciar conteúdos com
+   finalidades não lucrativas. 
+
+### Licença da licença
+
+O texto desta licença está licenciado por ele mesmo. 
+
+## Exemplo
+
+Estabelece o seguinte texto como a licença padrão de distribuição de conteúdo
+produzido pelo Coletivo:
+
+    1. Licença de Manipulação de Informações do Grupo $coletivo
+    
+    Licença baseada no Conjunto de Licenciamento Livre[1] do Encontro: Cultura
+    Livre e Capitalismo[2].
+    
+    2. Liberdades atribuídas ao/à licenciado/a
+    
+    Atribui ao detentor/a da informação as seguintes liberdades:
+    
+       1. A liberdade de armazenar a informação.
+       2. A liberdade de manipular a informação.
+       3. A liberdade de distribuir a informação, modificada ou não. 
+    
+    Desde que as condições listada na seção Obrigações do/a licenciado/a a seguir
+    sejam respeitadas.
+    
+    3. Obrigações do/a licenciado/a
+    
+    3.1 Viralidade
+    
+    Desde que esta licença acompanhe a informação.
+    
+    3.2 Restrição mercantil
+    
+        * Desde que para fins não-comerciais. 
+    
+    3.3 Restrição de citação
+    
+        * Desde que a fonte seja citada. 
+    
+    3.4 Restrição de distribuição
+    
+        * Caso o conteúdo seja distribuído por você, o Grupo $coletivo deve ser
+          notificado antecipadamente.
+        * Caso ocorra uma modificação, distribuir a
+          informação modificada e notificar antecipadamente o Grupo $coletivo. 
+    
+    4. Liberdades e obrigações atribuídas ao/à licenciante
+    
+        * O Grupo $coletivo pode a qualquer momento revogar o licenciamento da
+          informação para uma determinada pessoa ou entidade.
+    
+    [1] https://protocolos.fluxo.info/organizacao/comunicacao/license/
+    [2] http://encontro.fluxo.info
+
+Não é obrigatória nem compulsória a utilização desta licença, mas conteúdo
+veiculado pelo ou em nome do Coletivo a utiliza por padrão caso não haja menção
+formal em contrário.
+
+### Responsabilização
+
+A(s) pessoa(s) responsável(is) pelo processo ficam encarregadas de manter o
+texto da licença em um local público acessível via web para que possa ser
+referenciado por outros textos do Coletivo, além de adicionar a seguinte nota
+antes do texto da licença:
+
+`
+Desde que não mencionado em contrário, todo o conteúdo produzido pelo Grupo
+$coletivo é distribuído de acordo com a Licença de Manipulação de Informações do
+Grupo $coletivo.
+`
diff --git a/docs/social/coletivo/comunicacao/list.md b/docs/social/coletivo/comunicacao/list.md
new file mode 100644
index 0000000..9926c00
--- /dev/null
+++ b/docs/social/coletivo/comunicacao/list.md
@@ -0,0 +1,75 @@
+# Administração da Lista do Coletivo
+
+Este processo estabelece as linhas gerais para a administração da Lista de
+Discussão do Coletivo, estabelecida com o [Protocolo de Ação do $coletivo](/coletivo/coletivo/).
+
+Critérios de participação
+-------------------------
+
+1. Para participar da lista do Coletivo, uma pessoa precisa satisfazer o nível
+   ''3'' de [ACL](/coletivo/comunicacao/acl.html), isto é, fazer parte do Coletivo.
+2. Apenas [emails suficientemente seguros](/coletivo/comunicacao/infosec.html)
+   podem ser adicionados à lista.
+
+Responsabilização
+-----------------
+
+Para que seja possível manter tal lista, é necessário que as instâncias de
+comunicação por ela utilizadas estejam operantes. Assim, o Grupo de Trabalho
+formado pelas pessoas responsáveis por esse processo deve:
+
+* Garantir, na medida do possível, a existência da Lista do Coletivo e
+  mantendo a documentação correspondente.
+* Administrar e moderar a Lista do Coletivo.
+* Inscrever e desinscrever pessoas na Lista do Coletivo.
+
+Dependências
+------------
+
+A realização deste processo depende da realização dos seguintes processos:
+
+* [Organização do Coletivo](/coletivo/coletivo).
+* [Lista de acesso à participação (acl.html)](/coletivo/comunicacao/acl.html).
+* [Política de segurança da informação](/coletivo/comunicacao/infosec/).
+
+Administração da Lista de Mensagens de Sistema
+----------------------------------------------
+
+Este processo estabelece as linhas gerais para a administração da Lista de
+Mensagens de Sistema, utilizada para receber mensagens de sistema das diversas
+camadas do Coletivo.
+
+Critérios de participação
+-------------------------
+
+1. Para participar da lista do Coletivo, uma pessoa precisa satisfazer o nível
+   ''3'' de [ACL](/coletivo/comunicacao/acl.html), isto é, fazer parte do Coletivo.
+
+2. Apenas [emails suficientemente seguros](/coletivo/comunicacao/infosec/) podem ser
+   adicionados à lista.
+
+Responsabilização
+-----------------
+
+Para que seja possível manter tal lista, é necessário que as instâncias de
+comunicação por ela utilizadas estejam operantes. Assim, o Grupo de Trabalho
+formado pelas pessoas responsáveis por esse processo deve:
+
+* Garantir, na medida do possível, a existência da Lista de Mensagens de
+  Sistema e manter a documentação correspondente.
+
+* Administrar e moderar a Lista de Mensagens de Sistema.
+
+* Inscrever e desinscrever pessoas e emails administrativos na Lista de
+  Mensagens de Sistema.
+
+Observação: emails administrativos (isto é, emails de sistema) devem ser
+cadastrados com a recepção de mensagens desabilitadas, a não ser em casos
+especiais em que isso se fizer necessário.
+
+Dependências
+------------
+
+A realização deste processo depende da realização dos seguintes processos:
+
+* [ACL Lista de acesso à participação (acl.html)](/organizacao/comunicacao/acl.html).
diff --git a/docs/social/coletivo/comunicacao/transparency.md b/docs/social/coletivo/comunicacao/transparency.md
new file mode 100644
index 0000000..9b17ea9
--- /dev/null
+++ b/docs/social/coletivo/comunicacao/transparency.md
@@ -0,0 +1,55 @@
+# Transparência e compartilhamento de informações e protocolos
+
+O presente processo estabelece critérios de transparência e compartilhamento de
+informações e protocolos desenvolvidos dentro e fora do Coletivo.
+
+## Protocolos
+
+No âmbito do presente processo, entende-se por "protocolos" o conteúdo textual
+de templates, protocolos ou propostas de processo e não especificidades de
+determinadas instâncias processuais ou mesmo informações de responsabilização e
+realização das mesmas.
+
+## Compartilhamento
+
+Protocolos que podem ser publicizados por padrão em nível [ACL](/coletivo/comunicacao/acl.html)
+''1.a'' ou superior são todos aqueles que
+
+1. Não mencionam explicitamente o Coletivo, grupos ou pessoas E QUE
+2. Não contenham informações sensíveis, privadas ou particulares.
+
+Protocolos que podem ser publicizados por padrão em nível [ACL](/coletivo/comunicacao/acl.html)
+''2.a'' ou superior são todos aqueles que
+
+1. Afetem as atividades vizinhantes e dos grupos hospedados E QUE
+2. Não mencionam explicitamente grupos ou pessoas E QUE
+3. Não contenham informações sensíveis, privadas ou particulares.
+ 
+Cada processo formal pode alterar seu estado de transparência protocolar.
+
+## Instâncias de compartilhamento protocolar
+
+Muitos dos protocolos e processos desenvolvidos dentro do Coletivo podem ser
+úteis para outros grupos. Da mesma forma, desenvolvimentos similares que
+ocorram fora do Coletivo podem servir de inspiração para processos internos.
+
+Assim, o Coletivo permite por padrão que os protocolos que possam ser
+compartilhados em nível [ACL](/coletivo/comunicacao/acl.html) ''1.a'' detalhados na seção
+anterior sejam compartilhados ou integrados à linha de desenvolvimento nos
+seguintes locais:
+
+* Sítio "Protocolos do Coletivo", que deve existir em
+  `http://protocolos.$dominio` e que pode conter também análises dos protocolos.
+* Eventualmente em Resource Sharing Protocol (`http://rsp.$dominio`), caso aplicável.
+* Em outros locais, mediante pedido formal ao Coletivo.
+
+## Responsabilização
+
+As pessoas responsabilizadas pelo presente processo ficam encarregadas de
+manter o sítio "Protocolos do Coletivo".
+
+## Dependências
+
+A realização deste processo depende da realização dos seguintes processos:
+
+* [Lista de acesso à participação (acl.html)](/organizacao/comunicacao/acl.html).
diff --git a/docs/social/coletivo/comunicacao/vizinhanca.md b/docs/social/coletivo/comunicacao/vizinhanca.md
new file mode 100644
index 0000000..c538c85
--- /dev/null
+++ b/docs/social/coletivo/comunicacao/vizinhanca.md
@@ -0,0 +1,65 @@
+# Lista da Vizinhança
+
+Este processo estabelece as linhas gerais para o funcionamento da vizinhança do
+`$coletivo`, definida como o espaço de intercâmbio para o Coletivo, pessoas e
+grupos hospedados, amigos e/ou simpáticos.
+
+Os espaços da vizinhança são todos aqueles que se fazem parte do nível 2. da
+[Lista de acesso](/coletivo/comunicacao/acl.html), em especial uma lista de discussão por
+email denominada de Lista da Vizinhança do $coletivo com nível ALC ''2.a''.
+
+## Critérios de participação
+
+Será considerado satisfeito o critério ACL ''2.a'' para participação na
+vizinhança as pessoas ou grupos que:
+
+1. Já estiverem sendo hospedadas pelo Coletivo. Caso o grupo hospedado seja
+   muito aberto e muito amplo, em princípio apenas as pessoas relacionadas
+   diretamente com a hospedagem OU
+
+2. Mediante processo formal para decidir se tal pessoa ou grupo é confiável o
+   suficiente para participar de tal nível de acesso.
+
+Apenas [emails suficientemente seguros](/organizacao/comunicacao/infosec.html) podem
+ser adicionados à lista.
+
+## Procedimento de participação
+
+Pessoas que satisfazem os critérios de participação podem pedir inscrição ou
+serem convidadas a participar da vizinhança. No ato da inscrição, a seguinte
+mensagem de boas vindas com pedido de apresentação e recomendações de
+participação deve ser enviada:
+
+    Seja bem vindo/a à lista da vizinhança do $coletivo :)))
+    
+    Esta é uma lista composta por pessoas e grupos hospedados ou que são
+    considerados/as confiáveis pelo Coletivo. Este é um espaço de intercâmbio, trocas
+    e livre associação entre os/as participantes.
+    
+    Pedimos por gentileza para que você
+    
+      - Se apresente e aproveite para, caso queira, compartilhar sua história,
+        objetivos e anseios.
+    
+      - Não repasse informações veiculadas nessa lista a terceiros/as sem pedir antes.
+    
+      - Evite enviar muitas mensagens, principalmente se relacionadas a divulgações,
+        mas sinta-se à vontade para fazer isso quando julgar necessário.
+
+## Responsabilização
+
+Para que seja possível manter a vizinhança, é necessário que as instâncias de
+comunicação por ela utilizadas estejam operantes. Assim, o Grupo de Trabalho
+formado pelas pessoas responsáveis por esse processo deve:
+
+* Configurar a descrição da lista para "Vizinhança ao Grupo $coletivo".
+* Administrar e moderar a Lista da Vizinhança.
+* Inscrever e desinscrever pessoas na Lista da Vizinhança, enviando mensagem de
+  boas-vindas, termo de aceitação e pedido de apresentação.
+
+## Dependências
+
+A realização deste processo depende da realização dos seguintes processos:
+
+* [Lista de acesso à participação (acl.html)](/organizacao/comunicacao/acl.html).
+* [Política de segurança da informação](/organizacao/comunicacao/infosec.html).
diff --git a/docs/social/coletivo/contabilidade.md b/docs/social/coletivo/contabilidade.md
new file mode 100644
index 0000000..9a49179
--- /dev/null
+++ b/docs/social/coletivo/contabilidade.md
@@ -0,0 +1,41 @@
+# Contabilidade
+
+A [Contabilidade](/coletivo/contabilidade), por possibilitar a manipulação de
+recursos do coletivo que podem ser usados para a aquisição, manutenção e
+proteção de outros recursos, representa um ganho em autonomia.
+
+A contabilidade consiste nas seguintes tarefas:
+
+1. Efetuar os depósitos, saques e transferências em uma conta bancária (gestão
+   financeira), observando os [critérios](/coletivo/contabilidade/criterios)
+   sobre:
+  a. Doação (de e para o Coletivo).
+  b. Arrecadação.
+  c. Gastos.
+2. Transparência
+  a. Manter um balanço atualizado em local de acesso restrito ao Coletivo.
+  b. Fornecer os dados contábeis de acordo com os [critérios de
+     transparência](/coletivo/contabilidade/criterios) estabelecido pelo Coletivo.
+
+## Situações emergenciais e não-emergenciais
+
+O grupo de trabalho formado pelas pessoas responsáveis por este processo se compromete a:
+
+1. Em casos não-emergenciais, atender requisições (depósitos, saques, etc e
+   cujo uso estiver aprovado) em até '''2 semanas''', isto é, '''14 dias incluindo
+   finais de semana e feriados'''.
+2. Em casos de emergência, disponibilizar recursos (cujo estiver aprovado) em
+   até '''48 horas''', mantendo o Coletivo informado nas situações em que tal
+   prazo não puder ser atendido (por exemplo no caso férias, viagens, etc).
+
+## Responsabilização
+
+As pessoas responsáveis ficam encarregadas, além das tarefas contábeis
+mencionadas anteriormente, de:
+
+1. Fornecer ao menos conta bancária que possa ser utilizada para o
+   armazenamento de dinheiro do Coletivo e manter tal informação atualizada em
+   local de acesso restrito ao Coletivo.
+2. Antes de deixarem de ser responsáveis pelo processo (i.e, antes de saírem
+   dele), de transferirem os recursos financeiros do Coletivo que estejam de posse
+   para os/as responsáveis remanescentes.
diff --git a/docs/social/coletivo/contabilidade/criterios.md b/docs/social/coletivo/contabilidade/criterios.md
new file mode 100644
index 0000000..bf05fc2
--- /dev/null
+++ b/docs/social/coletivo/contabilidade/criterios.md
@@ -0,0 +1,153 @@
+# Critérios financeiros
+
+Este processo estabelece os critérios financeiros sobre
+
+1. Doação (de e para o Coletivo).
+2. Arrecadação.
+3. Gastos.
+4. Transparência.
+5. Remuneração.
+6. Ajuda de custos.
+7. Lucro e contas bancárias.
+
+## Doação
+
+Com relação à doações é adotado o seguinte critério (oriundo dos
+[http://encontro.fluxo.org/Principal/ConjuntoDePrincipiosEticos Princípios das
+mídias e grupos livres]):
+
+    10. Sobre doações: Se recebem dinheiro, o fazem apenas como doação, ou seja:
+        qualquer apoiador deve saber que seus recursos não serão empregados senão para
+        os fins estritos de criação de espaços comunicativos livres, sendo vedadas as
+        práticas de mercantismo cultural, social ou político. Tais doações são aceitas
+        apenas se anônimas (isto é, não publicizadas). Dinheiro governamental ou
+        empresarial não é aceito. 
+
+Ou seja, o Coletivo apenas recebe doações que satisfaçam o critério acima. No
+caso de doações que o Coletivo pode efetuar, as mesmas devem ser de acordo com
+o critério de gastos.
+
+## Arrecadação
+
+Com relação à arrecadação de recursos, é adotado o seguinte critério (oriundo
+dos [http://encontro.fluxo.org/Principal/ConjuntoDePrincipiosEticos Princípios
+das mídias e grupos livres]):
+
+    11. Sobre auto-sustentabilidade: As mídias e grupos livres estimulam a geração de
+        mecanismos de autosustentabilidade (ou "autodependência") local e comunitária.
+        Exemplos: venda de camisetas, comidas, rifas, organização de festas, mostra de
+        vídeos, etc. Tratam-se de atividades criadas e organizadas para estimular a
+        vivência em coletivo e a escapar das práticas capitalistas. É recomendável que,
+        dentro dos grupos e entre eles, exista uma socialização dos recursos e que os
+        individuos também adotem essa prática, compartilhando recursos pessoais com o
+        coletivo, para criar ambientes de solidariedade comunitária, onde ninguém seja
+        excluído por falta de recursos. 
+
+## Gastos
+
+Os gastos (reembolso, doações, aquisições, etc) são efetuados através de
+procedimento formal.
+
+## Transparência
+
+Com relação à transparência da contabilidade, é adotado o seguinte critério
+(oriundo dos [http://encontro.fluxo.org/Principal/ConjuntoDePrincipiosEticos
+Princípios das mídias e grupos livres]):
+
+    12. Sobre a gestão financeira: Para garantir essas condições de financiamento,
+        toda a gestão financeira das mídias e grupos livres é publica: tanto as
+        informações contábeis quanto a participação nas decisões são acessíveis às
+        pessoas concernidas nas ações desta organização. 
+
+Portanto, o Coletivo adota o critério de fornecer/publicar:
+
+1. Seus critérios financeiros.
+2. [wiki:Contabilidade/Planejamento Seu planejamento financeiro].
+3. [wiki:Contabilidade/Balanco Seu balanço financeiro].
+
+às pessoas afetadas pela organização do Coletivo (por exemplo, grupos
+hospedados e parcerios) levando em conta as restrições de privacidade e
+segurança, isto é, a publicação/disponibilização do balanço é restrita aos
+grupos e pessoas próximas.
+
+## Remuneração
+
+Sobre à remuneração pelo trabalho realizado dentro do Coletivo, é adotado o
+seguinte critério (oriundo dos
+[http://encontro.fluxo.org/Principal/ConjuntoDePrincipiosEticos Princípios das
+mídias e grupos livres]):
+
+    21. Sobre a remuneração pelo trabalho: As mídias e os grupos livres funcionam
+        exclusivamente a partir de trabalho voluntário.
+
+Em outras palavras, o Coletivo não remunera pelo trabalho nele e por ele
+realizado. A remuneração, contudo, não pode ser confundida com a ajuda de
+custos.
+
+## Ajuda de custos
+
+A ajuda de custos é um recurso utilizado para criar um ambiente de igualdade de
+participação no Coletivo, por exemplo nos casos de custeio de ida à reuniões
+para pessoas que no momento não estejam em condições de fazê-lo, etc. Assim,
+integrantes do Coletivo que não possam participar de alguma atividade do
+Coletivo por não disporem de recursos materiais para fazê-lo podem solicitar
+ajuda de custos para o Coletivo.
+
+## Lucro e contas bancárias
+
+O Coletivo não possui fins lucrativos. Por isso, o Coletivo não se utiliza de
+operações financeiras com o intuito de auferir lucro, mas pode se utilizar de
+meios lícitos que lhe garantam a atualização monetária.
+
+Assim, quanto ao uso de transações e contas bancárias, o Coletivo reconhece
+que, apesar da segurança do dinheiro poder ser garantida de outras formas, a
+utilização de contas bancárias pode ser útil para
+
+* Facilitar a arrecadação financeira por dispor da rede bancária.
+* Permitir a atualização financeira.
+
+O Coletivo reconhece as contradições de utilizar o sistema financeiro e por
+isso se compromete a utilizar somente o recurso da caderneta de poupança, que
+possui as seguintes características:
+
+* Baixo risco.
+* Rendimentos baixos, uma vez que ela é basicamente apenas uma atualização
+  monetária do dinheiro e por isso é praticamente o fundo de investimentos
+  menos prejudicial à sociedade.
+
+## Licença
+
+Como estes critérios se utilizam de trechos oriundos dos
+[http://encontro.fluxo.org/Principal/ConjuntoDePrincipiosEticos Princípios das
+mídias e grupos livres]), segue a seguinte licença de manipulação dos mesmos
+(disponível também [http://encontro.fluxo.org/Principal/Licenca aqui]):
+
+    1.  Licença de Manipulação do Conteúdo Deste Sítio
+    
+    Copyright (c) Encontro: Cultura Livre e Capitalismo: desde que não mencionado
+    em contrário, este conteúdo é distribuído de acordo com a licença a seguir. 
+    
+    2.  Liberdades atribuídas ao/à licenciado/a
+    
+    Atribui ao detentor/a da informação as seguintes liberdades:
+    
+       1. A liberdade de armazenar a informação.
+       2. A liberdade de manipular a informação.
+       3. A liberdade de distribuir a informação, modificada ou não. 
+    
+    Desde que as condições listada na seção Obrigações do/a licenciado/a a seguir
+    sejam respeitadas.
+    
+    3.  Obrigações do/a licenciado
+    
+    3.1  Viralidade
+    
+        * Desde que esta licença acompanhe a informação. 
+    
+    3.2  Restrição mercantil
+    
+        * Desde que para fins não-lucrativos. 
+    
+    3.3  Restrição de autoria e fonte
+    
+        * Desde que a fonte seja citada. 
diff --git a/docs/social/coletivo/contabilidade/planejamento.md b/docs/social/coletivo/contabilidade/planejamento.md
new file mode 100644
index 0000000..18414df
--- /dev/null
+++ b/docs/social/coletivo/contabilidade/planejamento.md
@@ -0,0 +1,23 @@
+# Planejamento financeiro
+
+O Coletivo adota o seguinte plano financeiro baseado numa reserva mínima e no seu excedente:
+
+1. A reserva mínima é a quantidade de dinheiro necessária para arcar com a soma (total: `R$x`) de:
+  a. Gasto `a`.
+  b. Gasto `b`.
+  c. Gasto `c`.
+
+2. Se o Coletivo possuir recursos em caixa cuja soma é maior do que a reserva
+   mínima, a diferença entre o total de dinheiro e a reserva mínima é considerado
+   como excedente.
+
+3. A arrecadação deve ser constante de modo que o Coletivo tenha sempre em
+   caixa uma reserva mínima ou condições de recuperar sua reserva mínima.
+
+Utilização do dinheiro
+----------------------
+
+* A reserva mínima deve ser utilizada apenas pelo Coletivo.
+* O excedente arrecadado pelo Coletivo pode ser disponibilizado para outros
+  grupos, coletivos e pessoas.
+* A cada ano o valor da reserva mínima deverá ser revisado de acordo com o IGP-M.
diff --git a/docs/social/coletivo/interpretacoes.md b/docs/social/coletivo/interpretacoes.md
new file mode 100644
index 0000000..7823790
--- /dev/null
+++ b/docs/social/coletivo/interpretacoes.md
@@ -0,0 +1,893 @@
+# Interpretações do Protocolo de Ação Coletiva
+
+Uma interpretação possível
+--------------------------
+
+* Versão: 0.2.
+* Licença: LIMICS[1].
+
+Este documento contém uma interpretação possível do Protocolo de Ação
+Coletiva[2], que aqui é considerado como um processo possível de existência de
+um coletivo autônomo tendo como propriedades emergentes a robustez, a
+resiliência, a resistência a falhas e a adaptabilidade ao redor da otimização
+de atividades. Este texto considera que a adoção de tal protocolo possa servir
+a alguns grupos de afinidade desde que ele atenda aos propósitos do grupo (um
+processo deve ser útil ao grupo, não o contrário).
+
+Característica geral
+--------------------
+
+Para grupos pequenos e coesos, a existência apenas de processos formais pode
+não representar um grande problema. Mas, se o grupo for grande, e/ou dispersivo
+e/ou com o foco de atuação abrangente, etc, as discussões e as tomadas de
+decisão podem se tornar muito cansativas e demoradas, além de nem sempre serem
+produtivas. Fora isso, o temor de não contemplar a todas as pessoas do coletivo
+pode fazer com que sejam aprovadas propostas que na prática não serão
+realizadas, mesmo se com a aprovação houver a responsabilidade do coletivo para
+cumpri-las.
+
+Muitos grupos possuem apenas processos formais, de modo que qualquer
+procedimento a ser realizado nesse grupo requer a pessagem pelo processo de
+tomada de decisão. Em muitas ocasiões, os processos formais acabam servindo,
+mesmo que as decisões sejam tomadas por consenso, para legitimar uma
+concentração de poder e um engessamento da estrutura dos grupos e contribuindo
+para criar grupos avessos a qualquer forma de organização definida. Surgem
+então os grupos organizados de maneira puramente informal, o que funciona muito
+bem para favorecer a espontaneidade e a auto-organização mas que também podem
+apresentar sérios problemas pela própria falta de formalidade.
+
+A características geral do Protocolo de Ação Coletiva consiste na articulação
+de uma forma possível de organização coletiva que responda tanto à problemática
+da tirania das organizações sem estrutura[3] quanto ao engessamento ocasionado
+por modos de organização estruturados de forma excessivamente rígida.
+
+O Protocolo de Ação Coletiva também pode ser entendido como uma forma de
+organização social do trabalho que possui um grande vínculo com a autonomia do
+grupo.
+
+Configuração Organizacional
+---------------------------
+
+Chamaremos de Coletivo aos fluxos informacionais, energéticos e materiais de um
+dado grupo de afinidade -- isto é, um grupo de pessoas que nutrem afeto umas
+pelas outras em relação a determinadas ou indeterminadas atividades -- que
+operam ao redor de uma dada configuração de autonomia definida pelo próprio
+grupo de afinidade. Por outro lado, é esta autonomia que define o Coletivo
+enquanto um grupo de afinidade por esta delinear a sua atuação:
+
+    Coletivo <-------------> Autonomia
+       ^                          ^
+        \                        /
+         `------> Fluxos <------'
+
+Tudo o que ocorre no Coletivo é um processo. Os processos assumem diversas
+manifestações, mas principalmente são fluxos e registros[4]. Todo o processo é
+um registro e um fluxo. O registro armazena o estado do fluxo, estando
+acessível para qualquer pessoa do Coletivo. Já o fluxo é a produção do processo
+e aquilo que efetua a escrita no registro[5].
+
+Em resumo: tudo no Coletivo é processo/fluxo/registro, sendo essa uma
+conceituação importante para auxiliar no entendimento do que se realiza, do que
+se produz no Coletivo. A mera existência de fluxos não garante ao Coletivo sua
+existência, mudança ou permanência, já que fluxos podem ser disjuntivos,
+dispersivos, explosivos.
+
+A autonomia do Coletivo é sua capacidade de determinar os fluxos que o afetam.
+A autonomia não opera apenas nas relações internas do Coletivo pelo fato deste
+não constituir um sistema fechado/isolado: o Coletivo pode ser entendido como
+um sistema aberto dentro de um sistema aberto mais abrangente que é o próprio
+mundo. Manter sua autonomia, isto é, sua autodeterminação de mudança e
+permanência (do mundo e de Si), é estipular uma relação de abertura e
+fechamento em relação ao mundo.
+
+De modo análogo, as pessoas que fazem parte do Coletivo também tem sua própria
+autonomia de ação. Enquanto integrantes do Coletivo, contudo, as pessoas
+concordam que sua autonomia pessoal não pode ser posta em detrimento da
+autonomia do Coletivo. Enquanto pessoas atuando fora do coletivo, exercem sua
+autonomia individual. Quando atuando como partes do Coletivo, sua autonomia
+enquanto indivíduos é limitada pela autonomia do Coletivo.
+
+Um/a integrante do Coletivo atua dentro dele quando utiliza os recursos e o
+nome do Coletivo. Por outro lado, um/a integrante do Coletivo atua fora dele
+quando não utiliza os recursos ou o nome do Coletivo. Intregrantes do Coletivo
+não realizam ações (dentro ou fora do Coletivo) que, conscientemente, possam
+prejudicar a autonomia do Coletivo.
+
+A autonomia, por ser uma propriedade de autodeterminação, pressupõe, no caso de
+uma associação de pessoas, um processo de tomada de decisões que respeite
+igualmente a autonomia das pessoas enquanto integrantes do Coletivo. Em outras
+palavras, é necessário que exista um processo formal para a operação da
+autonomia do Coletivo.
+
+Além disso, mesmo atuando dentro do Coletivo, a autonomia pessoal não é
+suprimida, apenas diminuída: há uma grande margem entre a autonomia da pessoa e
+a do Coletivo, o que permite que exista, dentro do Coletivo, fluxos que não
+interfiram na autonomia do Coletivo. Em outras palavras, é possível que exista,
+dentro do Coletivo, processos sem forma necessariamente definida e que não
+operem a autonomia do Coletivo, isto é, processos informais.
+
+Os Processos Formais
+--------------------
+
+Como dito anteriormente, o Coletivo possui dois tipos essenciais de
+processos/fluxos no que concerne ao uso da autonomia: os formais e os
+informais. Se nos informais não há interferência na autonomia do Coletivo, para
+os formais é preciso não apenas de um processo de tomada de decisão como uma
+garantia que as decisões tomadas sejam realizadas, do contrário a autonomia não
+pode ser exercida.
+
+No Coletivo, tal garantia é obtida pela responsabilização, que é o ato de
+chamar para Si a incumbência por um dado procedimento assim como responder pela
+sua realização total, parcial ou mesmo pela sua não-realização. É através da
+responsabilização que o Coletivo tem garantias mínimas de que o processo será
+realizado.
+
+Em resumo, os processos formais tem as seguintes características:
+
+* Forma necessariamente definida de antemão pelo coletivo E
+* Lidam com a autonomia do coletivo. PORTANTO
+* Precisam ser acompanhados pela responsabilização mínima para o processo não
+  falhar por falta de iniciativa
+
+Uma forma de saber saber se um processo deve ser formal ou informal é perguntar
+se o mesmo afeta (mexe com, precida da) ou não a automonia do Coletivo.
+
+Fluxograma de tomada de decisões e responsabilização formal
+-----------------------------------------------------------
+
+Existem inúmeras maneiras de se estabelecer um procedimento formal. No caso do
+Protocolo de Ação Coletiva, os processos formais do Coletivo são realizados de
+acordo com o seguinte diagrama:
+
+        .------------------->-----------------.
+       /  .----------<--------------<-------.  \
+      |  '                                   \  \
+      |  |               .------>-----.       \  \
+      |  |              |              \       \  \
+     Proposta -----> Discussão ->--.    \       \  \
+        |  ^            |           \    \       \  \
+        |  |            |            \    \       \  \
+        |   `----<-----'             |     \       \  \
+        |                            |      |       \  \
+         `------>------ Decisão --<--'      |        \  \
+                          | |               |         \  \
+                          | |               |          | |
+      Atribuição de --<---' '---> Arquivamento --->---'  ;
+    Responsabilidades ----->-------'   ^    \           /
+         ^  |              ___________/      `---<-----'
+         |   \           .'
+         |    `--> Realização -->--.
+         |           |  |           \
+         |           |  |           /
+          `----<-----'   `-----<---'
+
+Todas as etapas de um processo formal apresentam ao menos uma via de entrada e
+outra de saída. Não há começo e nem fim, apenas um processo fluído de
+realização autônoma. Cada etapa é discutida nas sessões a seguir.
+
+Etapa de Proposta
+-----------------
+
+Esta etapa não é a primeira nem a última, mas foi escolhida como tal nesta
+explicação apenas para facilitar o entendimento dos processos formais. É na
+etapa de proposição que a idéia de um procedimento formal é lançado ao
+Coletivo. A idéia -- ou descrição -- do processo pode vir do Arquivo de
+propostas, de uma Discussão anterior, de um procedimento informal que se julga
+importante formalizar ou mesmo de uma pessoa ou grupo de pessoas de dentro ou
+de fora do Coletivo.
+
+Recomenda-se que a proposta de processo formal seja bem explicada, contenha uma
+sugestão de prazo de decisão e que sugira o ciclo de vida do processo, isto é,
+como, quando e por quanto tempo ele deve ser realizado (se aplicável), assim
+como os critérios e prazo para atribuição de responsabilidade, o seu término
+(se aplicável) e recomendações para situações emergenciais (se aplicável).
+
+Uma vez lançadas, propostas podem ser discutidas, aprovadas ou arquivadas, como
+veremos a seguir.
+
+Etapa de Discussão
+------------------
+
+Após a introdução de uma proposta, a discussão não é estritamente necessária,
+isto é, a Proposta pode seguir diretamente para a Decisão. No entanto, a
+discussão não deixa de ter importância: ela não só ajuda a arquivar as
+propostas que não foram adotadas num dado momento como efetuam as alterações
+desejadas nas propostas antes da tomada de decisão. A discussão é o momento
+para o refinamento das propostas que as pessoas do Coletivo acharem
+interessantes.
+
+Alterações em propostas fazem com que o procedimento formal em questão volte
+para a etapa de Proposta. Propostas que não seguirem para a etapa de Decisão ou
+que não forem alteradas até o prazo proposto devem ser arquivadas.
+
+Propostas que vem de fora do Coletivo e que forem discutidas e alteradas devem
+ser enviadas também para o grupo ou à pessoa de fora do Coletivo responsável
+pela sua introdução, apesar destas pessoas não participarem da discussão
+interna do Coletivo. Se tal pessoa ou grupo concordar com a proposta alterada,
+então o processo formal em questão retorna à etapa de Discussão com a nova
+proposta. Caso contrário, isto é, a pessoa ou grupo de fora do Coletivo não
+concordar com a proposta alterada, então o processo formal em questão é
+arquivado e a pessoa ou grupo devem ser informados do arquivamento (exceto se
+as partes externas apresentarem uma nova alteração à proposta ou mais
+argumentos à discussão).
+
+Etapa de Decisão
+----------------
+
+Como dito anteriormente, a autonomia, por ser uma propriedade de
+autodeterminação, pressupõe, no caso de uma associação de pessoas, um processo
+de tomada de decisões que respeite igualmente a autonomia das pessoas enquanto
+integrantes do Coletivo. No Protocolo de Ação Coletiva, a etapa de Decisão é o
+momento no qual o Coletivo decide se determinada proposta é pertinente ou não,
+isto é, se o Coletivo julga, apóia e concorda com o seu teor ou o contrário.
+
+É importante ressaltar que há uma distinção entre julgar uma proposta
+pertinente ao Coletivo, se responsabilizar por ela e finalmente realizá-la. Na
+etapa de Decisão, apenas o teor da proposta é avaliado. Se o Coletivo aprova
+uma proposta, isso significa que a sua eventual execução será feita em nome do
+Coletivo, mesmo que seu nome não seja levado a público (isto é, para fora do
+Coletivo). 
+
+O Protocolo de Ação Coletiva assume o consenso como a forma de tomada de
+decisões. A participação em consenso depende do acesso às informações do
+coletivo; para participar ativamente de uma decisão, é preciso, portanto, estar
+acompanhando as informações referentes à proposta em questão. Se não há
+consenso sobre a aprovação de uma proposta, a mesma permanece bloqueada,
+podendo ter seu prazo estendido.
+
+Se manter em silêncio é considerado como concordância com a proposta em
+questão. O consenso velado, isto é, quando ninguém ou apenas poucas pessoas se
+posicionam em relação a uma proposta de processo formal, não é um problema
+desde que haja pessoas que se responsabilizem pelo andamento do processo
+aprovado; sem pessoas se responsabilizando, o processo é
+arquivado/interrompido/congelado na próxima etapa, de tal modo que o silêncio
+das pessoas não interfere no processo de tomada de decisão.
+
+Quanto aos prazos, recomenda-se que os mesmos sejam estipulados relativamente
+ao tempo que as pessoas ativas no coletivo levam para tomar conhecimento,
+discutir, propor alterações, pedirem eventuais adiamentos, etc, sendo passíveis
+de prorrogação ou antecipação através de um pedido explícito por alguma pessoa
+do Coletivo. No entanto, se não há pedido para alteração de prazo, a data
+inicial da proposta deve ser respeitada. Se não sofrerem objeção, pedidos de
+adiantamento ou adiamento de prazos são automaticamente aceitos. Na medida do
+possíve, prazos razoáveis são recomendados em detrimento de prazos
+emergenciais. É importante manter uma boa temporalidade para a etapa de decisão
+por possibilitar a participação de quem quiser e permitir a apreciação
+cuidadosa das propostas.
+
+Aprovações de propostas que vem de fora do Coletivo ou que tenham como
+participantes grupos ou pessoas de fora do coletivo são comunicadas às
+pessoas/grupos de fora do Coletivo apenas após a atribuição de
+responsabilidades, uma vez que o Coletivo terá responsabilidade sobre a
+realização de uma proposta a partir do momento que informar o ator/a externo da
+decisão da proposta.
+
+Etapa de Atribuição de Responsabilidades
+----------------------------------------
+
+Se a aprovação uma proposta requer a aceitação de todo o Coletivo, a atribuição
+de responsabilidades, por outro lado, tem um caráter distinto: não é preciso
+que todo o Coletivo assuma responsabilidades pela execução de uma proposta, mas
+apenas um determinado número de pessoas do Coletivo é necessário à execução da
+proposta em questão. A etapa de atribuição de responsabilidades é o momento em
+que um grupo de trabalho será formado com a responsabilidade pela realização da
+proposta aprovada.
+
+A atribuição de responsabilidade é uma etapa sensível porque constitui o
+momento onde a garantia de realização do procedimento será dada. Não adianta
+apenas tratar da responsabilização sem tratar da irresponsabilização: essa
+etapa cuida não só do comprometimento de pessoas do Coletivo com relação a um
+dado processo formal mas como também do caso emergencial quando pessoas do
+Coletivo tiverem comportamento irresponsável perante um processo formal. Em
+outras palavras, a etapa de Atribuição de Responsabilidades também deve ser a
+etapa de planejamento de falhas.
+
+A primeira medida para evitar a não-realização do processo formal é a
+minimização dos possíveis pontos de falha, principalmente dos pontos de falha
+singular. Um ponto de falha singular é todo aquele que por si só pode acarretar
+na não realização do processo formal. Um ponto de falha é um ponto de falha
+singular se for o único apoio existente para a realização do processo formal:
+se for removido, o processo não se realiza. Já pontos de falha não-singulares
+são os apoios que, mesmo se removidos, não comprometem a realização do
+processo.
+
+É evidente que se deseja evitar os pontos de falha singulares. Assim, para que
+seja possivel sair da etapa de responsabilizacao para a de realizacão, é
+importante que se estipule o número mínimo de pessoas necessário para que o
+processo seja considerado realizável. Isso depende da tarefa em questão e sua
+especificação é importante para evitar pontos de falha. Assim, por
+responsabilização suficiente se entende o número mínimo de pessoas se
+responsabilizando pelo processo formal para o mesmo ser considerado realizável.
+
+Outra forma de evitar a falha se encontra no detalhamento a respeito da
+responsabilização: a responsabilização não é apenas o comprometimento pelo
+andamento de um dado processo, mas também a responsabilidade de informar com
+antecedência quando não puder mais realizá-lo, assim como auxiliar no processo
+de transição da responsabilidade para outras pessoas, se for o caso.
+
+O não-cumprimento de uma responsabilidade compromete a atribuição de outras
+responsabilidades. Além disso, a atribuição de uma responsabilidade é
+voluntária e deve ser registrada para fins de documentação e para evitar
+mal-entendidos e problemas de comunicação.
+
+A pessoa que se responsabilizar por algum processo formal deve declarar no
+registro do processo formal que:
+
+* Tem conhecimento sobre o procedimento em questão.
+* Irá realizá-lo dentro do prazo estipulado e que manterá o Coletivo informado
+  sobre a sua realização.
+* Caso não possa mais arcar com a responsabilidade, avisará o Coletivo com
+  antecedência suficiente para que o mesmo possa, dependendo do caso, manter a
+  realização do processo, atribuir novas responsabilidades a ele ou então
+  simplesmente encerrá-lo e arquivá-lo.
+
+Processos formais que forem aprovados mas que, findo o prazo para a
+responsabilização, não tiverem responsabilização suficiente atribuída, devem
+seguir para o arquivamento, sendo que o desarquivamento de propostas
+anteriormente aprovadas não pode seguir diretamente para a atribuição de
+responsabilidade, mas sim seguir para a etapa de proposição.
+
+Chamaremos aqui de de grupo de trabalho o conjunto/grupo de pessoas envolvidas
+num mesmo processo (formal ou informal). Lembramos, também, que não é um
+requisito para se estar num grupo de trabalho formal a responsabilização pelo
+processo formal em questão: pode-se estar num grupo de trabalho (formal ou
+informal) de modo informal, isto é, sem ter responsabilidade sobre isso
+(bastando para isso participar das discussões ou acompanhar as respectivas
+informações).
+
+A permanência de pessoas no coletivo que não se voluntariam para se
+responsabilizar por algo não é problema, muito pelo contrário: permite que
+pessoas afins permaneçam no coletivo mesmo se não puderem ajudar em processos
+formais, já que há uma diferença entre não-responsabilidade e
+irresponsabilidade. Assim, as pessoas podem permanecer no Coletivo e serem
+ativas de várias maneiras sem precisarem necessariamente se responsabilizar por
+algo.
+
+No caso de propostas que vem de fora do Coletivo ou que tenham como
+participantes grupos ou pessoas de fora do coletivo são comunicadas às
+pessoas/grupos de fora do Coletivo sobre seu estado de !Aprovação/Realização
+apenas após a atribuição de responsabilidade, isto é, ao final desta etapa.
+
+Etapa de Realização
+-------------------
+
+Apenas processos formais cuja responsabilização foi atribuída podem partir para
+a etapa de realização. Processos que forem realizados e que não tiverem
+prosseguimento definido são arquivados.
+
+Processos formais que, não tendo sido realizados no prazo comprometido pelo
+grupo das pessoas que se responsabilizado por ele, devem retornar à etapa de
+Atribuição de Responsabilidades. De modo análogo, processos em realização mas
+cujos/as responsáveis não puderem mais realizá-los devem retornar à etapa de
+Atribuição de Responsabilidades caso o número de pessoas responsáveis
+remanescentes não for suficiente para a sua realização.
+
+Etapa de Arquivamento
+---------------------
+
+O arquivo, ou banco de propostas, é o local onde ficam armazenadas todas as
+propostas que:
+
+* Não foram aprovadas OU
+* Foram aprovadas mas não foram adotadas responsavelmente OU
+* Foram realizadas e encerradas OU
+* Estavam em realização mas não tem mais o número de pessoas responsáveis
+  suficiente, por exemplo: quando ninguém ou apenas um número insuficiente de
+  pessoas estiverem cuidando de um dado recurso.
+
+Um processo formal é dito em arquivamento quando uma das condições acima for
+verdadeira para ele. No caso de um processo que estava sendo realizado e
+precisar ser arquivado por falta de pessoas responsáveis por ele, as últimas
+pessoas responsáveis por ele devem realizar o procedimento de encerramento e
+arquivamento.
+
+No caso de propostas que vem de fora do Coletivo ou que tenham como
+participantes grupos ou pessoas de fora do coletivo são comunicadas às
+pessoas/grupos de fora do Coletivo sobre seu estado Recusa/Arquivamento apenas
+nesta etapa. 
+
+Observações sobre Processos Formais
+-----------------------------------
+
+Em resumo, o processo formal necessita que haja proposta, decisão e
+responsabilização antes da realização de uma atividade.
+
+É importante ressaltar que o objetivo destes princípios é favorecer o trabalho
+coletivo e otimizar a busca dos compromissos que o grupo de afinidade pode
+adquirir coletivamente. Pelo fluxograma de procedimentos formais, vemos que
+qualquer processo formal que não estiver na responsabilidade de alguém (ou de
+um grupo de trabalho) será automaticamente arquivado/congelado.
+
+Esta é provavelmente a propriedade emergente mais importante desse sistema: a
+etapa de responsabilização atua como um filtro de propostas aprovadas de tal
+forma que apenas o que passar por ela pode ser realizado. A etapa de
+responsabilização introduz uma limitação necessária no processo, o que se
+compatibiliza com a limitação real de atuação do grupo. O processo como um todo
+atua no sentido de encontrar com eficiência as atividades que o Coletivo pode e
+quer realizar.
+
+Um caso degenerado seria um grupo que adote este processo mas que, composto por
+pessoas verborrágicas porém preguiçosas, decidisse fazer tudo mas não se
+responsabilizar por nada, de modo que o processo formal opera como um detector
+de índole e proporciona ao grupo encontrar o que realmente quer fazer: apenas
+discutir.
+
+Indo pela situação oposta, outro grupo que adote este processo mas que, por não
+discutir nada também não decide nada e, consequentemente, não precisa se
+responsabilizar por nada e também não realiza nada. Neste caso o processo
+também auxiliou o grupo a realizar as atividades a que estiver inclinado.
+
+Mesmo em grupos que estão entre esses pólos de atuação, o processo formal
+favorece a triagem das propostas que podem serem postas em prática. Muitas
+vezes as propostas partem de pessoas (ou grupos dentro do Coletivo) que já
+estão predispostas a realizá-las. Noutras, porém, a proposta surge de pessoas
+que não estão inclinadas a realizá-la mas julgam a realização, por parte do
+Coletivo, muito pertinente. Em ambos os casos, se a tomada de decisão avalia se
+a proposta é pertinente e aparentemente viável, a etapa de responsabilização
+dirá se o coletivo possui meios de arcar com sua realização.
+
+Sob o aspecto do registro, cada processo formal pode ser entendido como uma
+instância de uma máquina de estado finito. Seu fluxograma apresenta
+características interessantes: o barramento de arquivamento é full-duplex e que
+existe uma configuração rotacional ao redor da discussão e da realização. Já o
+arquivamento possui basicamente convergências e divergências.
+
+O processo formal é uma maquinação, um processo de desenvolvimento de um
+software social. Ele não impõe regras sobre o teor das propostas (que inclusive
+podem propor a mudança ou abolição do fluxograma), mas apenas regras mínimas
+sobre o próprio andamento do coletivo. No entanto, os próprios princípios de
+organização coletiva compõem um processo formal cuja responsabilidade é de todo
+o coletivo. Consequentemente, ele mesmo passa pelos procedimentos de
+aprovação/execução/responsabilização previstos nele mesmo (bootstrapping e
+recursividade).
+
+Os Processos Informais
+----------------------
+
+Os processos informais do Coletivo são os fluxos que não interferem na sua
+autonomia. Eles apresentam propriedades notáveis para a emergência de padrões,
+para a experimentação, para a auto-organização e para o combate à apatia e ao
+gerenciamento centralizado.
+
+Nos coletivos onde se reconhece apenas a existência de processos formais, está
+subentendido que toda a ação coletiva deve passar pela instância de tomada de
+decisões. Nesse tipo de coletivo, nada se realiza explicitamente sem uma
+decisão central, mantendo-se assim uma cultura de gerenciamento onde a
+iniciativa pessoal ou de um pequeno grupo apenas tem espaço no processo de
+tomada de decisão oficial. Mesmo através do conhecimento empírico é possível
+mostrar que tal modelo muitas vezes afasta a participação e a iniciativa
+pessoal, além de gerar ruído desnecessário na instância formal de decisão por
+ter de decidir a respeito de todos os assuntos e ações pertinentes ao grupo.
+
+Por exemplo: muitas vezes constitui um esforço desnecessário para submeter à
+decisão do Coletivo qual é a melhor data para se realizar uma reunião onde nada
+será decidido pelo Coletivo. Pode ser até mais complicado logisticamente de se
+discutir esse tipo de coisa na instância formal de decisão quando um processo
+informal pode endereçar isso facilmente.
+
+Por isso que, em fluxos que sejam possíveis de serem realizados sem interferir
+na autonomia do Coletivo que o Protocolo de Ação Coletiva incentiva que estes
+sejam processos informais. Como processos formais, pela própria definição, não
+tem forma definida de antemão pelo processo de decisão do Coletivo, eles não
+precisam ser propostos e nem decididos, mas podem ser simplesmente realizados
+desde se constituam como processos, isto é, sejam fluxos e registros (conforme
+nossa definição inicial de um processo). Sendo também registros, os processos
+informais em planejamento ou realização tem sua informação disponibilizada para
+todas as pessoas do Coletivo, sendo então sua existência um convite à
+participação. Por exemplo, procedimentos informais podem começar com um
+informe, convite ou como uma proposta (mas não confundir com uma proposta
+formal).
+
+Em resumo, os processos informais tem as seguintes características:
+
+* Forma não necessariamente definida de antemão E
+* Não afetam a autonomia do coletivo. PORTANTO
+* Não precisam necessariamente estar atrelados à responsabilidade de alguém
+  (isto é, a não-realização de um processo informal não afeta a autonomia do
+  Coletivo).
+
+Trocando em miúdos, os processos informais não necessariamente tem um protocolo
+previamente definido, ou seja, negociado de antemão: sua negociação pode ser
+dar também durante sua realização. Por outro lado, devido à não necessidade de
+responsabilização, os processos informais não tem garantias formais de
+execução.
+
+Cabe ressaltar que processos informais, mesmo não tendo forma previamente
+definida, ainda são processos. Atividades sem informação disponibilizada no
+Coletivo não pode ser considerada como processos (formais ou informais) do
+Coletivo porque não dispõem de igualdade de acesso à informação, requisito para
+a possibilidade de participação (isonomia informacional). A falta de forma
+previamente definida não deve ser confundida com falta de forma (aformalidade):
+nos processos informais, a forma está contida no próprio processo informal (in
+forma) e não em princípios de organização externos (como no caso dos processos
+formais, onde sua forma geral é definida de antemão e externamente ao
+processo).
+
+Certamente há uma vasta gama (talvez a maior parte) das atividades realizadas
+que fogem dessa conceituação de processo, isto é, podem até serem processos
+físicos, mentais, etc, mas pela falta delas figurarem no fluxo de informação do
+Coletivo elas não podem ser consideradas como processos protocolares no sentido
+dado pelo Protocolo de Ação Coletiva, mas apenas processos aformais. Para
+ganhar em termos de organização, o Protocolo de Organização Coletiva restringe
+a denomiação de processo apenas às atividades que integram o fluxo
+informacional do Coletivo (processos do Coletivo são aqueles que foram
+coletivizados).
+
+Formalização e informalização
+-----------------------------
+
+Processos formais e informais são diferenciações que nos ajudam a agir conforme
+a necessidade. Se é preciso voar, experimentar, atuar favorecendo-se com as
+relações sociais e culturais que são naturais sem interferir na autonomia do
+Coletivo, os processos informais permitem que se proceda sem regras dadas de
+antemão. Caso precisemos agir com coesão, com firmeza e favorecendo uma
+coletividade forte (isto é, usando a autonomia do Coletivo), o Protocolo de
+Ação Coletiva encoraja o uso de processos formais.
+
+Os processos formais possuem um andamento mais rígido quando é preciso um
+acordo comum para pessoas agirem conjuntamente sem que precisem abrir mão das
+suas diversidades, das suas diferenças, das suas particularidades, das suas
+culturas. Da mesma forma, as pessoas do Coletivo podem precisar dos processos
+informais se acreditarem ser importante uma ação coletiva que utilize
+exatamente dessas diversidades e diferenças.
+
+Modos formais e informais permanecem distintos em princípio mas, com o tempo,
+também é possível formalizar um processo informal (via consenso e atribuindo
+responsabilidade ao mesmo) ou, por outro lado, transformar um processo formal
+em informal (via consenso e retirando responsabilidade, mas retirando
+igualmente a dependência do coletivo a esse procedimento, isto é, a autonomia
+do coletivo deve se tornar independente do processo que estiver se
+informalizando).
+
+Se o processo formal de tomada de decisões pode ser entendido como um protocolo
+que mantém a coesão do coletivo ao redor de sua autonomia (espaço comum,
+central), os procedimentos informais podem ser entendidos como protocolos
+distribuídos, maleáveis, que se reordenam durante sua existência com uma
+flexibilidade maior do que os processos formais. Alguns processos informais
+podem até ter o caráter experimentalista de descobrir próximas ações que, de
+tão importantes que podem se tornar, se transformem em processos formais.
+
+Fluxo informacional
+-------------------
+
+Estes princípios apenas funcionam se há acesso disponível às informações por
+todas as pessoas que fazem parte do Coletivo (acesso não significa obrigação
+por acompanhar todas as informações que trafegam pelo Coletivo, mas sim
+possibilidade de acompanhamento arbitrário das mesmas). Sendo assim, é
+importante que existam instâncias de tráfego informacional (instâncias
+processuais) que facilitem o acompanhamento dos processos coletivos (tanto
+formais quanto informais) e que satisfaçam requisitos de privacidade e
+segurança que garantam a autonomia do Coletivo.
+
+Convém distinguir três possíveis instâncias informacionais:
+
+* Instâncias informais, que são aquelas utilizadas para o fluxo informacional
+  de processos informais.
+* Instâncias formalizadoras, que são as instâncias utilizadas para formalizar
+  procedimentos.
+* Instâncias maleáveis, que podem ser utilizadas para agregar informações de
+  processos formais e informais.
+
+Notar que essas distinções não são estritamente excludentes: uma instância pode
+ser utilizada simultaneamente para comunicação informal, para formalizações e
+para agregar informações diversas. Por exemplo, um modo mais simples de lidar
+com as instâncias seja considerar todas as instâncias de comunicação como
+informais ''a priori'' (isto é, se nada mais for dito a respeito da forma de
+cada uma delas) e estabelecer alguns critérios pelos quais determinadas
+instâncias assumem o papel de formalizadoras e/ou maleáveis.
+
+Alem disso, requisições e comunicações ao coletivo (internas ou externas) devem
+ser feitas ao coletivo e não individualmente (isto é, fora da base pessoal),
+tanto para não sobrecarregar pessoas quanto para:
+
+* Manter a informação disponível ao coletivo.
+* Incentivar uma interação coletiva.
+
+Autonomia do Coletivo
+---------------------
+
+O Protocolo de Ação Coletiva define uma autonomia básica para o Coletivo. A
+autonomia básica do Coletivo, isto é, a autonomia mínima que garante a sua
+existência de acordo com estes princípios, é a posse de canais de comunicação
+privados e seguros que permitam a existência dos registros de processos
+coletivos (formais ou informais). Sem esses canais, a autonomia básica do
+Coletivo é seriamente abalada, assim como a aplicação destes princípios. Toda
+autonomia adicional do Coletivo (isto é, que não for a autonomia básica) deve
+ser definida através de processos formais.
+
+Todo o processo formal em realização requer uma autonomia (um poder) em geral
+além da autonomia básica (por exemplo, um recurso necessário para a realização
+do processo). Por isso, ao realizar um processo formal, o grupo de trabalho em
+questão é responsável por manter a autonomia requerida. Portanto, os aumentos e
+diminuições da autonomia do Coletivo apenas ocorrem através de processos
+formais.
+
+O Protocolo de Ação Coletiva reconhece, também, que mesmo um coletivo autônomo
+também possui relações de dependência e trocas com o ambiente externo e que
+esse é um fator importante de interferência na autonomia do Coletivo. O
+Coletivo não produz tudo o que necessita para Si: certos fluxos são
+externalizados (outsourcing, terceirização) de e para o ambiente.
+
+Tal visão de autonomia, inclusive, é compatível e satisfaz os seguintes
+Princípios das mídias e grupos livres do Encontro: Cultura Livre e
+Capitalismo[6], uma vez que a autonomia do Coletivo emana de si enquanto
+organização dinâmica:
+
+    0. Sobre a mobilidade dos princípios: Todos os princípios podem ser a qualquer
+    momento modificados ou abandonados desde que não sejam mais a expressão
+    imanente das relações que se constituem através das ações coletivas. 
+    
+    1. Sobre a autonomia: grupos e mídias livres renunciam e se recusam a recorrer a
+    qualquer entidade política que não a si próprias para constituir sua legalidade
+    e sua normatividade, por acreditar que a sua única fonte legítima é sua
+    emergencia a partir dos laços de confiança e solidarieade entre participantes e
+    de cada participante com os coletivos por eles constituídos.
+    
+    6. Sobre a gestão: As mídias e os grupos livres usam e desenvolvem
+    sistematicamente mecanismos de gestão anti-hierárquicos e baseados na geração
+    de consensos a partir da argumentação pública; ou seja, rejeitam (ou evitam ao
+    máximo), como práticas de organização: a representação política e a votação
+    plebiscitária. A divisão funcional é adotada com ponderação, sob avaliação
+    coletiva e de maneira ocasional. 
+
+Atividade Coletiva Complexa 
+---------------------------
+
+O Protocolo de Ação Coletiva serve para facilitar as atividades do Coletivo,
+combatem a apatia e o espetáculo (no sentido das pessoas se portarem como
+espectadoras, pessoas gerenciadas que permanecem em estado de espera, letárgico
+e apático), o ruído existente nas instâncias de tomada de decisão, a
+dificuldade de acompanhamento dos processos no coletivo e a preenchem a
+necessidade por processos realmente coletivos em andamento (e não apenas as
+iniciativas pessoais).
+
+Os processos formais encorajam um trabalho coletivo firme enquanto que os
+informais encorajam comportamentos pessoais protagonistas que realizem
+discussões e também encontros descompromissados. O Processo de Ação Coletiva
+também ressalta a importância de se utilizar os recursos de comunicação
+coletiva de modo a minimizar o ruído pois isso facilita o acompanhamento dos
+processos.
+
+Quanto ao seu funcionamento, uma analogia interessante pode ser feita com um
+sistema operacional multi-usuário/a, uma vez que o Protocolo de Ação Coletiva
+utiliza o conceito de processo e permite que muitos processos existam
+paralelamente, os quais podem serem até organizados em árvores, de acordo com
+suas semelhanças e/ou dependências.
+
+Memética da auto-organização
+----------------------------
+
+O Protocolo de Ação Coletiva é um fruto da cultura e do choque cultural do
+grupo de afinidade no qual ele se originou. Quando esses princípios de
+organização adentram o plano da cultura das pessoas do Coletivo, isto é, são
+praticados com naturalidade e desenvoltura, então temos uma mudança profunda no
+modo de agir coletivamente. Tal dinâmica pode se suceder indefinidamente
+conforme os princípios antigos se tornam obsoletos.
+
+Como exemplo, deixamos um modelo comportamental possível dentro dos Protocolo
+de Ação Coletiva. Nesse esquema mental, qualquer pessoa do Coletivo pode
+participar nas suas três instâncias informacionais:
+
+* Nas reuniões informais, participando de discussões, bate-papo
+  descompromissado, elaboração de propostas de decisão e ação.
+* Na instância maleável, com a elaboração de relatos, propostas e documentação diversa.
+* Na instância formalizadora, participando das tomadas de decisão.
+
+Ou seja:
+
+* Instância informal: reuniões presenciais ou remotas de caráter mais
+  descomprometido e facilitador da troca de idéia.
+* Instância formalizadora: utilização prioritariamente para os ritos de
+  formalização de processos ou em casos emergenciais.
+* Meio de campo: instância maleável, diminuidora de ruído, podendo ser usada ao
+  máximo para economizar a largura de banda da instância formalizadora.
+
+Esse esquema mental, aliado à distinção entre processos formais e informais,
+sugere um modelo pessoal de entendimento e participação no processo coletivo,
+onde a pessoa pode determinar a melhor maneira de se comunicar e submeter
+propostas, idéias e relatos sem que suas mensagens façam parte de um ruído
+(isto é, excesso de mensagens enviadas aos canais de comunicação) ou caiam num
+processo de formalização muito burocrático sem necessidade.
+
+Com relação às reuniões informais, não há problema de autonomia se as pessoas
+combinarem previamente, avisarem ao Coletivo e depois acrescentarem relatos nos
+canais de comunicação coletivos, já que numa reunião informal nada pode ser
+decidido pelo Coletivo. Inclusive, as reuniões informais, se feitas dessa
+forma, evitam o problema de gastarmos semanas tentando encaixar na agenda de
+todo mundo uma reunião onde no fim das contas aparecem poucas pessoas. Desse
+modo, quando alguém quiser ou sentir que uma reunião é necessária, basta
+combinar com outras pessoas interessadas, comunicar ao Coletivo lista e pronto
+:)
+
+Tal modelo de comportamento, desde que respeite a presente carta de princípios,
+nem precisa ser aprovado pelo coletivo, pois é um modelo de entendimento e
+relacionamento pessoal de como as coisas podem fluir e como processos
+interessantes podem emergir, lembrando que emergência pode ser entendida como
+pequenas regras (ou modelos, esquemas) de comportamento que cada pessoa mantém
+e aplica.
+
+Por fim, a questão da apatia versus o protagonismo. Tal modelo de
+relacionamento proposto só funciona de modo saudável se todas as pessoas forem
+protagonistas, deixando sua apatia e sua preguiça de lado. Caso contrário, ela
+levará a um gerenciamento centralizado nas poucas pessoas que forem ativas.
+Sentiu que uma troca de idéias deve ser feita? Vá, faça, se possível informe a
+lista com antecedência e depois adicione o conteúdo nos canais de comunicação
+coletivos.
+
+Quem não tem iniciativa está destinado/a a ser gerenciado/a e governado/a.
+
+Limitações
+----------
+
+Mesmo que estes princípios sejam úteis e desejáveis para o Coletivo, convém
+reconhecermos suas limitações. Tais princípios assumem que o Coletivo é um
+grupo de afinidade e por isso ele pode enfrentar problemas e necessitar
+modificações se for adotado por grupos onde não haja afinidade, principalmente
+porque sua capacidade de resolução de disputas e conflitos é limitada. O
+circuito de um processo formal também pode ser usado para criar loops e os
+princípios não prevêem em si regras para lidar com o ruído. Talvez eles também
+precisem de adaptações para funcionarem como desejado em grupos muito grandes,
+principalmente porque processos que demandem um fluxo de informação muito
+intenso (por exemplo, propostas grandes) tendem a demandar mais tempo para
+discussão, decisão, etc.
+
+O Protocolo de Ação Coletiva também não dá (e talvez nem devesse mesmo)
+fundamento para lidar com desconexões (saída de pessoas do grupo de afinidade)
+ou rachaduras no grupo. O grande obstáculo para lidar com rachaduras de forma
+transparente é a questão do nome e da aparência pública do Coletivo, o que
+talvez só possa ser resolvido num coletivo com espaço de nomes múltiplo. Como,
+no entanto, o Protocolo de Ação Coletiva não foi criado para lidar exatamente
+com desconexões e rachaduras, esses fluxos disjuntivos foram deixados de lado,
+ao menos temporariamente.
+
+Algo mais deve ser lembrado: estes princípios não definem os objetivos do
+Coletivo e nem garantem que atividades sejam realizadas. Esta declaração de
+princípios apenas diz como a energia pode ser gasta no Coletivo, isto é, dado
+um potencial, um desejo de agir, como a energia pode fluir dentro do Coletivo.
+O propósito, a vontade e o potencial de agir são sempre externos aos princípios
+de organização coletiva e ao Protocolo de Ação Coletiva.
+
+Em direção a muitos protocolos de rede
+--------------------------------------
+
+A organização parece uma necessidade, algo crucial[7], ao passo que parece
+inesgotável a quantidade de formas de organização possíveis. Em outras
+palavras, se a organização é importante, os modos de se obtê-la podem não ser
+tão óbvios.
+
+A questão mais geral de como um grupo de pessoas pode se organizar melhor para
+atender seus objetivos e lidar com os problemas que surgem pela própria
+organização pode nos levar inclusive a uma análise um pouco mais profunda da
+natureza não apenas do Protocolo de Ação Coletiva apresentado como de todo um
+conjunto de protocolos que satisfaçam uma dada coletividade.
+
+Historicamente, dentre as formas de organização igualitárias e de democracia
+direta, destacam-se as federações, inventadas pelos movimentos sociais nos
+últimos séculos e redes abertas, formas recentes criadas nos últimos anos com o
+adventos das modernas técnicas de comunicação e com novos desafios para
+organização encontrados pelos movimentos.
+
+Muitas vezes federações e redes abertas são colocadas em polos opostos dadas
+suas diferenças muitas vezes irreconciliáveis. Se é difícil dar um nome à
+relação entre essas duas formas de organização, por outro lado elas não parecem
+ser exatamente opostas, mas dialógicas. Algo que talvez possa generalizar tal
+relação seja a noção de protocolo. Protocolos não apenas lidam com o fluxo de
+informação, matéria e energia entre nós/grupos de uma rede, mas também podem
+lidar com o processo de conexão e desconexão.
+
+O modelo federativo auxilia muito no processo de decisão e responsabilização,
+enquanto que o modelo das redes abertas impulsiona a emergência de padrões
+complexos. Enquanto é mais difícil observar emergências em federações do que em
+redes abertas, o oposto ocorre quando se tenta tomar uma decisão. Uma rede
+aberta dificilmente realiza uma decisão que não faça parte do seu protocolo.
+
+Portanto, federações tendem a ser uma melhor opção nos momentos em que
+seus/suas participantes precisam decidir sobre o uso e o acesso a um bem ou
+recurso rival, isto é, quando há uma necessidade de dirigir um bem
+rival/excludente a um dado uso. Por outro lado, redes abertas existem
+usualmente em locais onde pessoas e grupos lidam basicamente com bens
+não-rivais (principalmente informação).
+
+Consideremos, ao invés dos conceitos de federação e redes abertas, conceitos
+como formalidade, informalidade e protocol. Um procotolo seria um conjunto de
+regras (definidas ou indefinidas) usadas para dar topologia (forma) a uma rede,
+lidando com suas conexões, desconexões, fluxo informacional, tomada de decisão,
+etc.
+
+A formalidade e a informalidade concernem ao conjunto de regras predefinidas
+num dado protocolo: no caso de uma rede aberta, regras usualmente não existem a
+priori e emergem as poucos num modo informal conforme o protocolo é atualizado
+dinamicamente, enquanto que federações tipicamente começam com um conjunto de
+regras acordadas de antemão.
+
+Como regras acordadas antes da instanciação de uma regra representam um
+entendimento comum das possibilidades e autonomia de casa uma das partes
+envolvidas no acordo, elas são mais propícias para lidarem com ben/recursos
+rivais/exclusionários. Mas, por precederam a atual experiência da rede, elas
+podem carecer de características necessárias para lidam com padrões emergentes
+de organização, especialmente à manipulação de bens não-rivais, algo muito bem
+obtido com processos informais.
+
+Muitos grupos são complexos o suficiente para lidaram tanto com bens e recursos
+rivais quanto não-rivais mas também com questões importantes como segurança,
+privacidade e confiança. Por isso, provavelmente muitos grupos precisarão de
+protocolos híbridos que lidem ao mesmo tempo com a formalidade e a
+informalidade.
+
+Ter um processo não significa ter um monte de regras desnecessárias, mas sim um
+pequeno conjunto de regras (um protocolo) para lidar com um processo de tomada
+de decisão acerca de bens e recursos rivais, com a segurança e a privacidade,
+podendo deixar os bens não-rivais se formarem de acordo com a experiência.
+
+Para criar protocolos sociais, portanto, as seguintes perguntas podem ser de
+grande valia:
+
+1. Quais são os bens e recursos rivais a serem compartilhados pelo grupo?
+2. Quais são os requisitos de segurança, privacidade e confiança no grupo?
+3. Quais são os requisitos de administração da informação (canais de
+   comunicação e documentação)?
+
+Respostas práticas a essas questões permitem o esboço de um protocolo (ou
+conjunto de protocolos):
+
+1. Para a questão 1, o protocolo pode se dirigir ao processo de tomada de
+   decisões.
+2. Para a questão 2, o protocolo pode estabelecer um esquema de controle de
+   acesso à informação.
+3. Para a questão 3, o protocolo pode sugerir um fluxo informacional padrão que
+   auxilie na comunicação, na documentação (memória) e eventualmente até nos
+   critérios de distribuição de informação para entidades externas (licenciamento
+   de conteúdo).
+
+Protocolos híbridos, além de serem compatíveis simultaneamente com processos
+formais e informais, são também propícios para se fazer um bom uso de recursos
+limitados (trabalho, energia, matéria, etc. Bons protocolos híbridos fazem um
+balanço entre formalidade (um conjunto excessivo de regras tende a ser
+burocrático) e informalidade e auxiliam aos grupos acumularem mais excedente
+com menos trabalho.
+
+Além disso, pode ser conveniente balizar a criação de protocolos levando em
+conta o princípio do não-preconcebimento, que afirma que ''nada que foi
+explicitamente informado ou acordado deve ser considerado ou assumido''. Por
+exemplo se alguém não informou que está realizando uma dada atividade, então
+não há condições suficientes para se considerar que essa pessoa a está
+realizando.
+
+Ou seja, a iniciativa só deve ser considerada se houver disponibilidade de
+informação. Até pode acontecer que alguém que não informou que esteja
+trabalhando na verdade esteja, mas pela inexistência dessa informação não
+podemos nos arriscar a considerá-lo.
+
+A urgência e a emergência da organização
+----------------------------------------
+
+Um dado "nível" de organização/acumulação permite inclusive tornar situações
+antes emergenciais em procedimentos bem estabelecidos. Por isso, um grupo que
+se dedica à sua organização terá um ganho futuro de lidar melhor com situações
+que hoje são urgentes. Se o grupo apenas se dedicar a apagar o fogo, a resolver
+emergências/urgências, não terá tempo para mudar e melhorar sua organização.
+Certamente o mundo apresenta uma série de situações emergenciais. A urgência
+permeia a existência.
+
+Não é possível não se omitir em todas as lutas, em todas as frentes, em todas
+as tarefas. Há uma rivalidade de atuação porque os grupos não são ilimitados. A
+energia das sociedades humanas não escala indefinidamente, ao menos atualmente,
+apesar de ser possível para um grupo ao menos apoiar -- nem que seja uma
+declaração de apoio -- múltiplas causas, mas escolhas precisam ser feitas.
+
+Por isso, é importante para um grupo dividir bem sua dedicação, seu tempo e seu
+esforço não apenas para todas as emergências, mas também para a sua
+organização. Às vezes é preciso dar um basta à resolução de emergências e
+dedicar um pouco do tempo à organização. Ao se organizar mais, a resolução de
+algumas emergências podem se tornar tarefas mais fácil.
+
+Referências
+-----------
+
+* [1] Licença de Manipulação de Informações do Grupo Saravá: http://wiki.sarava.org/Main/Licenca
+* [2] Protocolo de Ação Coletiva, http://protocolos.sarava.org/trac/wiki/Organizacao
+* [3] A tirania das organizações sem estrutura: http://www.midiaindependente.org/pt/blue/2001/07/3257.shtml
+* [4] O registro também pode ser entendido tanto como memória coletiva como superfície de inscrição do corpo coletivo. O registro é a memória da autogestão coletiva.
+* [5] Existiriam paralelos ou mesmo identidades com os conceitos de máquinas desejantes, fluxo de produção, superfície de inscrição e corpo sem órgãos? Estaria então o desarranjo também inserido nesse princípio de funcionamento? Deixamos estas questões em aberto.
+* [6] Os princípios das mídias e grupos livres - http://encontro.sarava.org/Principal/ConjuntoDePrincipiosEticos.
+* [7] Veja, por exemplo, o texto A Organização II - Errico Malatesta - 11 de julho de 1897, http://nucleos-fasp.blogspot.com/2008/08/organizao-ii-errico-malatesta-11-de.html
diff --git a/docs/social/coletivo/misc.md b/docs/social/coletivo/misc.md
new file mode 100644
index 0000000..1c9323a
--- /dev/null
+++ b/docs/social/coletivo/misc.md
@@ -0,0 +1 @@
+# Misc
diff --git a/docs/social/coletivo/misc/ata.md b/docs/social/coletivo/misc/ata.md
new file mode 100644
index 0000000..667a34f
--- /dev/null
+++ b/docs/social/coletivo/misc/ata.md
@@ -0,0 +1,22 @@
+# Ata de reunião

+

+# Reunião de ../../....

+

+  * Horário: ..:..

+  * Local: ... (Cidade).

+  * Caráter: ...

+  * Presentes: ...

+

+# Ata

+

+## Informes

+

+...

+

+## Próximas reuniões

+

+...

+

+## Outras questões

+

+...

diff --git a/docs/social/coletivo/misc/atualizacao.md b/docs/social/coletivo/misc/atualizacao.md
new file mode 100644
index 0000000..78a3463
--- /dev/null
+++ b/docs/social/coletivo/misc/atualizacao.md
@@ -0,0 +1,32 @@
+# Atualização de processo

+

+O presente processo efetua a atualização do seguinte processo:

+

+  * `$processo`

+

+O novo texto para o processo é o seguinte:

+

+    $novo_texto

+

+Condições de atualização

+------------------------

+

+* O processo só pode ser atualizado se as pessoas responsabilizadas pelo mesmo

+  concordarem explicitamente com isso. Caso elas não concordem este processo

+  deve ser arquivado.

+* No ticket do processo deve haver uma menção à atualização efetuada e com

+  referência ao processo que o alterou.

+

+Responsabilização

+-----------------

+

+As pessoas responsáveis pelo presente processo devem efetivar a atualização do

+processo de acordo com as condições mencionadas anteriormente.

+

+Sobre este texto

+----------------

+

+O texto deste processo foi redigido utilizando o [Template para Atualização de

+Processo](/organizacao/misc/atualizacao). No caso de alterações que não dizem

+respeito apenas ao Grupo e que possam enriquecer tal template, favor

+submetê-las também upstream, isto é, ao texto do template. 

diff --git a/docs/social/coletivo/misc/autorizacao.md b/docs/social/coletivo/misc/autorizacao.md
new file mode 100644
index 0000000..33cf236
--- /dev/null
+++ b/docs/social/coletivo/misc/autorizacao.md
@@ -0,0 +1,34 @@
+# Template para Autorização de Uso de Conteúdo

+

+Por este processo, `$entidade` fica autorizada a utilizar os seguintes conteúdos do Coletivo:

+

+1. `$conteudo`

+

+Com as seguintes permissões:

+

+1. Distribuição do conteúdo nos seguintes meios:

+ a. Digital.

+ b. Impresso.

+ c. Audiovisual.

+2. Alteração do conteúdo mediante inclusão de nota descrevendo as mudanças efetuadas.

+3. Vigente para versões anteriores e futuras do conteúdo.

+

+Com as seguintes restrições:

+

+1. Impedido o uso comercial ou fins lucrativos.

+2. A preservação da licença original do conteúdo.

+3. Uso restrito apenas para a publicação intitulada `$publicacao`.

+4. A validade desta permissão é de `$validade`, podendo ou não ser renovada.

+

+# Dependências

+

+A realização deste processo depende da realização dos seguintes processos:

+

+* [Licenciamento de informações](/organizacao/license).

+

+# Sobre este texto

+

+O texto deste processo foi redigido utilizando o [Template para Autorização de

+Uso de Conteúdo/organizacao/misc/autorizacao]. No caso de alterações que não

+dizem respeito apenas ao Grupo e que possam enriquecer tal template, favor

+submetê-las também upstream, isto é, ao texto do template.

diff --git a/docs/social/coletivo/misc/debate.md b/docs/social/coletivo/misc/debate.md
new file mode 100644
index 0000000..59f414c
--- /dev/null
+++ b/docs/social/coletivo/misc/debate.md
@@ -0,0 +1,33 @@
+# Debate

+

+Realização de um debate no `$local` ou em outro lugar conveniente (mas não pago

+e nem corporativo), eventualmente em parceria com o `$grupo`, de um debate

+sobre `$tema`. O evento seria oficialmente organizado pelo Coletivo e talvez

+pelo `$grupo` (caso topem) e portanto se trata de um processo formal.

+

+Tal evento é politicamente interessante ao Coletivo ao marcar presença no

+`$local`, além de preencher uma lacuna pela falta de debates sobre o assunto.

+

+As tarefas envolvidas são:

+

+* Marcar uma boa data.

+* Reservar o `$local` ou local apropriado, juntamente equipamento necessário.

+* Convidar palestrantes que entendam do assunto e possuam visão crítica.

+* Fazer, imprimir e afixar cartazes em locais chaves.

+* Divulgação pela internet e eventualmente pelo Portal do Coletivo.

+* Realizar o debate, fazendo a mediação se necessário.

+

+Observações:

+

+* O debate não terá o apoio de organizações corporativas ou estatais e não

+  contará com financiamento.

+* As pessoas do Coletivo que estiverem presentes na mesa não falarão em nome do

+  Coletivo.

+

+Sobre este texto

+----------------

+

+O texto deste processo foi redigido utilizando o [Template para

+Debate](/organizacao/misc/debate). No caso de alterações que não dizem respeito

+apenas ao Grupo e que possam enriquecer tal template, favor submetê-las também

+upstream, isto é, ao texto do template.

diff --git a/docs/social/coletivo/misc/grupos.md b/docs/social/coletivo/misc/grupos.md
new file mode 100644
index 0000000..6546851
--- /dev/null
+++ b/docs/social/coletivo/misc/grupos.md
@@ -0,0 +1,92 @@
+# Participação no $grupo

+

+Este processo estabelece a participação do Coletivo no $grupo, doravante

+mencionado neste texto tanto como $grupo ou simplesmente como '''Grupo'''.

+

+# Descrição do Grupo

+

+A descrever.

+

+# Informações de contato e comunicação

+

+A descrever.

+

+# Critérios de privacidade e segurança do Grupo

+

+A descrever.

+

+# Descrição das tarefas relacionadas

+

+Considerando que:

+

+1. Não se pode assumir que todas as pessoas do Coletivo estejam participando

+   ativamente do Grupo e que

+2. O Coletivo precisa discutir, propor e emitir posições acerca de questões relativas ao Grupo.

+

+As tarefas para a participação no Grupo consistem em:

+

+1. Levar do Grupo para o Coletivo as questões a serem discutidas, decididas

+   e/ou que sejam de interesse do Coletivo ou de pessoas do Coletivo, documentando

+   na medida do possível os processos relacionados nas instâncias e seções

+   correpondentes do Coletivo usadas para tais fins.

+

+2. Levar do Coletivo para o Grupo as propostas, discussões, sugestões e

+   posicionamentos que partirem do Coletivo e cujo envio estiver aprovado,

+   documentando na medida do possível os processos relacionados nas instâncias e

+   seções correpondentes do Grupo usadas para tais fins.

+

+3. Providenciar ao Coletivo ou à pessoas do Coletivo informações disponíveis no

+   Grupo mediante requisição da parte interessada.

+

+# Responsabilização

+

+Em todos os casos, as pessoas responsabilizadas:

+

+1. Se comunicarão do Grupo para o Coletivo (e vice-versa) observando os

+   critérios de privacidade segurança do Coletivo e do Grupo.

+

+2. Informarão explicitamente, caso estejam repassando informações que o

+   Coletivo envia para o Grupo, que tais informações representam uma comunicação

+   oficial e formal do Coletivo. Nos demais casos, recomenda-se que as pessoas

+   responsáveis informem explicitamente que estão se comunicando informalmente

+   e/ou que a comunicação não representa a posição do Coletivo.

+

+3. Realizarão, na medida do possível, a tradução de comunicação de e para o

+   português, nos casos em que a mesma precise ser realizada noutro idioma.

+

+Cabe ainda observar que:

+

+1. As pessoas responsáveis por tal comunicação entre o Coletivo e o Grupo são

+   denominadas de ''[http://en.wikipedia.org/wiki/Liaison liaisons]'' entre o

+   Coletivo e o Grupo, podendo atuar também como

+   ''[http://en.wikipedia.org/wiki/Proxy proxies]'' para pessoas do Coletivo, isto

+   é, enviar informações para o Grupo oriundas de pessoas do Coletivo que não

+   queiram se identificar.

+

+2. Cabe aos/às ''liaisons'' dividirem entre si se organizarem para dividir as

+   tarefas relativas ao acompanhamento e repasse de informações do Coletivo para o

+   Grupo e vice-versa.

+

+3. Oas/as '''liasons''' respeitarão e observarão os critérios, regras e

+   sugestões de conduta, comunicação e etiqueta tanto do Grupo quando do Coletivo.

+

+# Compartilhamento de informações

+

+Caso o Grupo mantenha comunicações em outros idiomas que não o português, é

+possível ainda compartilhar informações sobre o Grupo que não sejam

+específicas/internas do Coletivo entre outros grupos lusófonos/brasileiros que

+também estão no Grupo, desde que isso seja feito atendendo os critérios de

+segurança e privacidade do Grupo e do Coletivo.

+

+Além disso, tal repasse de informações:

+

+1. Não é de responsabilidade dos/as ''liaisons''.

+2. Precisa de autorização do Coletivo.

+

+# Sobre este texto

+

+O texto deste processo foi redigido utilizando o

+[wiki:PageTemplates/ParticipacaoEmGruposExternos Template para Participação em

+Grupos Externos]. No caso de alterações que não dizem respeito apenas ao Grupo

+e que possam enriquecer tal template, favor submetê-las também ''upstream'',

+isto é, ao texto do template.

diff --git a/docs/social/coletivo/misc/rollcall.md b/docs/social/coletivo/misc/rollcall.md
new file mode 100644
index 0000000..209d775
--- /dev/null
+++ b/docs/social/coletivo/misc/rollcall.md
@@ -0,0 +1,25 @@
+# Rodada de Chamadas

+

+A Rodada de Chamadas, também conhecida como

+[http://en.wikipedia.org/wiki/Roll_call roll call], é um procedimento utilizado

+para saber quem ainda participa de um grupo. Em cada rodada, das pessoas

+ausentes nas atividades do Coletivo, apenas aquelas que responderem permanecem

+no grupo conforme o [Processo de participação no

+Coletivo](/organizacao/coletiva/participacao).

+

+# Chamado

+

+As pessoas envolvidas no Coletivo que estiverem ausentes das atividades do

+Coletivo tem o período entre o início e o término da realização do processo

+para se pronunciarem a respeito da sua permanência no Coletivo, caso contrário

+estarão passíveis de retirada do Coletivo.

+

+Esta também pode ser considerada como uma oportunidade para as pessoas

+apresentarem suas atividades e seus anseios. :)

+

+# Sobre este texto

+

+O texto deste processo foi redigido utilizando o [Template para Rodada de

+Chamadas](/organizacao/misc/rollcall). No caso de alterações que não dizem

+respeito apenas ao Grupo e que possam enriquecer tal template, favor

+submetê-las também upstream, isto é, ao texto do template. 

diff --git a/docs/social/coletivo/organizacao.md b/docs/social/coletivo/organizacao.md
new file mode 100644
index 0000000..5efaf54
--- /dev/null
+++ b/docs/social/coletivo/organizacao.md
@@ -0,0 +1,198 @@
+# Protocolo de Ação Coletiva
+
+Possíveis interpretações sobre o significado e o efeito deste protocolo se
+encontram [aqui](/organizacao/coletiva/interpretacoes).
+
+* Versão: 1.0.
+* Licença: LIMICS[1].
+* Protocolos apresentados neste projeto podem ser aplicados através do esquema
+  de "processos formais" definidos neste documento, o que inclui até mesmo o
+  presente protocolo.
+
+Processos e autonomia
+---------------------
+
+Tudo o que ocorre no Coletivo é um processo. Os processos assumem diversas
+manifestações, mas principalmente são fluxos e registros desses fluxos
+(memória/informação).
+
+Existem dois tipos de processos:
+
+* Processos formais
+    * Forma necessariamente definida de antemão via consenso do coletivo E
+    * Lidam com a autonomia do coletivo. PORTANTO
+    * Precisam ser acompanhados pela responsabilização mínima para o processo não
+      falhar por falta de iniciativa
+
+* Processos informais
+    * Forma não necessariamente definida de antemão E
+    * Não afetam a autonomia do coletivo. PORTANTO
+    * Não precisam necessariamente estar atrelados à responsabilidade de alguém
+      (isto é, a não-realização de um processo informal não afeta a autonomia do
+      Coletivo)
+
+Atividades sem informação disponibilizada no Coletivo não podem ser
+consideradas como processos (formais ou informais) do Coletivo porque não
+dispõem de igualdade de acesso à informação, requisito para a possibilidade de
+participação (isonomia informacional).
+
+A autonomia básica do Coletivo, isto é, a autonomia mínima que garante a sua
+existência de acordo com este protocolo, é a posse de canais (instâncias) de
+comunicação privados e seguros que permitam a existência dos registros de
+processos coletivos (formais ou informais). Sem esses canais, a autonomia
+básica do Coletivo é seriamente abalada, assim como a aplicação deste
+protocolo. Toda autonomia adicional do Coletivo (isto é, que não for a
+autonomia básica) deve ser definida através de processos formais.
+
+Um/a integrante do Coletivo atua dentro dele quando utiliza os recursos e o
+nome do Coletivo. Por outro lado, um/a integrante do Coletivo atua fora dele
+quando não utiliza os recursos ou o nome do Coletivo. Intregrantes do Coletivo
+não realizam ações (dentro ou fora do Coletivo) que, conscientemente, possam
+prejudicar a autonomia do Coletivo.
+
+Processos Formais
+-----------------
+
+Os processos formais possuem as etapas e os andamentos de acordo com o
+fluxograma a seguir:
+
+         .------------------->-----------------.
+        /  .----------<--------------<-------.  \
+       |  '                                   \  \
+       |  |               .------>-----.       \  \
+       |  |              |              \       \  \
+      Proposta -----> Discussão ->--.    \       \  \
+         |  ^            |           \    \       \  \
+         |  |            |            \    \       \  \
+         |   `----<-----'             |     \       \  \
+         |                            |      |       \  \
+          `------>------ Decisão --<--'      |        \  \
+                           | |               |         \  \
+                           | |               |          | |
+       Atribuição de --<---' '---> Arquivamento --->---'  ;
+     Responsabilidades ----->-------'   ^    \           /
+          ^  |              ___________/      `---<-----'
+          |   \           .'
+          |    `--> Realização -->--.
+          |           |  |           \
+          |           |  |           /
+           `----<-----'   `-----<---'
+
+* Proposta: etapa na qual a idéia de um procedimento formal é lançado ao
+  Coletivo. A idéia -- ou descrição -- do processo pode vir do Arquivo de
+  propostas, de uma Discussão anterior, de um procedimento informal que se
+  julga importante formalizar ou mesmo de uma pessoa ou grupo de pessoas de
+  dentro ou de fora do Coletivo. Recomenda-se que ela seja bem explicada e
+  contenha: sugestão de prazo de decisão, ciclo de vida do processo, critérios
+  e prazo para atribuição de responsabilidade assim como recomendações para
+  situações emergenciais (quando aplicável).
+
+* Discussão:
+    * Não é uma etapa estritamente necessária, mas não deixa de ter importância.
+    * Alterações em propostas fazem com que o procedimento formal em questão
+      volte para a etapa de Proposta. Propostas que não seguirem para a etapa de
+      Decisão ou que não forem alteradas até o prazo proposto devem ser
+      arquivadas.
+    * Propostas que vem de fora do Coletivo ou que tenham como participantes
+      grupos ou pessoas de fora do coletivo e que forem discutidas e alteradas
+      devem ser enviadas também para o grupo ou à pessoa de fora do Coletivo
+      responsável pela sua introdução, apesar destas pessoas não participarem
+      da discussão interna do Coletivo. Se tal pessoa ou grupo concordar com a
+      proposta alterada, então o processo formal em questão retorna à etapa de
+      Discussão com a nova proposta. Caso contrário, isto é, a pessoa ou grupo
+      de fora do Coletivo não concordar com a proposta alterada, então o
+      processo formal em questão é arquivado (exceto se as partes externas
+      apresentarem uma nova alteração à proposta ou mais argumentos à
+      discussão).
+
+* Decisão:
+    * Via consenso e a participação ativa depende do acompanhamento das
+      informações do Coletivo requeridas pela proposta em questão.
+    * Se não há consenso sobre a aprovação de uma proposta, a mesma permanece
+      bloqueada, podendo ter seu prazo estendido.
+    * São considerados dois caminhos possíveis para a tomada de decisão caso
+      haja silêncio. Cada uma delas tem vantagens e desvantagens e pode depender
+      do contexto do Coletivo. Recomenda-se que a opção escolhida seja pactuada
+      explicitamente por todas e todos participantes logo na adoção deste Protocolo:
+        * Opção 1: "quem cala não consente", isto é, aprovação somente com
+          consenso explícito não-silencioso; neste caso, é considerado por
+          padrão que ninguém topa participar ou concorda com a proposta.
+        * Opção 2: manter-se em silêncio é considerado como concordância com a
+          proposta em questão.
+    * Prazo: recomenda-se que os mesmos sejam estipulados relativamente ao
+      tempo que as pessoas ativas no coletivo tomarem conhecimento, discutir,
+      propor alterações, pedirem eventuais adiamentos, etc, sendo passíveis de
+      prorrogação ou antecipação através de um pedido explícito por alguma
+      pessoa do Coletivo. No entanto, se não há pedido para alteração de prazo,
+      a data inicial da proposta deve ser respeitada.
+    * Aprovações de propostas que vem de fora do Coletivo ou que tenham como
+      participantes grupos ou pessoas de fora do coletivo são comunicadas às
+      pessoas/grupos de fora do Coletivo apenas após a atribuição de
+      responsabilidades.
+
+* Atribuição de Responsabilidades:
+    * Minimização de pontos de falha.
+    * Responsabilização voluntária, mas que exige envio de termo de
+      comprometimento/responsabilização afirmando que:
+        * Tem conhecimento sobre o procedimento em questão.
+        * Irá realizá-lo dentro do prazo estipulado, que manterá o Coletivo
+          informado sobre a sua realização.
+        * Caso não possa mais arcar com a responsabilidade, avisará o Coletivo
+          com antecedência suficiente para que o mesmo possa, dependendo do
+          caso, manter a realização do processo, atribuir novas
+          responsabilidades a ele ou então simplesmente encerrá-lo e
+          arquivá-lo.
+    * O não-cumprimento de uma responsabilidade compromete a atribuição de
+      outras responsabilidades. Além disso, a atribuição de uma
+      responsabilidade é voluntária e deve ser feita por escrito para fins de
+      documentação e para evitar mal-entendidos e problemas de comunicação.
+    * Processos formais que forem aprovados mas que, findo o prazo para a
+      responsabilização, não tiverem responsabilização suficiente atribuída,
+      devem seguir para o arquivamento, sendo que o desarquivamento de
+      propostas anteriormente aprovadas não pode seguir diretamente para a
+      atribuição de responsabilidade, mas sim seguir para a etapa de
+      proposição.
+    * No caso de propostas que vem de fora do Coletivo ou que tenham como
+      participantes grupos ou pessoas de fora do coletivo são comunicadas às
+      pessoas/grupos de fora do Coletivo sobre seu estado de
+      Aprovação/Realização apenas após a atribuição de responsabilidade, isto
+      é, ao final desta etapa.
+
+* Realização:
+    * Apenas processos formais cuja responsabilização foi atribuída podem partir
+      para a etapa de realização. Processos que forem realizados e que não
+      tiverem prosseguimento definido são arquivados.
+    * Processos formais que, não tendo sido realizados no prazo comprometido pelo
+      grupo das pessoas que se responsabilizaram por ele, devem retornar à etapa
+      de Atribuição de Responsabilidades. De modo análogo, processos em
+      realização mas cujos/as responsáveis não puderem mais realizá-los devem
+      retornar à etapa de Atribuição de Responsabilidades caso o número de
+      pessoas responsáveis remanescentes não for suficiente para a sua
+      realização.
+
+* Arquivamento:
+    * Propostas que:
+        * Foram aprovadas mas não foram adotadas responsavelmente OU
+        * Foram realizadas e encerradas OU
+        * Estavam em realização mas não tem mais o número de pessoas
+          responsáveis suficiente, por exemplo: quando ninguém ou apenas um
+          número insuficiente de pessoas estiverem cuidando de um dado recurso.
+    * No caso de um processo que estava sendo realizado e precisar ser
+      arquivado por falta de pessoas responsáveis por ele, as últimas pessoas
+      responsáveis por ele devem realizar o procedimento de encerramento e
+      arquivamento.
+    * No caso de propostas que vem de fora do Coletivo ou que tenham como
+      participantes grupos ou pessoas de fora do coletivo são comunicadas às
+      pessoas/grupos de fora do Coletivo sobre seu estado Recusa/Arquivamento
+      apenas nesta etapa.
+
+## Dependências entre processos
+
+1. Processos formais que explícita ou implicitamente dependam de outros
+   processos formais podem ter vínculo de dependência estabelecido.
+2. Processos formais em realização cujas dependências se encontrarem arquivadas
+   são passíveis de arquivamento.
+
+## Referências
+
+* [1] Licença de Manipulação de Informações do Grupo Saravá - http://sarava.fluxo.info/Main/Licenca
diff --git a/docs/social/coletivo/participacao.md b/docs/social/coletivo/participacao.md
new file mode 100644
index 0000000..b4846a2
--- /dev/null
+++ b/docs/social/coletivo/participacao.md
@@ -0,0 +1,105 @@
+# Participação de pessoas no Coletivo
+
+O presente processo trata da Entrada e saída de pessoas no Coletivo,
+estabelecendo assim a participação de pessoas no Coletivo no nível 3 de
+[ACL](/coletivo/comunicacao/acl).
+
+Participação de pessoas
+-----------------------
+
+A participação de cada pessoa no nível 3 de ACL deve ser dar através de um processo formal, onde:
+
+1. Nas etapas de proposta e discussão da participação deve ocorrer a
+   aproximação da pessoa com o Coletivo.
+2. A etapa de realização do processo está dividida nas seguintes fases:
+  a. Entrada tipo "trainee".
+  b. Participação efetiva.
+  c. Saída/afastamento, quando o processo de participação da pessoa no nível
+     ACL 3 é arquivado, podendo ser desarquivado no futuro.
+
+Aproximação com o Coletivo
+--------------------------
+
+Nesta etapa, a pessoa e o Coletivo procuram se aproximar e se conhecer e ambos
+avaliam a vontade de prosseguir com a participação.
+
+Entrada de treinamento
+----------------------
+
+Caso haja prosseguimento do processo, a pessoa passa por um período de
+experiência e treinamento, onde:
+
+1. Toma conhecimento do funcionamento e das atividades do Coletivo.
+2. É auxiliada por alguma pessoa do Coletivo que se voluntaria de guia.
+3. Aprende a utilizar os instrumentos técnológicos básicos do Coletivo.
+
+Mas que:
+
+1. Não tem acesso a chaves, senhas ou contas em camadas do Coletivo.
+
+Antes de entrar no período de participação, a pessoa precisa concordar
+explicitamente que respeitará:
+
+1. Os processos do Coletivo.
+2. O sigilo e a privacidade do Coletivo, mesmo no caso de deixar de participar
+   do mesmo.
+
+A fase de treinamento se encerra quando a pessoa sentir que já pode participar
+efetivamente do Coletivo.
+
+Participação efetiva
+--------------------
+
+Após passar pelo período de treinamento, a pessoa se integrará efetivamente no
+Coletivo, podendo assumir responsabilidades e ter acesso a todas as camadas e
+interfaces do Coletivo.
+
+Para que continue com tal participação, um mínimo de comprometimento é
+necessário
+
+1. Ter ciência do que aconteceu nos últimos tempos dentro do Coletivo.
+2. Participar de alguma forma nas discussões do Coletivo.
+3. Caso não possa arcar com 1 ou 2, deve ao menos responder nos processos de
+   [roll call](/organizacao/misc/rollcall).
+
+Critérios de segurança
+----------------------
+
+Levando em conta que o Coletivo abriga informações de muita gente, é importante
+que exista um nível de segurança mais alto do que a média):
+
+1. Ter a pasta pessoal e área de troca (swap) criptografadas.
+2. Utilizar senhas seguras.
+3. Utilizar criptografia GPG.
+4. Verificar fingerprints em servidores, etc.
+5. Demais [recomendações](/organizacao/comunicacao/infosec).
+
+Privacidade
+-----------
+
+É uma escolha de cada participante se manter como membro privado ou mencionar
+que faz parte do Coletivo, seja publicamente ou em círculos restritos.
+
+Congelamento e término de participação
+--------------------------------------
+
+Nos casos de problemas pessoais, o Coletivo pode, mediante processo formal,
+congelar temporariamente a participação de alguma pessoa no Coletivo.
+
+No caso de congelamento ou término de participação, a pessoa perde os acessos
+às camadas e interface de ACL 3 do Coletivo.
+
+Responsabilização
+-----------------
+
+O Grupo de Trabalho formado pelas pessoas responsáveis pelo presente processo
+fica encarregado de zelar pela aplicabilidade do presente processo e de
+certificar que os acessos às interfaces e camadas das pessoas que se desligarem
+ou se afastarem do Coletivo sejam removidos.
+
+Retroatividade
+--------------
+
+O presente processo é retroativo, isto é, mesmo quem já participa do Coletivo
+antes da vigência do processo precisa passar por ele, por uma questão de
+isonomia.
diff --git a/docs/social/coletivo/responsabilizacao.md b/docs/social/coletivo/responsabilizacao.md
new file mode 100644
index 0000000..168b9b5
--- /dev/null
+++ b/docs/social/coletivo/responsabilizacao.md
@@ -0,0 +1,15 @@
+# Termo de responsabilização
+
+    Me compromento a me responsabilizar pela realização da tarefa/processo X
+    de acordo com os termos indicados na descrição da tarefa/processo e
+    mantendo o coletivo informado do seu andamento.
+
+    Caso não possa mais manter minha responsabilização, me comprometo a
+    informar o coletivo com antecedência.
+
+    No caso do encerramento da minha responsabilização acarretar numa
+    responsabilidade mínima menor do que aquela especificada pela tarefa/processo,
+    me comprometo também e a passá-la para frente ou, na ausência de pessoas
+    que componham a responsabilidade mínima, me comprometo a arquivar a
+    tarefa/processo, levando em conta os procedimentos específicos para
+    o caso.
diff --git a/docs/social/etica.md b/docs/social/etica.md
new file mode 100644
index 0000000..79b1759
--- /dev/null
+++ b/docs/social/etica.md
@@ -0,0 +1,155 @@
+# Conjunto de Princípios Éticos
+
+Baseado nos [princípios das mídias e grupos livres](https://encontro.fluxo.info/Principal/ConjuntoDePrincipiosEticos).
+
+0. Sobre a mobilidade dos princípios: Todos os princípios podem ser a qualquer
+momento modificados ou abandonados desde que não sejam mais a expressão
+imanente das relações que se constituem através das ações coletivas.
+
+1. Sobre a autonomia: grupos e mídias livres renunciam e se recusam a recorrer
+a qualquer entidade política que não a si próprias para constituir sua
+legalidade e sua normatividade, por acreditar que a sua única fonte legítima é
+sua emergencia a partir dos laços de confiança e solidarieade entre
+participantes e de cada participante com os coletivos por eles constituídos.
+ 
+2. Sobre a apropriação pública: As mídias e os grupos livres defendem e
+promovem a apropriação pública dos meios de produção (rejeita a sua apropriação
+privada) e, em específico dos meios de produção de bens simbólicos e culturais
+e aos produtos do trabalho intelectual e imaterial.
+
+3. Sobre o licenciamento: As mídias e os grupos livres usam licenciamento
+livre, apoiam explicitamente os novos direitos autorais e consideram
+especialmente inaceitável a apropriação privada do trabalho intelectual /
+imaterial. aqui, bem que podia aparecer alguma vinculação das licenças com
+propostas de escambo, economia solidária, moeadas locais, permacultura,
+comércio justo... tipo: inventar uma licença que permitisse a circulação em
+sistemas de mercado não-capitalistas. Talvez, exigindo para isso o
+consentimento (tácito?) dos envolvidos
+
+4. Sobre o acesso público: As mídias e os grupos livres criam plataformas de
+comunicação mediática e espaços simbólicos de acesso público em que se rejeita
+absolutamente a monopolização vertical da produção mediática; embora
+estabeleçam princípios éticos e políticos para o acesso aos suportes, não há
+controle sobre a produção de "conteúdo", permitindo que uma pluralidade de
+organizações possam se utilizar dos mesmos canais de comunicação.
+
+5. Sobre a diversidade: As mídias e os grupos livres visam aumentar a
+diversidade dos pontos de vista e estimular o debate argumentativo, recusa
+apoiar práticas da política institucional e veda o proselitismo religioso,
+político-institucional e/ou propaganda comercial.
+
+6. Sobre a gestão: As mídias e os grupos livres usam e desenvolvem
+sistematicamente mecanismos de gestão anti-hierárquicos e baseados na geração
+de consensos a partir da argumentação pública; ou seja, rejeitam (ou evitam ao
+máximo), como práticas de organização: a representação política e a votação
+plebiscitária. A divisão funcional é adotada com ponderação, sob avaliação
+coletiva e de maneira ocasional.
+
+7. Sobre as invenções: As mídias e os grupos livres propiciam e estimulam a
+invenção estética, tecnológica e política, na medida em que tomam a organização
+social, a cultura e o corpo como realidades dignas de serem transformados e
+aperfeiçoados. Nesse sentido, as mídias e os grupos livres defendem a liberdade
+de conhecimento e de acesso a ele; para contribuir com a concretização destas
+liberdades, as mídias e os grupos livres incentivam o uso de softwares livres e
+a publicação em formatos livres (.ogg para áudio, .png para imagens, etc.) e
+em, caso isso não seja possível, em formatos proprietários mas que sejam
+públicos (.rtf e .pdf para textos, .mpg para vídeos, etc.). As mídias e os
+grupos livres não incentivam o uso de formatos proprietários (.doc para texto,
+.ppt para apresentação de slides, etc.).
+
+8. Sobre as pesquisas e as metodologias: As mídias e os grupos livres promovem
+a pesquisa, o desenvolvimento e pratica de metodologias para a apropriação dos
+recursos de comunicação pelos públicos, através do que buscam transformar em
+práticas cotidianas dos cidadãos a produção de comunicação mediática e o seu
+uso público político.
+
+9. Sobre a expansão e a organização em redes: A lógica de expansão das mídias e
+grupos livres segue a de formação dos rizomas (e não da árvores): formam novas
+organizações quando o contingente de participantes aumenta, adensam as
+interconexões (comunicação lateral) entre as organizações e evitam que
+indivíduos e grupos de influência se coloquem no lugar de intermediários
+políticos.
+
+10. Sobre doações: Se recebem dinheiro, o fazem apenas como doação, ou seja:
+qualquer apoiador deve saber que seus recursos não serão empregados senão para
+os fins estritos de criação de espaços comunicativos livres, sendo vedadas as
+práticas de mercantismo cultural, social ou político. Tais doações são aceitas
+apenas se anônimas (isto é, não publicizadas). Dinheiro governamental ou
+empresarial não é aceito.
+
+11. Sobre auto-sustentabilidade: As mídias e grupos livres estimulam a geraçãoo
+de mecanismos de autosustentabilidade (ou "autodependência") local e
+comunitária. Exemplos: venda de camisetas, comidas, rifas, organização de
+festas, mostra de videos, etc. Tratam-se de atividades criadas e organizadas
+para estimular a vivência em coletivo e a escapar das práticas capitalistas. É
+recomendável que, dentro dos grupos e entre eles, exista uma socialização dos
+recursos e que os individuos também adotem essa prática, compartilhando
+recursos pessoais com o coletivo, para criar ambientes de solidariedade
+comunitária, onde ninguém seja excluído por falta de recursos.
+
+12. Sobre a gestão financeira: Para garantir essas condições de financiamento,
+toda a gestão financeira das mídias e grupos livres é publica: tanto as
+informações contábeis quanto a participação nas decisões são acessíveis às
+pessoas concernidas nas ações desta organização.
+
+13. Sobre a privacidade: As mídias e os grupos livres defendem a
+inviolabilidade da intimidade e a privacidade do indivíduo, especialmente
+contra sua exploração capitalista, por meio de dispositivos de identificação de
+padrões comportamentais. No caso da implementação de sistemas emergentes de
+identificação de padrões de uso nas plataformas das mídias e grupos livres,
+todos os concernidos têm pleno acesso ao seu funcionamento e os podem alterar
+sempre que desejarem (através de processos de formação argumentativa de
+consensos, vide acima).
+
+14. Sobre a espetacularização: As mídias e os grupos livres não se utilizam da
+espetacularização ou maravilhização. Quer dizer, realmente estamos precisados
+de conceituar e expressar verbalmente o que estamos tomando sob
+"espetacularização" e "maravilhização": quase a totalidade dos grupos de hoje
+trabalham demais com a espetacularização: as ações que escolhem são as mais
+espetacularizadas possíveis (tanto é que não vemos os grupos trabalharem com a
+mesma intensidade em coisas de base ou em estrutura), eles tem uma preocupação
+imensa em mostrar o que estão fazendo, em trabalhar com mídia, etc. Isso deve
+ser uma herança da dita mídia tática e de mais um monte de coisa e acho que
+deveriam ser analisados, tem que ter uma crítica. Porque às vezes os logotipos
+parecem surgir antes mesmo das ações.
+
+15. Sobre uma sociedade livre: As mídias e os grupos livres comprometem-se com
+o projeto de construção de uma sociedade livre, igualitária e com respeito ao
+meio ambiente.
+
+16. Sobre a garantia de expressão: As mídias e os grupos livres trabalham no
+sentido de garantir um espaço para que qualquer pessoa, grupo (de afinidade
+política, de ação direta, de artivismo) e movimento social - que estejam em
+sintonia com esses objetivos - possam publicar sua própria versão dos fatos.
+
+17. Sobre a distinção entre produtor/a e consumidor/a: As mídias e os grupos
+livres trabalham no sentido de romper o papel de espectador(a) passivo/a e
+transformando a prática midiática ao romper com a mediação do/a jornalista
+profissional e com a interferência de editores/as no conteúdo das matérias.
+
+18. Sobre a transformação da sociedade: As mídias e os grupos livres favorecem
+conteúdos informacionais sobre transformação social ou que retratem as
+realidades dos/as oprimidos/as ou as lutas dos novos movimentos.  Sobre a
+união: As mídias e os grupos livres trabalham no sentido de unir esforços para
+uma real democratização da sociedade, primando sempre por privilegiar a
+perspectiva dos/as oprimidos/as. Em função disso, esperamos uma atitude
+construtiva e tolerante entre os/as participantes do sítio; afinal, queremos
+juntar forças, não lutar entre nós.
+
+19. Sobre a intolerância: As mídias e os grupos livres lutam contra o racismo,
+o sexismo e outros tipos de intolerância.
+
+20. Sobre a remuneração pelo trabalho: As mídias e os grupos livres funcionam
+exclusivamente a partir de trabalho voluntário.
+
+21. Sobre a capitalização sobre trabalho: As mídias e os grupos livres não
+devem permitir que seus voluntários/as capitalizem em cima do seu trabalho
+voluntário, seja adicionando tal trabalho em seu currículo ou seja por obter
+benesses através do uso do nome do grupo ou da mídia livre. 
+
+## Outros códigos de conduta
+
+* [Debian Social Contract, Version 1.0](https://www.debian.org/social_contract.1.0).
+* Projeto Tor:
+  * [Our Social Contract](https://gitweb.torproject.org/community/policies.git/tree/social_contract.txt).
+  * [Our Statement of Values](https://gitweb.torproject.org/community/policies.git/tree/statement_of_values.txt).
diff --git a/docs/social/muamba/README.md b/docs/social/muamba/README.md
new file mode 100644
index 0000000..3772551
--- /dev/null
+++ b/docs/social/muamba/README.md
@@ -0,0 +1,79 @@
+# Clube da Muamba
+
+Sabe aquela festa de rua que não acontece porque falta o gerador de energia,
+aquele filme que não é feito porque não há câmera ou aquela rádio que não
+transmite por falta de transmissor? E aquele panfleto que não é impresso porque
+ninguém tem acesso a uma máquina de Xerox ou aquele passeio que não é feito por
+falta de bicicletas?
+
+É muito frustante não conseguir fazer algo por falta de recursos. Mais
+frustrante ainda é saber que em geral muito desses recursos são possuídos por
+alguém conhecido ou, alternativamente, poderiam sê-lo caso se soubesse da
+necessidade do seu uso. Mesmo que alguém compre uma mesa de som para dar uma
+festa, essa pessoa não a usará necessariamente todos os dias, e isso vale para
+muitos dos nossos objetos pessoais: máquinas fotográficas, microfones, rádios,
+etc, nem tudo isso é usado por nós o tempo todo, mas no entanto há um forte
+apelo do mercado para que cada um de nós tenha um exemplar de cada um dos
+milhares de produtos da indústria de massa.
+
+O Clube da Muamba é uma iniciativa cultural de pensar novas formas de economia
+que não se baseiam no valor de troca, mas no valor de uso não-rival de objetos
+físicos. Para montar um clube da muamba, basta juntar seus/as amigas/os e
+colocar na roda o que cada pessoa quer compartilhar.
+
+Como funciona?
+--------------
+
+Existem mil maneiras de fazer um Clube da Muamba, cabendo a cada grupo inventar
+e/ou adaptar a sua e portanto aqui deixamos apenas sugestões de como fazer o
+seu. O Clube da Muamba não é um grupo fixo ou organização institucional, mas
+uma idéia para que existam muitos Clubes da Muamba e para que a prática de
+empréstimos de equipamentos e recursos inativos se torne parte da cultura comum
+das pessoas ao ponto de ser desempenhado com naturalidade.
+
+Basta reunir um grupo de pessoas, amigos/as ou voluntários/as que esteja
+disposto a compartilhar recursos (materiais ou não), sejam livros,
+eletroeletrônicos, máquinário pesado, veículos de transporte, etc. Cada pessoa
+ou subgrupo de pessoas do clube pode então tanto compartilhar objetos que já
+possuem como juntar recursos para adquirir (conjuntamente ou não) outros bens
+para serem disponibilizados coletivamente.
+
+Logística
+---------
+
+Nossa idéia é que não haja gerência cuidando dos empréstimos ou do contato
+entre as pessoas, mas sim que a logística se realize através de autogestão
+distribuída: cada pessoa ou grupo de pessoas que for dono de um dado recurso
+adiciona essa informação numa tabela, juntamente com informações adicionais
+sobre o recurso e disponibilidade de empréstimo. Assim, a pessoa ou grupo de
+pessoas que necessitar de um dado recurso disponível precisa apenas entrar em
+contato com os/as donos do recurso.
+
+Vaquinha contínua
+-----------------
+
+A vaquinha perpétua é uma forma de aquisição constante, permanente ou variável
+de equipamentos: um grupo de pessoas mantém um fundo coletivo que é gasto em
+bens diversos conforme a necessidade de incluí-los no Clube.
+
+Projetos similares
+------------------
+
+* [Vizinhocas](https://github.com/coolmeia/vizinhocas).
+* [NeighborGoods](http://neighborgoods.net).
+
+Conservação de equipamentos
+---------------------------
+
+De preferência:
+
+* Mantenha ferramentas e equipamentos sempre prontos para o uso!
+* Para não perder equipamentos ou ter dificuldades em encontrá-los, mantenha-os
+  sempre num mesmo local.
+
+Centro de Estocagem de Bugigangas
+---------------------------------
+
+O que fazer com o monte de coisas acumuladas? Um Centro de Estocagem coletivo
+numa vizinhança pode dar conta de aproveitar melhor as coisas que não temos um
+uso imediato.
diff --git a/docs/social/muamba/clube.md b/docs/social/muamba/clube.md
new file mode 100644
index 0000000..7d72e90
--- /dev/null
+++ b/docs/social/muamba/clube.md
@@ -0,0 +1,89 @@
+# Clube da Muamba $nome
+
+O Clube da Muamba $nome pode ser composto por pessoas que fazem parte de uma
+mesma vizinhança. Para saber a respeito da disponibilidade e viabilidade do
+empréstimo de um dos recursos listados, entre em contato com o/a dono/a ou
+zelador/a e eventualmente também com quem está atualmente com ele.
+
+Por uma questão de logística, as muambas podem estar separadas por região, o
+que não impede de uma pessoa de outra região pedir algo emprestado que esteja
+em outra, desde que consiga resolver o problema do transporte :)
+
+Lista de Muambas
+----------------
+
+| Equipamento            | Detalhes | Disponibilidade | Dono/a ou Zelador/a | Com quem está atualmente |
+|------------------------|----------|-----------------|---------------------|--------------------------|
+| Exemplo de equipamento | troca    | Total           | email@de.contato    | email@de.contato         |
+
+Viajantes
+---------
+
+Esta seção existe para permitir que pessoas que viajarão de um local para outro
+possam trazer muambas para outras pessoas e grupos (serviço voluntário de mula
+:P). Recomenda-se dar preferência para trazer muambas a grupos ou objetos que
+constarão no clube da muamba e deixar muambas para uso exclusivamente pessoal
+com menor prioridade (mas que nem por isso sejam desencorajados os traslados de
+muambas pessoais.
+
+| Viajante | Local de origem | Local de destino | Data de partida | Data de chegada (ou retorno) | Observações |
+|----------|-----------------|------------------|-----------------|------------------------------|-------------|
+| -        | -               | -                | -               | -                            | -           |
+
+Lista de Reparos
+----------------
+
+Nesta tabela as pessoas e/ou grupos podem colocar os bens que, por motivos de
+força maior, poderiam mas não estão no Clube se estivessem em condições de uso.
+Também aqueles que são inviáveis para o dono consertar mas de conserto
+vantajoso para terceiros! :)
+
+| Recurso | Detalhes | O que precisa(ou gostaria) | Possibilidade de vaquinha |
+|---------|----------|----------------------------|---------------------------|
+| -       | -        | -                          | -                         |
+
+Lista de Livros
+---------------
+
+Aqui ficam listados os livros, revistas, etc que estão na roda, formando assim
+nossa biblioteca distribuída e autogestionada :)
+
+| Livro | Autor | Disponibilidade | Dono/a ou Zelador/a | Com quem está atualmente |
+|-------|-------|-----------------|---------------------|--------------------------|
+| -     | -     | -               | -                   | -                        |
+
+Lista de Filmes
+---------------
+
+Esta é uma lista experimental onde ficam listados os filmes que estão na roda,
+formando assim nossa videoteca distribuída e autogestionada. Adicione apenas
+filmes em '''cópias físicas removíveis''' (DVDs, VHS, VCD), já que estamos
+fomentando o empréstimo de bens físicos. Ou seja: se você tiver uma lista
+imensa de filmes no seu disco, opte por utilizar um sistema de compartilhamento
+P2P para aliviar o volume desta lista.
+
+| Filme | Áudio/Legenda | Mídia | Disponibilidade | Dono/a ou Zelador/a | Com quem está atualmente |
+|-------|---------------|-------|-----------------|---------------------|--------------------------|
+| -     | -             | -     | -               | -                   | -                        |
+ 
+Lista de Vontades
+-----------------
+
+Nesta tabela as pessoas e/ou grupos podem colocar os bens que gostariam que
+estivessem no Clube.
+
+| Recurso | Detalhes | Quem gostaria ou precisa | Possibilidade de vaquinha |
+|---------|----------|--------------------------|---------------------------|
+| -       | -        | -                        | -                         |
+
+Lista de Reparos
+----------------
+
+Nesta tabela as pessoas e/ou grupos podem colocar os bens que, por motivos de
+força maior, poderiam mas não estão no Clube se estivessem em condições de uso.
+Também aqueles que são inviáveis para o dono consertar mas de conserto
+vantajoso para terceiros! :)
+
+| Recurso | Detalhes | O que precisa(ou gostaria) | Possibilidade de vaquinha |
+|---------|----------|----------------------------|---------------------------|
+| -       | -        | -                          | -                         |
diff --git a/docs/social/muamba/emprestimos.md b/docs/social/muamba/emprestimos.md
new file mode 100644
index 0000000..c4cc8fa
--- /dev/null
+++ b/docs/social/muamba/emprestimos.md
@@ -0,0 +1,19 @@
+# Termo de empréstimo
+
+Plano Básico
+------------
+
+Adoro emprestar minhas coisas! Empresto a muamba que você me pediu desde que:
+
+  - Você devolva conforme nosso combinado :)
+  - Caso haja alguma quebra ou perda da muamba, você se compromete a ressarcir o prejú.
+  - Se eu precisar dela antes do nosso combinado, você topa devolvê-la.
+
+Planos específicos
+------------------
+
+* Coisas frágeis (discos de vinil): como cuidar.
+* Como proceder em casos de quebras:
+*   Peças substituíveis.
+*   Peças insubstituíveis. 
+* Entrega e devolução. 
diff --git a/docs/social/rede.md b/docs/social/rede.md
new file mode 100644
index 0000000..551eefb
--- /dev/null
+++ b/docs/social/rede.md
@@ -0,0 +1,82 @@
+# Princípios e processo da rede $rede
+
+Originalmente [Princípios e processo da rede `$rede`](https://rectech.sarava.org/publico/processo).
+
+Sobre
+-----
+
+A rede `$rede` é um fórum de coletivos técnicos anticapitalistas, antifascistas,
+antisexistas, antihomofóbicos e antiracistas e que rejeitam qualquer forma  
+de dominação e discriminação social.
+
+O objetivo do fórum é possibilitar o intercâmbio, a ajuda mútua e a cooperação
+entre os coletivos participantes e também uma interface pública de debates.     
+
+Assim, `$rede` não é um coletivo mas sim uma rede.
+
+Como funciona
+-------------
+
+A rede por padrão permanece em estado de dormência até ser ativada, quando por
+exemplo algum(s) coletivo(s) sugere(m) uma atividade, encontro ou cooperação.
+
+Processo de participação
+------------------------
+
+A participação na rede `$rede` é restrita a coletivos que atendam os critérios de
+afinidade, confiabilidade e comprometimento com a rede. Novos coletivos podem
+entrar na rede após processo de decisão favorável e caso eles concordem
+com a presente carta.
+
+Uma vez dentro da rede, os coletivos podem indicar quais dos seus membros devem
+ser inscritos ou retirados das plataformas de comunicação da rede `$rede`.
+
+Cada indivíduo deve, ao ingressar nas plataformas de comunicação da rede `$rede`,
+se apresentar e afirmar que atuará de forma construtiva, caso contrário estará
+passível de remoção.
+
+Processo de decisão
+-------------------
+
+Nenhuma pessoa ou grupo pode tomar decisões que afetem a autonomia da rede sem
+consultá-la anteriormente e obter um consenso positivo.
+
+As decisões na rede são baseadas em propostas que devem ser enviadas para a
+lista de discussão fechada da rede.
+
+O prazo mínimo de decisão é de duas semanas passível de adiamento e as decisões
+são atingidas por consenso. Caso um coletivo não se manifeste sobre uma proposta
+ele será considerado como em concordância com a proposta enviada.
+
+Privacidade
+-----------
+
+A rede `$rede` é semipública, isto é, parte de sua comunicação e organização é
+restrita aos coletivos participantes, enquanto que outra parte é pública e aberta
+a qualquer grupo ou pessoa.
+
+Informações que circulem em instâncias de comunicação privadas precisam de
+autorização para serem disponibilizadas em meios públicos (desclassificação).
+
+É uma escolha de cada participante se manter como membro privado.
+
+Interfaces de comunicação
+-------------------------
+
+A rede `$rede` possui as seguintes interfaces de comunicação:
+
+- Lista de discussão fechada com arquivo restrito a participantes.
+- Lista de anúncios moderada com inscrição e arquivos abertos.    
+- Plataforma web colaborativa.
+
+Tais interfaces são hospedadas por coletivos participantes ou afins e seu
+acesso e continuidade são cruciais para a manutenção da memória da rede.
+Assim, é imprescindível que a rede disponha de backups dessas plataformas
+sempre que necessário.
+
+Sobre este texto
+----------------
+
+Este processo foi baseado no "Template para Carta de princípios e processo de
+redes v1.0". Licença deste documento: GNU Free Documentation License:
+http://www.gnu.org/copyleft/fdl.html
diff --git a/docs/todo.md b/docs/todo.md
new file mode 100644
index 0000000..20ca166
--- /dev/null
+++ b/docs/todo.md
@@ -0,0 +1,25 @@
+# Tarefas
+
+Lista de tarefas deste projeto.
+
+## MkDocs
+
+* Convert to MkDocs. References:
+  * https://gitlab.torproject.org/rhatto/onion-mkdocs
+  * https://packages.debian.org/bookworm/mkdocs-material
+
+## Protocol Suite
+
+Um desenvolvimento posterior deste projeto poderia inclusive permitir a
+especificação de uma dada escolha protocolar através de:
+
+* Uma string de Protocol Suite.
+* Identificadores de cada protocolo ou parte de protocolo.
+* Indicação de dependências entre protocolos.
+
+Um esboço deste tipo foi feito no [RSP](https://rsp.fluxo.info).
+
+## Transition file
+
+* Inclusão de modelo de "arquivo de transição" e "testamentos" (digitais e
+  "analógicos"): https://jacobian.org/2022/nov/9/transition-files/
diff --git a/docs/usando.md b/docs/usando.md
new file mode 100644
index 0000000..2a5d110
--- /dev/null
+++ b/docs/usando.md
@@ -0,0 +1,15 @@
+# Como usar este projeto
+
+A modularidade de tais protocolos permite que eles sejam adotados tanto como um
+todo quanto em pequenos conjuntos (ou mesmo unitariamente) sem perda de
+consistência desde que seja observada a dependência entre protocolos/processos.
+
+## Variáveis
+
+Muitos dos protocolos utilizam variáveis, isto é, porções de texto prontas para
+a subsituição por um valor correspondente. Como exemplo, ocorrências da porção
+de texto `$coletivo` podem ser substituídas pelo nome do seu grupo.
+
+## Clonando o código
+
+    git clone https://git.fluxo.info/templates