Content migration from other projects

28 files changed, 1824 insertions, 0 deletions

diff --git a/organizacao/backups.mdwn b/organizacao/backups.mdwn
new file mode 100644
index 0000000..e258020
--- /dev/null
+++ b/organizacao/backups.mdwn
@@ -0,0 +1,38 @@
+[[PageOutline]]
+
+= 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 [http://rsp.sarava.org RSP], 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 [wiki:Backups/Auditagem 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:
+
+  * [wiki:Comunicacao/Politica Política de segurança da informação].
diff --git a/organizacao/backups/entrega.mdwn b/organizacao/backups/entrega.mdwn
new file mode 100644
index 0000000..d95008a
--- /dev/null
+++ b/organizacao/backups/entrega.mdwn
@@ -0,0 +1,33 @@
+[[PageOutline]]
+
+= 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 [wiki:Backups/Entrega/Tabela 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.
diff --git a/organizacao/coletiva.mdwn b/organizacao/coletiva.mdwn
new file mode 100644
index 0000000..5da6b44
--- /dev/null
+++ b/organizacao/coletiva.mdwn
@@ -0,0 +1,101 @@
+= Protocolo de Ação Coletiva =
+
+Possíveis interpretações sobre o significado e o efeito deste protocolo se encontram [wiki:Organizacao/Interpretacoes aqui].
+
+ * Versão: 1.0.
+ * Licença: LIMICS[1].
+
+== 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.
+     * Se manter 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://wiki.sarava.org/Main/Licenca
diff --git a/organizacao/coletiva/coletivo.mdwn b/organizacao/coletiva/coletivo.mdwn
new file mode 100644
index 0000000..1f67a9a
--- /dev/null
+++ b/organizacao/coletiva/coletivo.mdwn
@@ -0,0 +1,56 @@
+= 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] [wiki:Comunicacao/Licenciamento Licença de Manipulação de Informações do Coletivo $coletivo].
+  * [2] [wiki:Organizacao Protocolo de Ação Coletiva].
diff --git a/organizacao/coletiva/interpretacoes.mdwn b/organizacao/coletiva/interpretacoes.mdwn
new file mode 100644
index 0000000..d181590
--- /dev/null
+++ b/organizacao/coletiva/interpretacoes.mdwn
@@ -0,0 +1,368 @@
+[[PageOutline]]
+
+= 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/organizacao/coletiva/participacao.mdwn b/organizacao/coletiva/participacao.mdwn
new file mode 100644
index 0000000..e9415bd
--- /dev/null
+++ b/organizacao/coletiva/participacao.mdwn
@@ -0,0 +1,76 @@
+[[PageOutline]]
+
+= 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 [wiki:Comunicacao/ACL 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 [wiki:PageTemplates/RollCall roll call].
+
+= 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 [wiki:Comunicacao/Politica recomendações].
+
+= 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/organizacao/comunicacao/acl.mdwn b/organizacao/comunicacao/acl.mdwn
new file mode 100644
index 0000000..6417d94
--- /dev/null
+++ b/organizacao/comunicacao/acl.mdwn
@@ -0,0 +1,39 @@
+[[PageOutline]]
+
+= 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/organizacao/comunicacao/archive.mdwn b/organizacao/comunicacao/archive.mdwn
new file mode 100644
index 0000000..86a32e0
--- /dev/null
+++ b/organizacao/comunicacao/archive.mdwn
@@ -0,0 +1,13 @@
+[[PageOutline]]
+
+= 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/organizacao/comunicacao/backup.mdwn b/organizacao/comunicacao/backup.mdwn
new file mode 100644
index 0000000..b20f3ca
--- /dev/null
+++ b/organizacao/comunicacao/backup.mdwn
@@ -0,0 +1,29 @@
+[[PageOutline]]
+
+= 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 [wiki:Comunicacao/ACL ACL] 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 [wiki:Comunicacao/Politica Política de segurança da informação] e
+que possam ser utilizados como backup.
+
+== Dependências ==
+
+A realização deste processo depende da realização dos seguintes processos:
+
+  * [wiki:Comunicacao/Politica Política de segurança da informação].
+  * [wiki:Comunicacao/ACL Lista de acesso à participação (ACL)].
diff --git a/organizacao/comunicacao/cert.mdwn b/organizacao/comunicacao/cert.mdwn
new file mode 100644
index 0000000..48e78fc
--- /dev/null
+++ b/organizacao/comunicacao/cert.mdwn
@@ -0,0 +1,134 @@
+[[PageOutline]]
+
+= 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 [http://lair.fifthhorseman.net/~dkg/tls-centralization/ imposição tecnocrata] à utilização prática do HTTPS. Ela recria um domínio cartorial no cyberespaço e pode a qualquer momento [http://web.monkeysphere.info/news/internet_secret_backdoor/ ser utilizada por governos ou corporações para forjar certificados autenticados] e com isso [https://secure.wikimedia.org/wikipedia/en/wiki/Man-in-the-middle_attack grampear] 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 [http://cacert.org CACert].
+    b. [http://web.monkeysphere.info Monkeysphere].
+    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 [https://secure.wikimedia.org/wikipedia/en/wiki/Cacert#Inclusion_status caso do CACert].
+    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 [http://web.monkeysphere.info Monkeysphere] 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 [https://www.eff.org/wp/osp Best Practices for Online Service Providers], 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 [http://www.debian-administration.org/article/Enabling_HTTP_Strict_Transport_Security_on_debian_servers HSTS].
+  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.
+
+= Implementação =
+
+A implementação de HTTPS também deve obedecer a uma suite bem estabelecida. No caso do Apache:
+
+{{{
+SSLEngine on
+SSLProtocol -all +SSLv3 +TLSv1
+SSLCipherSuite HIGH:MEDIUM:!aNULL:!SSLv2:!MD5:@STRENGTH
+SSLHonorCipherOrder on
+}}}
+
+Para o Nginx:
+
+{{{
+ssl_protocols SSLv3 TLSv1;
+ssl_ciphers HIGH:MEDIUM:!aNULL:!SSLv2:!MD5:@STRENGTH;
+ssl_prefer_server_ciphers on;
+}}}
+
+Tal escolha deve desabilitar uma série de cifras ruins e habilitar aquelas que provém [https://secure.wikimedia.org/wikipedia/en/wiki/Perfect_forward_secrecy Perfect Forward Secrecy (PFS)].
+
+= 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 [https://gandi.net Gandi] 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. [https://secure.wikimedia.org/wikipedia/en/wiki/Gandi#Gandi_supports Contribuir com projetos de código aberto], vide [http://en.gandi.net/supports/ lista].
+
+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 {{{*.sarava.org}}} via [https://gandi.net Gandi]. O Coletivo arcará com os custos. Caso contrário, adotar a certificação [http://www.cacert.org/ CaCert] como padrão.
+  2. Manter formas alternativas de certificação via:
+    a. [http://web.monkeysphere.info Monkeysphere].
+    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 chaves de acesso, utilizando para isso OpenPGP. Como exemplo, manter uma página pública e atualizada sobre os atuais certificados utilizados e também informar grupos 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.sarava.org/?p=puppet-ssl.git;a=summary 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/organizacao/comunicacao/chat.mdwn b/organizacao/comunicacao/chat.mdwn
new file mode 100644
index 0000000..6c5d6b1
--- /dev/null
+++ b/organizacao/comunicacao/chat.mdwn
@@ -0,0 +1,36 @@
+[[PageOutline]]
+
+= 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}}}: [wiki:Comunicacao/ACL ACL] 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}}}: [wiki:Comunicacao/ACL ACL] 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 [wiki:Comunicacao/ACL ACL] 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:
+
+  * [wiki:Comunicacao/Politica Os critérios de segurança e privacidade].
+  * 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:
+
+  * [wiki:Comunicacao/Politica Política de segurança da informação].
+  * [wiki:Comunicacao/ACL Lista de acesso à participação (ACL)].
diff --git a/organizacao/comunicacao/infosec.mdwn b/organizacao/comunicacao/infosec.mdwn
new file mode 100644
index 0000000..ba2e16c
--- /dev/null
+++ b/organizacao/comunicacao/infosec.mdwn
@@ -0,0 +1,68 @@
+[[PageOutline]]
+
+= 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:
+
+  * [wiki:Comunicacao/ACL Lista de acesso à participação (ACL)].
diff --git a/organizacao/comunicacao/license.mdwn b/organizacao/comunicacao/license.mdwn
new file mode 100644
index 0000000..f047990
--- /dev/null
+++ b/organizacao/comunicacao/license.mdwn
@@ -0,0 +1,64 @@
+[[PageOutline]]
+
+= Licenciamento de informações =
+
+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] http://encontro.sarava.org/Principal/ConjuntoDeLicenciamentoLivre
+[2] http://encontro.sarava.org
+}}}
+
+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/organizacao/comunicacao/list.mdwn b/organizacao/comunicacao/list.mdwn
new file mode 100644
index 0000000..ed66169
--- /dev/null
+++ b/organizacao/comunicacao/list.mdwn
@@ -0,0 +1,51 @@
+[[PageOutline]]
+
+= 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 [wiki:Organizacao/Coletivo Protocolo de Ação do $coletivo].
+
+== Critérios de participação ==
+
+  1. Para participar da lista do Coletivo, uma pessoa precisa satisfazer o nível ''3'' de [wiki:Comunicacao/ACL ACL], isto é, fazer parte do Coletivo.
+  2. Apenas [wiki:Comunicacao/Politica emails suficientemente seguros] 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:
+
+  * [wiki:Organizacao/Coletivo Organização do Coletivo].
+  * [wiki:Comunicacao/ACL Lista de acesso à participação (ACL)].
+  * [wiki:Comunicacao/Politica Política de segurança da informação].
+
+= 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 [wiki:Comunicacao/ACL ACL], isto é, fazer parte do Coletivo.
+  2. Apenas [wiki:Comunicacao/Politica emails suficientemente seguros] 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:
+
+  * [wiki:Comunicacao/ACL Lista de acesso à participação (ACL)].
diff --git a/organizacao/comunicacao/transparency.mdwn b/organizacao/comunicacao/transparency.mdwn
new file mode 100644
index 0000000..03fc46a
--- /dev/null
+++ b/organizacao/comunicacao/transparency.mdwn
@@ -0,0 +1,44 @@
+[[PageOutline]]
+
+= 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 [wiki:Comunicacao/ACL ACL] ''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 [wiki:Comunicacao/ACL ACL] ''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 [wiki:Comunicacao/ACL ACL] ''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:
+
+  * [wiki:Comunicacao/ACL Lista de acesso à participação (ACL)].
diff --git a/organizacao/comunicacao/vizinhanca.mdwn b/organizacao/comunicacao/vizinhanca.mdwn
new file mode 100644
index 0000000..812d3ea
--- /dev/null
+++ b/organizacao/comunicacao/vizinhanca.mdwn
@@ -0,0 +1,53 @@
+[[PageOutline]]
+
+= 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 [wiki:Comunicacao/ACL Lista de acesso], 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 [wiki:Comunicacao/Politica emails suficientemente seguros] 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:
+
+  * [wiki:Comunicacao/ACL Lista de acesso à participação (ACL)].
+  * [wiki/Comunicacao/Politica Política de segurança da informação].
diff --git a/organizacao/contabilidade.mdwn b/organizacao/contabilidade.mdwn
new file mode 100644
index 0000000..af8a8c5
--- /dev/null
+++ b/organizacao/contabilidade.mdwn
@@ -0,0 +1,29 @@
+[[PageOutline]]
+
+= Contabiliade =
+
+A [wiki: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 [wiki:Contabilidade/Criterios critérios] sobre:
+    a. Doação (de e para o Coletivo).
+    b. Arrecadação.
+    c. Gastos.
+  2. Transparência
+    a. Manter o [wiki:Contabilidade/Balanco balanço] atualizado.
+    b. Fornecer os dados contábeis de acordo com os [wiki:Comunicacao/Transparencia critérios de transparência] 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 [wiki:Contabilidade/ContaBancaria tal informação] atualizada.
+  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/organizacao/contabilidade/criterios.mdwn b/organizacao/contabilidade/criterios.mdwn
new file mode 100644
index 0000000..18520d1
--- /dev/null
+++ b/organizacao/contabilidade/criterios.mdwn
@@ -0,0 +1,132 @@
+[[PageOutline]]
+
+= 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.sarava.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.sarava.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.sarava.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.sarava.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.sarava.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.sarava.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/organizacao/contabilidade/planejamento.mdwn b/organizacao/contabilidade/planejamento.mdwn
new file mode 100644
index 0000000..08cfc01
--- /dev/null
+++ b/organizacao/contabilidade/planejamento.mdwn
@@ -0,0 +1,18 @@
+[[PageOutline]]
+
+= 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/organizacao/hospedagem.mdwn b/organizacao/hospedagem.mdwn
new file mode 100644
index 0000000..cffc252
--- /dev/null
+++ b/organizacao/hospedagem.mdwn
@@ -0,0 +1,41 @@
+[[PageOutline]]
+
+= 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/organizacao/hospedagem/carta.mdwn b/organizacao/hospedagem/carta.mdwn
new file mode 100644
index 0000000..bd7ddcc
--- /dev/null
+++ b/organizacao/hospedagem/carta.mdwn
@@ -0,0 +1,77 @@
+[[PageOutline]]
+
+= 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
+}}}
+
+= Tradução inglesa = #English
+
+Versão inglesa em [wiki:English/Hosting/Letter].
diff --git a/organizacao/hospedagem/politica.mdwn b/organizacao/hospedagem/politica.mdwn
new file mode 100644
index 0000000..0dd50e8
--- /dev/null
+++ b/organizacao/hospedagem/politica.mdwn
@@ -0,0 +1,53 @@
+[[PageOutline]]
+
+= Política de Hospedagem do Grupo $coletivo =
+
+{{{
+Política de Hospedagem do Grupo $coletivo
+-----------------------------------------
+
+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.
+}}}
+
+= Tradução inglesa = #English
+
+Versão inglesa em [wiki:English/Hosting/Policy].
diff --git a/organizacao/hospedagem/recusa.mdwn b/organizacao/hospedagem/recusa.mdwn
new file mode 100644
index 0000000..1496d21
--- /dev/null
+++ b/organizacao/hospedagem/recusa.mdwn
@@ -0,0 +1,34 @@
+[[PageOutline]]
+
+== 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.
+
+== Modelo ==
+
+{{{
+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 ==
+
+Versão inglesa em [wiki:English/Hosting/Refusal].
diff --git a/organizacao/hospedagem/termo.mdwn b/organizacao/hospedagem/termo.mdwn
new file mode 100644
index 0000000..4b7a096
--- /dev/null
+++ b/organizacao/hospedagem/termo.mdwn
@@ -0,0 +1,111 @@
+[[PageOutline]]
+
+= 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
+}}}
+
+= Tradução inglesa = #English
+
+Versão inglesa em [wiki:English/Hosting/Term].
diff --git a/organizacao/pessoal.mdwn b/organizacao/pessoal.mdwn
new file mode 100644
index 0000000..1fb7a76
--- /dev/null
+++ b/organizacao/pessoal.mdwn
@@ -0,0 +1,39 @@
+Pessoal
+=======
+
+Isso varia de pessoa para pessoa. TL;DR aqui é o 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
+
+Como organizo as atividades
+---------------------------
+
+* Divido 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.
+* Fornecedores: é um projeto que agrega listas de compras.
+
+Como organizo 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.
diff --git a/organizacao/sistemas.mdwn b/organizacao/sistemas.mdwn
new file mode 100644
index 0000000..b04d75c
--- /dev/null
+++ b/organizacao/sistemas.mdwn
@@ -0,0 +1,41 @@
+[[PageOutline]]
+
+= 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 [http://rsp.sarava.org Resource Sharing Protocol] (RSP) 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 do [http://reductivelabs.com/trac/puppet/ Puppet], 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 o [http://padrao.sarava.org Padrão Saravá] 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/organizacao/sistemas/dns.mdwn b/organizacao/sistemas/dns.mdwn
new file mode 100644
index 0000000..df0b627
--- /dev/null
+++ b/organizacao/sistemas/dns.mdwn
@@ -0,0 +1,18 @@
+[[PageOutline]]
+
+= 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 [wiki:Camadas/Dominios domínios do Coletivo] 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:
+
+  * [wiki:Camadas/Dominios Gerenciamento de domínios].
diff --git a/organizacao/sistemas/dominios.mdwn b/organizacao/sistemas/dominios.mdwn
new file mode 100644
index 0000000..f6c5be4
--- /dev/null
+++ b/organizacao/sistemas/dominios.mdwn
@@ -0,0 +1,28 @@
+[[PageOutline]]
+
+= 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.