diff options
88 files changed, 5193 insertions, 1 deletions
diff --git a/backup/trac/Backups%2FEntrega.txt b/backup/trac/Backups%2FEntrega.txt new file mode 100644 index 0000000..2a7d45e --- /dev/null +++ b/backup/trac/Backups%2FEntrega.txt @@ -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.
\ No newline at end of file diff --git a/backup/trac/Backups.txt b/backup/trac/Backups.txt new file mode 100644 index 0000000..40b97a0 --- /dev/null +++ b/backup/trac/Backups.txt @@ -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].
\ No newline at end of file diff --git a/backup/trac/Camadas%2FDNS.txt b/backup/trac/Camadas%2FDNS.txt new file mode 100644 index 0000000..50e84be --- /dev/null +++ b/backup/trac/Camadas%2FDNS.txt @@ -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].
\ No newline at end of file diff --git a/backup/trac/Camadas%2FDominios.txt b/backup/trac/Camadas%2FDominios.txt new file mode 100644 index 0000000..a33b21c --- /dev/null +++ b/backup/trac/Camadas%2FDominios.txt @@ -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.
\ No newline at end of file diff --git a/backup/trac/Camadas.txt b/backup/trac/Camadas.txt new file mode 100644 index 0000000..12e339f --- /dev/null +++ b/backup/trac/Camadas.txt @@ -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.
\ No newline at end of file diff --git a/backup/trac/Comunicacao%2FACL.txt b/backup/trac/Comunicacao%2FACL.txt new file mode 100644 index 0000000..0d74283 --- /dev/null +++ b/backup/trac/Comunicacao%2FACL.txt @@ -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.
\ No newline at end of file diff --git a/backup/trac/Comunicacao%2FBackup.txt b/backup/trac/Comunicacao%2FBackup.txt new file mode 100644 index 0000000..4b80737 --- /dev/null +++ b/backup/trac/Comunicacao%2FBackup.txt @@ -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)].
\ No newline at end of file diff --git a/backup/trac/Comunicacao%2FBatePapo.txt b/backup/trac/Comunicacao%2FBatePapo.txt new file mode 100644 index 0000000..8851455 --- /dev/null +++ b/backup/trac/Comunicacao%2FBatePapo.txt @@ -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)].
\ No newline at end of file diff --git a/backup/trac/Comunicacao%2FDocumentos.txt b/backup/trac/Comunicacao%2FDocumentos.txt new file mode 100644 index 0000000..8d2cea8 --- /dev/null +++ b/backup/trac/Comunicacao%2FDocumentos.txt @@ -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''.
\ No newline at end of file diff --git a/backup/trac/Comunicacao%2FLicenciamento.txt b/backup/trac/Comunicacao%2FLicenciamento.txt new file mode 100644 index 0000000..cc0af4a --- /dev/null +++ b/backup/trac/Comunicacao%2FLicenciamento.txt @@ -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.
+}}}
\ No newline at end of file diff --git a/backup/trac/Comunicacao%2FLista.txt b/backup/trac/Comunicacao%2FLista.txt new file mode 100644 index 0000000..72e9bfc --- /dev/null +++ b/backup/trac/Comunicacao%2FLista.txt @@ -0,0 +1,26 @@ +[[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].
\ No newline at end of file diff --git a/backup/trac/Comunicacao%2FPolitica.txt b/backup/trac/Comunicacao%2FPolitica.txt new file mode 100644 index 0000000..3e881ab --- /dev/null +++ b/backup/trac/Comunicacao%2FPolitica.txt @@ -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)].
\ No newline at end of file diff --git a/backup/trac/Comunicacao%2FSSL.txt b/backup/trac/Comunicacao%2FSSL.txt new file mode 100644 index 0000000..d408211 --- /dev/null +++ b/backup/trac/Comunicacao%2FSSL.txt @@ -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/backup/trac/Comunicacao%2FSistemas.txt b/backup/trac/Comunicacao%2FSistemas.txt new file mode 100644 index 0000000..9effc8b --- /dev/null +++ b/backup/trac/Comunicacao%2FSistemas.txt @@ -0,0 +1,26 @@ +[[PageOutline]]
+
+= 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)].
\ No newline at end of file diff --git a/backup/trac/Comunicacao%2FTransparencia.txt b/backup/trac/Comunicacao%2FTransparencia.txt new file mode 100644 index 0000000..bc10338 --- /dev/null +++ b/backup/trac/Comunicacao%2FTransparencia.txt @@ -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)].
\ No newline at end of file diff --git a/backup/trac/Comunicacao%2FVizinhanca.txt b/backup/trac/Comunicacao%2FVizinhanca.txt new file mode 100644 index 0000000..7395bd2 --- /dev/null +++ b/backup/trac/Comunicacao%2FVizinhanca.txt @@ -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].
\ No newline at end of file diff --git a/backup/trac/Contabilidade%2FCriterios.txt b/backup/trac/Contabilidade%2FCriterios.txt new file mode 100644 index 0000000..9486400 --- /dev/null +++ b/backup/trac/Contabilidade%2FCriterios.txt @@ -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/backup/trac/Contabilidade%2FPlanejamento.txt b/backup/trac/Contabilidade%2FPlanejamento.txt new file mode 100644 index 0000000..deab3ea --- /dev/null +++ b/backup/trac/Contabilidade%2FPlanejamento.txt @@ -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.
\ No newline at end of file diff --git a/backup/trac/Contabilidade.txt b/backup/trac/Contabilidade.txt new file mode 100644 index 0000000..1fbd97c --- /dev/null +++ b/backup/trac/Contabilidade.txt @@ -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/backup/trac/English%2FHosting%2FLetter.txt b/backup/trac/English%2FHosting%2FLetter.txt new file mode 100644 index 0000000..b3f35fd --- /dev/null +++ b/backup/trac/English%2FHosting%2FLetter.txt @@ -0,0 +1,63 @@ +[[PageOutline]]
+
+= Hosting Letter =
+
+{{{
+$collective Hosting Letter
+--------------------------
+
+$collective is part of an intersection of various groups that discuss politics and
+technology in different ways. We work with internet servers turned to various
+cooperative goals. Then, our ideia is to colaborate with groups/projects that
+are part of mutual and multiple aid and support.
+
+$collective is an autonomous project kept by a collective of volunteers. One of our
+main goals is the collective creation of public spaces, common areas with projects and
+groups that intend to enforce and straighten coexistence.
+
+Our intention is not just offer a "hosting service" and then we're not available
+for groups that just want such thing. We want that groups we host colaborate with
+the construction of a neighborhood, a rhizome, meaning that technology doesn't have to be
+a barrier, but exactly the opposite. As technology is also a social construction,
+its purposes, its configurations and the processes it interferes with can't
+impose themselves independently of the choices made by the social groups where it's used.
+
+The internet is not only an environment of cooperation, but also of apropriation and
+exploitation of common goods. We understand that it just turns essentially into a
+public space when people can control their production and access means, things that
+don't happen on corporate and governmental spaces. Because of this we try to
+create public spaces, non-corporative and non-governmental and we hope that
+groups we host colaborate to the construction of such spaces.
+
+During the construction of these kind of spaces, we make discussions where we try to
+discover themes such as culture, society, technology, activism, social change
+and many others. Such a research, when possible, is shared pubicly.
+
+We research the political implications of technology and develop systems and
+instruments using different political values. We also keep a political dialogue
+in the logics of theory/practice.
+
+So, one of our proposals is to collectivelly establish a network of mutual
+support among groups and individuals interested in sharing the same physical
+structure to share their knowledges, activities and researches.
+
+We attempt then to break the relation between service provider/clients,
+because we're not service providers and the groups/individuals we host are not
+our clients. We both make part of the same collaboration network where diverse
+interests converge towards mutual empowerment. And who knows if such way of
+organizing things won't spread to other parts of society.
+
+Thinking about knowledge distribution and with an incentive to new groups
+interested in keeping their own server infrastructure, we try to share the most of
+our organization scheme.
+
+And remember: for us, $collective is not just a hosting system or a service provider.
+
+Interesting links:
+
+ - Researches available: http://wiki.$domain
+ - Configurations and operational procedures: http://padrao.$domain
+
+In solidarity,
+$collective Group
+}}}
\ No newline at end of file diff --git a/backup/trac/English%2FHosting%2FPolicy.txt b/backup/trac/English%2FHosting%2FPolicy.txt new file mode 100644 index 0000000..f51a062 --- /dev/null +++ b/backup/trac/English%2FHosting%2FPolicy.txt @@ -0,0 +1,49 @@ +[[PageOutline]]
+
+= Hosting Policy =
+
+{{{
+$collective Group Hosting Policy
+--------------------------------
+
+1. The Collective reserves to istelf the power to host or discontinue the
+ hosting of any group or individual according to the ethical, political and
+ practical principles of the Collective.
+
+2. In the case of hosting discontinuation for a given group, the Collective
+ commits itself to inform the hosted part with sufficient time and to make
+ available the hosted data.
+
+3. Groups and individuals are just hosted by the Collective if they want to
+ have a mutual relation of resources and activity sharing.
+
+4. Once the hosting partnership is created, the Collective must be informed of
+ actions and ways the hosted part is taking if those affects the Collective. By
+ the other hand, the Collective commits to inform the hosted part of anything
+ that can affect it.
+
+5. The terms of partnership must be clear in the sense of the commitment
+ between both sides on support, maintenance and development of the host and
+ sites.
+
+6. The hosted part is responsible for the hosted content and the Collective
+ cannot suffer legal consequences of improper or illegal content. Anyway the
+ Collective will make everything possible to protect the identity and privacy of
+ the hosted part.
+
+7. The relations should be established as transparently as possible, avoiding
+ hidden or manipulated information by both parts.
+
+8. The relations have the purpose of solidarity on knowledge, complementarity
+ on actions and exchange among groups, being vital to achieve ways of mutual
+ teaching-learning and develop policies that unite groups towards social and
+ political changes.
+
+9. The Collective commits itself to inform at least in general ways its
+ security and privacy policies on the hosting platforms.
+
+10. Hosting of social movements with sensitive content are kept, when possible,
+ hosted on platforms abroad.
+
+11. The hosting consists in cooperation and not in service providing.
+}}}
\ No newline at end of file diff --git a/backup/trac/English%2FHosting%2FRefusal.txt b/backup/trac/English%2FHosting%2FRefusal.txt new file mode 100644 index 0000000..b77e24b --- /dev/null +++ b/backup/trac/English%2FHosting%2FRefusal.txt @@ -0,0 +1,26 @@ +[[PageOutline]]
+
+= Refusal hosting letter =
+
+{{{
+Hi $requisitante,
+
+Unfortunatelly we can't host the project you requested because:
+
+ - We think it doesn't match the etical principles we adopt[1].
+
+ - And/or we consider it matches the kind of projects we have a critical
+ position with[2].
+
+We believe that there's not just one way to fight. We also don't believe that
+our etical principles and our criticisms represent the "right" viewpoint.
+Our viewpoint just reflect the conclusions we got after a lot of discussions.
+We try just to be coherent with what we believe and that's the reason why we
+can't accept your request.
+
+We don't want for this statement to mean that we want to give no value for
+the thing your project do or about what do you believe.
+
+[1] See http://encontro.sarava.org/Principal/ConjuntoDePrincipiosEticos
+[2] See http://wiki.$dominio
+}}}
\ No newline at end of file diff --git a/backup/trac/English%2FHosting%2FTerm.txt b/backup/trac/English%2FHosting%2FTerm.txt new file mode 100644 index 0000000..ba2b3a7 --- /dev/null +++ b/backup/trac/English%2FHosting%2FTerm.txt @@ -0,0 +1,96 @@ +[[PageOutline]]
+
+= Hosting Terms =
+
+{{{
+Hi :)
+
+Agreement on Hosting
+--------------------
+
+We discussed and we agree to offer hosting as you requested. Now, in order for we to
+effectivelly maintain this hosting, we need to:
+
+ 1. State what is our commitment in relation to this hosting.
+ 2. That you and/or your group agree with the present term of agreement and
+ with our Hosting Policy.
+
+These are mutual commitment agreements, where we explain what is our commitment
+with the hosting and that the hosted part needs to agree so we can keep such
+relation.
+
+In case you agree with the terms of this letter and accept our Hosting Policy,
+just reply saying so and the hosting will start as soon as possible. :)
+
+Our commitment
+--------------
+
+We commit ourselves to keep the hosting working. The hosting maintenance
+happens through volunteer and responsible work.
+
+The used infra-structure is stable, but subject to eventual power and network
+outages or even more sensitive problems.
+
+Then, sometimes hosting can go offline. We will always be allert and we care
+for security and integrity of the hosted data. But, for a lot of reasons, we
+cannot garantee the total availability or even the eternity of such data.
+
+We commit ourselves as much as possible to keep security copies of the data we
+host. But we ask for you to also arrange, as much as possible, backup copies of
+your data.
+
+Our group is composed by people that do a lot of tasks. The most important and
+sensitive tasks, such as hosting, are dependent to other taks and each one is
+associated to a workgroup of responsible persons.
+
+It may happen that someone leaves a workgroup and eventually some tasks will lack
+commited people to get them accomplished. It's on this sense that we garantee
+hosting: according to the available workforce at our group. It's possible that,
+in the future, something happens and we stop hosting in a given platform.
+But, if we do so, we garantee that it won't happen from night to day and we'll
+give enough time for you and your project to migrate the data somewhere else.
+
+We also have the commitment to inform, when you ask, our procedures according to
+our accounting policy. Such procedures vary from privacy and security policies
+to choices of platforms and our group's situation.
+
+As our procedures can change with time, we recommend you to ask for procedures
+descriptions when you feel necessary.
+
+We have our limitations but we'll keep things working as much as we can. :)
+
+Your commitment
+---------------
+
+We hope that you and/or your project use the offered resource with wisdom.
+Don't ask for websites and tools if you will abandon them. If you install your own
+programs, please have the responsibility to keep it up-to-date as security holes at
+your place can compromise other hosted projects.
+
+Please don't forget that the maintenance of multiple projects needs a lot of work
+and is difficult to keep secure. Then we ask for everyone's collaboration. We would be
+very pleased if you informed us about your plans to install tools in your space. :)
+
+Sharing interfaces
+------------------
+
+A possible space for interactions among projects is the Neighborhood Mailing
+List[1] (subscription just for sufficiently secure mail accounts, get in touch for
+more information). When we host groups and individuals, we hope that they will also
+be responsible in what comes to taking care of such spaces.
+
+Our neighborhood is also a place for articulations, where all groups and
+individuals sharing the same infra-structure can communicate between
+themselves.
+
+If the subjects we research are inspiring for you too, we invite you to
+participate in such discussions. To avoid centralization, we propose you to
+collectivelly discuss with your group and publish the conclusions you
+get. For us it is fundamental to try to build a metodology that makes possible the
+dissemination of such discussions.
+
+[1] $neighborhood_mailing_list_address
+
+In solidarity,
+$grupo Collective
+}}}
\ No newline at end of file diff --git a/backup/trac/English%2FOrganization.txt b/backup/trac/English%2FOrganization.txt new file mode 100644 index 0000000..de7b618 --- /dev/null +++ b/backup/trac/English%2FOrganization.txt @@ -0,0 +1,122 @@ +[[PageOutline]]
+
+= Collective Action Protocol =
+
+The protocol was written to make possible a generic adoption by groups but at the same time it attempt to solve specific problems that aren't necessarily shared by a gvin group. Then, it's not intended to be "The Collective Protocol" but instead a suggestion about how to shape a collective protocol.
+
+Suggestion is to read it as how could a collective protocol look like instead a sugestion of adoption, especially because usually the needs for a process are different as here we're trying to solve a different set of problems.
+
+The Collective Action Protocol seems to be both a stateless (at it's informal part) and stateful (at it's formal part) protocol. It has some inspiration from:
+
+ * Games, altough it's unknow how a parallel with game theory could be traced (could this protocol be considered a game where the objective is a win-win outcome attempting to maximize the collective effort?).
+ * Free and open source software development processes (although this protocol makes the 'benevolent dictator' obsolete as behaviour, purpose and telealogy turns to be mean properties emerging internally from the processes and peoples' wishes and mutual relationship). It can be thought as a social software (culture).
+ * Ways labor division can be organized to better fill collective needs and autonomy while encouraging people to work together.
+
+== Characteristics ==
+
+For sinthetic purposes, most of the discussion was split from the protocol text. Perhaps this compression let a lot of helpful information to be missing, so here comes a list of the main properties this protocol tries to achieve:
+
+ * Resilience, robustness and failover.
+ * Ensure some collective autonomy is guaranteed (through formal process having responsibility attached) while not blocking the self-organizing efforts using to kinds of processes (formal and informal). This means in some way to overcome the [http://en.wikipedia.org/wiki/Tyranny_of_Structurelessness The Tyranny of Structurelessness] while not failing back to over-structuration, bureaucracy, etc and at the same time tries to deal with apathy and missparticipation.
+ * For formal processes, splits decision-making (i.e, the step where the collective evals if a given proposal is pertinent an deserves the collective moral support) from the resposibility assignment (step where people actually volunteer to do the tasks) in a way that just formal processses that are under responsibility can be counted as processes that will very probably happen, so if in the proposal/discussion/decision steps just the content of the proposal is evalued, the responsibility assignment is a filter where just processes that finds people to achieve them are able to pass.
+ * Leting a process be also a registry eases the integration with a ticket system.
+
+== Limitations ==
+
+Some limitations of the protocol are:
+
+ * Not sure whether it's scalable. Maybe it was set for usage inside a small affinity group so it might not fit to big groups where people has not affinity between themselves.
+ * It does not deal with connections/disconnections, i.e, the protocol do not define how someone joins or leaves the group.
+ * As all protocols depends on it's usage, it is not a guarantee by itself that things are going to happen in the collective. The protocol just states how the energy is spent in the collective process but have no influence in the desire to act or not to act.
+ * It does not state what are the communication channels (both for formal and informal communications) and how they should be used. In fact, as this really varies a lot from collective to collective so it was chosen to leave that specific communication structure out of the Collective Action Protocol so it would be easier to share and have another protocol taking care of informational channels.
+
+== Formality and informality ==
+
+In this protocol, what is a formal and what is an informal process really depends in how the collective wants to extend it's autonomy, so it's not a thing defined withing the protocol. Examples of formal and informal processes can be:
+
+ * Informal processes: meetings, dinners, researching, write texts, code, talk with people, wikifarming and everything else that the collective thinks that does not changes the collective autonomy.
+ * Formal processes: the main activities the group is commited to do and what is crucial for them to happen and to keep the collective autonomy.
+
+= Collective Action Protocol =
+
+ * Version: 0.1.
+ * Raw english translation version (related to protocol version): 0.1.
+ * License: Sarava Content Distribution License (no translation for now :/)
+
+== Processes and autonomy ==
+
+Everything that happens in the Collective is a process. Processes has different manifestations but are mainly fluxes and the registry of these fluxes (memory/information).
+
+There are two kinds of processes:
+
+ * Formal processes
+ * Shape/form predefined by collective consensus AND
+ * Needs/use the collective autonomy THUS
+ * Needs to be followed by a minimum responsabilization so the process do not fail
+
+ * Informal processes
+ * Shape/form not needed to be predefined AND
+ * Do not need/use the collective autonomy THUS
+ * Do not need to be under the resposability of someone, i.e, an informal process that do not happen doesn't affect the collective autonomy
+
+Activities without information in the collective cannot be considered by processes (formal or informal) as these activities do not have information equality/isonomy in the collective. To have information about a process is a requisite for participation and then an activity without information inside the collective cannot be considered as process.
+
+The basic autonomy of the Collective, i.e, the minimum autonomy that allows it's existence according to this protocol is the existence of secure and private communication channels that allows the existence of collective processes (formal or informal). Without these channels, the basic collective autonomy is seriously damaged as well as the application of this protocol. All aditional autonomy in the collective (i.e, autonomy that is not contained in the basic autonomy) should be defined with formal processes.
+
+A collective member act inside the collective when use it's resources or the collective name. By the other hand, a collective member act outside of the collective when do not use such resources or the collective name. Collective members do not make actions (inside or outside the collective) that consciouslly can cause damage to the collective autonomy.
+
+== Formal processes ==
+
+Each formal processs is an instance of the following state diagram:
+
+{{{
+ .------------------->-----------------.
+ / .----------<--------------<-------. \
+ | ' \ \
+ | | .------>-----. \ \
+ | | | \ \ \
+ Proposal -----> Discussion ->-. \ \ \
+ | ^ | \ \ \ \
+ | | | \ \ \ \
+ | `----<-----' | \ \ \
+ | | | \ \
+ `------>----- Decision --<--' | \ \
+ | | | \ \
+ | | | | |
+ Responsibility --<---' '------> Archiving --->---' ;
+ Assignment --------->---------' ^ \ /
+ ^ | ___________/ `---<-----'
+ | \ .'
+ | `--> Achievement ->--.
+ | | | \
+ | | | /
+ `----<-----' `-----<---'
+}}}
+
+ * Proposal: step where an idea of a formal process is presented to the collective. The idea ' or description ' can come for the Archive, from a previous Discussion, from an informal process that needs to be formalized or from a person or group from inside or outside the collective. General recomendation is to give a good explanation of the idea containing: deadline sugestion, process life cycle, responsibility assignment criteria and deadline and recomendations for emergencies (when appliable).
+
+ * Discussion:
+ * It's not a mandatory step, but has importance anyway.
+ * Changes to proposals make the formal process go back to the Proposal state. Proposals that do not follow to the Decision step or do not get changes until it's deadline should be archived.
+ * Changed proposals that come from outside the collective or that have external groups or persons participation should be sent back also to the external group/person, despite these persons/groups do not participate in the internal discussion at the collective. If these external people/groups agree with the changed proposal, then the formal process proceeds with the discussion using the changed proposal. If that doesn't happen, i.e, these external people/groups don't agree with the changed proposal, then the formal process is archived (except if the external parties provide another changed proposal or more arguments to the discussion).
+
+ * Decision:
+ * Through consensus and the active participation depends in following the information required by the proposal.
+ * If there's no consensus about the decision of a proposal it's automatically blocked with the possibility to extend it's deadline.
+ * Silence regarding a proposal is considered as an agreement.
+ * Deadline: general recomendation is to set deadlines relative to the average time needed by active people in the collective to take into account, discuss, make changes and ask for eventual postponing. Processes are elegible to postponing or advance it's deadline with an explicitly request from someone from the collective. If there's no such request, the initial deadline is assumed.
+ * Approvals from proposals coming from outside the collective or that have external people/groups involved are communicated about the approval just after the responsibility assignment.
+
+ * Responsibility assignment
+ * Concerns the minimization of points of failure.
+ * Responsibilization is a volunteer action but requires the submission of a commitment/responsibilization term affirming that the person:
+ * Has knowledge about the procedure in question.
+ * Is gonna achieve it under the estimated deadline and is gonna keep the collective informed about the task.
+ * Will inform the collective in a reasonable timeframe if cannot continue to be involved with the process so the collective can keep the process going, assign new responsibilities or finnish it and send to the archive.
+ * Non-accomplishment with a process compromises the ability of someone to be responsible for other tasks.
+ * Formal processes that are approved but, after the responsibility assignment deadline, have unsufficient responsibilization assigned, should be sent to the archive. Proceesses in the archive were previously approved cannot be sent back directly to the responsibilty assigment and should instead go to the proposal step.
+ * In case of proposals coming from outside the collective or that have external people/groups involved, these people/groups should be informed of the approval just after the responsibility assignment, i.e, at the end of this step.
+
+ * Achievement
+ * Just formal processes with sufficient responsibility assignment can go to the achievement step. Processes that were already achived goes to the archive.
+ * Formal processes that were not achieved in the deadline should come back to the Responsibility assignment step. In a similar way, processes whose assigned people cannot doing it should come back to the Responsibility assignment step if the number of assigned people is smaller than the required.
diff --git a/backup/trac/Hospedagem%2FCarta.txt b/backup/trac/Hospedagem%2FCarta.txt new file mode 100644 index 0000000..6862e42 --- /dev/null +++ b/backup/trac/Hospedagem%2FCarta.txt @@ -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/backup/trac/Hospedagem%2FCartaDeRecusa.txt b/backup/trac/Hospedagem%2FCartaDeRecusa.txt new file mode 100644 index 0000000..647ba7f --- /dev/null +++ b/backup/trac/Hospedagem%2FCartaDeRecusa.txt @@ -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].
\ No newline at end of file diff --git a/backup/trac/Hospedagem%2FPolitica.txt b/backup/trac/Hospedagem%2FPolitica.txt new file mode 100644 index 0000000..5a38b50 --- /dev/null +++ b/backup/trac/Hospedagem%2FPolitica.txt @@ -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].
\ No newline at end of file diff --git a/backup/trac/Hospedagem%2FTermo.txt b/backup/trac/Hospedagem%2FTermo.txt new file mode 100644 index 0000000..2be1ee6 --- /dev/null +++ b/backup/trac/Hospedagem%2FTermo.txt @@ -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].
\ No newline at end of file diff --git a/backup/trac/Hospedagem.txt b/backup/trac/Hospedagem.txt new file mode 100644 index 0000000..6992c54 --- /dev/null +++ b/backup/trac/Hospedagem.txt @@ -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.
\ No newline at end of file diff --git a/backup/trac/Organizacao%2FColetivo.txt b/backup/trac/Organizacao%2FColetivo.txt new file mode 100644 index 0000000..0e1212d --- /dev/null +++ b/backup/trac/Organizacao%2FColetivo.txt @@ -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].
\ No newline at end of file diff --git a/backup/trac/Organizacao%2FDependencia.txt b/backup/trac/Organizacao%2FDependencia.txt new file mode 100644 index 0000000..8b075a1 --- /dev/null +++ b/backup/trac/Organizacao%2FDependencia.txt @@ -0,0 +1,10 @@ += Dependências entre processos =
+
+Por este processo:
+
+ 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.
+
+= Sugestão =
+
+Como sugestão para o futuro, o conteúdo deste processo pode ser incluído numa proposta de alteração de [wiki:Organizacao protocolos].
\ No newline at end of file diff --git a/backup/trac/Organizacao%2FInterpretacoes.txt b/backup/trac/Organizacao%2FInterpretacoes.txt new file mode 100644 index 0000000..b9d5b8c --- /dev/null +++ b/backup/trac/Organizacao%2FInterpretacoes.txt @@ -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/backup/trac/Organizacao%2FParticipacao.txt b/backup/trac/Organizacao%2FParticipacao.txt new file mode 100644 index 0000000..991d8a9 --- /dev/null +++ b/backup/trac/Organizacao%2FParticipacao.txt @@ -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/backup/trac/Organizacao.txt b/backup/trac/Organizacao.txt new file mode 100644 index 0000000..307ed0b --- /dev/null +++ b/backup/trac/Organizacao.txt @@ -0,0 +1,98 @@ +[[PageOutline]]
+
+= 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.
+
+== Referências ==
+
+ * [1] Licença de Manipulação de Informações do Grupo Saravá http://wiki.sarava.org/Main/Licenca
\ No newline at end of file diff --git a/backup/trac/PageTemplates%2FAdministracaoDeServidor.txt b/backup/trac/PageTemplates%2FAdministracaoDeServidor.txt new file mode 100644 index 0000000..ead1412 --- /dev/null +++ b/backup/trac/PageTemplates%2FAdministracaoDeServidor.txt @@ -0,0 +1,51 @@ +[[PageOutline]]
+
+= Administração do {{{$servidor}}} =
+
+Este processo estabelece os critérios de administração do {{{$servidor}}}, doravante mencionado como {{{$servidor}}}, canalizador de fluxos ou simplesmente como servidor.
+
+= Classes RSP =
+
+O servidor deve estar configurado de acordo com as seguintes classes do [wiki:Camadas/RSP Resource Sharing Protocol]:
+
+ * {{{$classe}}} - {{{$classe_versao}}}.
+
+= Política de Administração =
+
+ 0. Criação de Usuários:
+ a. Qualquer integrante do Coletivo pode ter uma conta no servidor, mas caso tenha deve zelar pela segurança da mesma e concordar com a presente política.
+ b. A criação de usuários no servidor deve ser comunicada ao Coletivo e seguir eventuais procedimentos existentes.
+ c. A senha da conta no servidor não pode ser compartilhada com outras contas e deve ser razoavelmente forte.
+ d. Em caso de perda ou roubo de senha, o Grupo de Trabalho do servidor deve ser contatado o quanto antes.
+
+ 1. Configuração: ao instalar ou efetuar qualquer tipo de configuração na máquina, procure:
+ a. Adicionar, se possível e/ou necessário, a configuração em sistema de gestão servidores que o Coletivo utiliza.
+ b. Documentar os procedimentos utilizados ou informe ao Grupo de Trabalho do servidor.
+
+ 3. Comunicação: na medida do possível, comunique o Grupo de Trabalho do servidor sobre alterações feitas na sua configuração configuração.
+
+= Quota =
+
+O Coletivo alocará para si, em princípio, um limite garantido de {{{$disco}}} de espaço em disco no servidor. Toda a quantidade adicional de disco existente no servidor pode ser disponibilizada para outros grupos afins, mediante processo formal e sem garantias de backup.
+
+Quotas de uso de banda, processamento e memória ficam a cargo do Grupo de Trabalho do servidor ou de todo o Coletivo conforme necessidade ou mediante requisição.
+
+= Responsabilização =
+
+Cabe ao Grupo de Trabalho formado pelas pessoas responsáveis por este processo seguir a política de administração e ainda:
+
+ * Zelar para que o servidor possua o nível de segurança, privacidade e estabilidade escolhidas.
+ * Cuidar para que o downtime do servidor não passe de {{{$downtime}}}.
+ * Efetuar as atualizações de softwares necessárias para o funcionamento básico do servidor.
+
+A responsabilização neste processo não implica o compromisso com a administração de todas as camadas, aplicações, configurações e dados que existam ou possam existir no servidor, mas apenas com o funcionamento básico do servidor.
+
+= Dependências =
+
+A realização deste processo depende da realização dos seguintes processos:
+
+ * {{{$dependencia}}}.
+
+= Sobre este texto =
+
+O texto deste processo foi redigido utilizando o [wiki:PageTemplates/AdministracaoDeServidor Template para Administração de Servidor]. No caso de alterações que não dizem respeito apenas ao Grupo e que possam enriquecer tal template, favor submetê-las também upstream, isto é, ao texto do template.
\ No newline at end of file diff --git a/backup/trac/PageTemplates%2FAtaDeReuniao.txt b/backup/trac/PageTemplates%2FAtaDeReuniao.txt new file mode 100644 index 0000000..545ea05 --- /dev/null +++ b/backup/trac/PageTemplates%2FAtaDeReuniao.txt @@ -0,0 +1,23 @@ +[[PageOutline]]
+
+= Reunião de ../../.... =
+
+ * Data: ../../.... (dia-da-semana).
+ * Horário: ..:..
+ * Local: ... (Cidade).
+ * Caráter: ...
+ * Presentes: ...
+
+= Ata =
+
+== Informes ==
+
+...
+
+== Próximas reuniões ==
+
+...
+
+== Outras questões ==
+
+...
diff --git a/backup/trac/PageTemplates%2FAtualizacaoDeProcesso.txt b/backup/trac/PageTemplates%2FAtualizacaoDeProcesso.txt new file mode 100644 index 0000000..43e0388 --- /dev/null +++ b/backup/trac/PageTemplates%2FAtualizacaoDeProcesso.txt @@ -0,0 +1,26 @@ +[[PageOutline]]
+
+= Atualização de processo =
+
+O presente processo efetua a atualização do seguinte processo:
+
+ * {{{$processo}}}
+
+O novo texto para o processo é o seguinte:
+
+{{{
+$novo_texto
+}}}
+
+== Condições de atualização ==
+
+ * O processo só pode ser atualizado se as pessoas responsabilizadas pelo mesmo concordarem explicitamente com isso. Caso elas não concordem este processo deve ser arquivado.
+ * No ticket do processo deve haver uma menção à atualização efetuada e com referência ao processo que o alterou.
+
+== Responsabilização ==
+
+As pessoas responsáveis pelo presente processo devem efetivar a atualização do processo de acordo com as condições mencionadas anteriormente.
+
+= Sobre este texto =
+
+O texto deste processo foi redigido utilizando o [wiki:PageTemplates/AtualizacaoDeProcesso Template para Atualização de Processo]. No caso de alterações que não dizem respeito apenas ao Grupo e que possam enriquecer tal template, favor submetê-las também upstream, isto é, ao texto do template.
\ No newline at end of file diff --git a/backup/trac/PageTemplates%2FAutorizacaoParaUsoDeConteudo.txt b/backup/trac/PageTemplates%2FAutorizacaoParaUsoDeConteudo.txt new file mode 100644 index 0000000..91a6660 --- /dev/null +++ b/backup/trac/PageTemplates%2FAutorizacaoParaUsoDeConteudo.txt @@ -0,0 +1,33 @@ +[[PageOutline]]
+
+= Template para Autorização de Uso de Conteúdo =
+
+Por este processo, {{{$entidade}}} fica autorizada a utilizar os seguintes conteúdos do Coletivo:
+
+ 1. {{{$conteudo}}}
+
+Com as seguintes permissões:
+
+ 1. Distribuição do conteúdo nos seguintes meios:
+ a. Digital.
+ b. Impresso.
+ c. Audiovisual.
+ 2. Alteração do conteúdo mediante inclusão de nota descrevendo as mudanças efetuadas.
+ 3. Vigente para versões anteriores e futuras do conteúdo.
+
+Com as seguintes restrições:
+
+ 1. Impedido o uso comercial ou fins lucrativos.
+ 2. A preservação da licença original do conteúdo.
+ 3. Uso restrito apenas para a publicação intitulada {{{$publicacao}}}.
+ 4. A validade desta permissão é de {{{$validade}}}, podendo ou não ser renovada.
+
+= Dependências =
+
+A realização deste processo depende da realização dos seguintes processos:
+
+ * [wiki:Comunicacao/Licenciamento Licenciamento de informações].
+
+= Sobre este texto =
+
+O texto deste processo foi redigido utilizando o [wiki:PageTemplates/AutorizacaoParaUsoDeConteudo Template para Autorização de Uso de Conteúdo]. No caso de alterações que não dizem respeito apenas ao Grupo e que possam enriquecer tal template, favor submetê-las também upstream, isto é, ao texto do template.
\ No newline at end of file diff --git a/backup/trac/PageTemplates%2FDebate.txt b/backup/trac/PageTemplates%2FDebate.txt new file mode 100644 index 0000000..9b1fbe8 --- /dev/null +++ b/backup/trac/PageTemplates%2FDebate.txt @@ -0,0 +1,25 @@ +[[PageOutline]]
+
+= Debate =
+
+Realização de um debate no {{{$local}}} ou em outro lugar conveniente (mas não pago e nem corporativo), eventualmente em parceria com o {{{$grupo}}}, de um debate sobre {{{$tema}}}. O evento seria oficialmente organizado pelo Coletivo e talvez pelo {{{$grupo}}} (caso topem) e portanto se trata de um processo formal.
+
+Tal evento é politicamente interessante ao Coletivo ao marcar presença no {{{$local}}}, além de preencher uma lacuna pela falta de debates sobre o assunto.
+
+As tarefas envolvidas são:
+
+ * Marcar uma boa data.
+ * Reservar o {{{$local}}} ou local apropriado, juntamente equipamento necessário.
+ * Convidar palestrantes que entendam do assunto e possuam visão crítica.
+ * Fazer, imprimir e afixar cartazes em locais chaves.
+ * Divulgação pela internet e eventualmente pelo Portal do Coletivo.
+ * Realizar o debate, fazendo a mediação se necessário.
+
+Observações:
+
+ * O debate não terá o apoio de organizações corporativas ou estatais e não contará com financiamento.
+ * As pessoas do Coletivo que estiverem presentes na mesa não falarão em nome do Coletivo.
+
+= Sobre este texto =
+
+O texto deste processo foi redigido utilizando o [wiki:PageTemplates/Debate Template para Debate]. No caso de alterações que não dizem respeito apenas ao Grupo e que possam enriquecer tal template, favor submetê-las também upstream, isto é, ao texto do template.
\ No newline at end of file diff --git a/backup/trac/PageTemplates%2FEntregaDeBackup.txt b/backup/trac/PageTemplates%2FEntregaDeBackup.txt new file mode 100644 index 0000000..829c4c8 --- /dev/null +++ b/backup/trac/PageTemplates%2FEntregaDeBackup.txt @@ -0,0 +1,50 @@ +[[PageOutline]]
+
+= Entrega de Backup =
+
+{{{
+Conforme solicitado, o último backup disponível de $descricao, datado de $data
+e obtido $origem, já está disponível.
+
+Seguem os dados:
+
+ - URL: https://backups.$dominio/$sitio
+ - Conta: $sitio
+ - Senha: $senha
+
+O https://backups.$dominio atualmente usa um certificado SSL
+auto-assinado, cuja impressão digital é
+
+ $fingerprint
+
+Hashes dos arquivos disponibilizados:
+
+ md5sum: $hashes
+ sha1sum: $hashes
+
+Auditoria realizada:
+
+ - Busca e eventual remoção de código executável.
+ - Mudança de senhas em banco de dados (senhas truncadas).
+ - Busca por vírus.
+
+Tarefas não-realizadas porém recomendadas:
+
+ - Checagem do conteúdo do banco de dados (para evitar calúnia ou
+ desinformação)
+ - Checagem do conteúdo dos arquivos.
+ - IMPORTANTE: checagem de usuários para evitar inscrições de
+ elementos estranhos.
+ - Checagem da configurações da instância, caso ela seja reinstalada
+ noutro local.
+ - Limpeza do spam e desativação de todas as contas desconhecidas
+ (principalmente relacionadas a spam).
+
+Observações:
+
+ - Em princípio, não há prazo para a permanência de tal backup
+ no local disponibilizado. No entanto, pode ser que ele precise
+ ser apagado para liberar espaço ou nalgum procedimento de
+ limpeza. Por isso, recomenda-se que sejam baixados o quanto antes.
+
+}}}
\ No newline at end of file diff --git a/backup/trac/PageTemplates%2FGrupoDeTrabalhoDeHospedagem.txt b/backup/trac/PageTemplates%2FGrupoDeTrabalhoDeHospedagem.txt new file mode 100644 index 0000000..ee3d363 --- /dev/null +++ b/backup/trac/PageTemplates%2FGrupoDeTrabalhoDeHospedagem.txt @@ -0,0 +1,29 @@ +[[PageOutline]]
+
+= Grupo de Trabalho de Hospedagem em {{{$plataforma}}} =
+
+O presente processo estabelece o funcionamento do Grupo de Trabalho de Hospedagem em {{{$plataforma}}} (doravante mencionado apenas como '''plataforma'''), consistindo em:
+
+ 1. Manter instalações atualizadas e em funcionamento da plataforma.
+ 2. Acompanhar avisos de segurança e atualizações dos aplicativos necessários para o funcionamento da plataforma.
+ 3. Caso não seja realizado automaticamente, efetuar atualizações de segurança em no máximo '''uma semana''' (incluindo finais de semana e feriados) após as mesmas serem disponibilizadas.
+ 4. Observar e aplicar os critérios de segurança e privacidade existentes para os/as usuários da plataforma.
+ 5. Caso possível, atender a pedidos do Coletivo pela instalação adicional da plataforma em locais distintos em virtude de aspectos legais e políticos.
+ 6. Disponibilizar ao Coletivo informações relacionadas aos procedimentos utilizados pelo grupo de trabalho, manutenções e atualizações que foram ou serão efetuadas.
+
+= Responsabilização =
+
+É de responsabilização do grupo de trabalho a realização das tarefas anteriormente mencionadas. Não é de responsabilidade do presente grupo de trabalho:
+
+ 1. Manter ou entrar em contato com grupos hospedados.
+ 2. Prestar suporte aos grupos hospedados.
+
+Não é de responsabilidade do presente grupo de trabalho:
+
+ 1. Pelo funcionamento de cada instância da plataforma.
+
+Em outras palavras, o presente grupo de trabalho não se responsabiliza pelo uso de cada instância da plataforma, mas sim pelo funcionamento, atualização e auditoria das instalações globais da plataforma, isto é, o grupo de trabalho não lida com instâncias específicas da plataforma mas sim com a infra-estrutura da mesma.
+
+= Sobre este texto =
+
+O texto deste processo foi redigido utilizando o [wiki:PageTemplates/GrupoDeTrabalhoDeHospedagem Template para Grupo de Trabalho de Hospedagem]. No caso de alterações que não dizem respeito apenas ao Grupo e que possam enriquecer tal template, favor submetê-las também upstream, isto é, ao texto do template.
\ No newline at end of file diff --git a/backup/trac/PageTemplates%2FHospedagem.txt b/backup/trac/PageTemplates%2FHospedagem.txt new file mode 100644 index 0000000..8b7654d --- /dev/null +++ b/backup/trac/PageTemplates%2FHospedagem.txt @@ -0,0 +1,19 @@ +[[PageOutline]]
+
+= Hospedagem de {{{$projeto}}} =
+
+Este processo trata da hospedagem de um sítio/repositório em {{{$plataforma}}} com endereço {{{http://$sitio.$dominio}}} (e eventuais domínios adicionais) para abrigar o projeto {{{$projeto}}}, que é {{{$descricao}}}.
+
+== Contato ==
+
+O contato do projeto {{{$projeto}}} responsável pelo sítio é o {{{$contato}}}.
+
+== Dependências ==
+
+A realização deste processo depende da realização dos seguintes processos:
+
+ * {{{$dependencias}}}
+
+= Sobre este texto =
+
+O texto deste processo foi redigido utilizando o [wiki:PageTemplates/Hospedagem Template para Hospedagem]. No caso de alterações que não dizem respeito apenas ao Grupo e que possam enriquecer tal template, favor submetê-las também upstream, isto é, ao texto do template.
\ No newline at end of file diff --git a/backup/trac/PageTemplates%2FParticipacaoEmGruposExternos.txt b/backup/trac/PageTemplates%2FParticipacaoEmGruposExternos.txt new file mode 100644 index 0000000..20dd383 --- /dev/null +++ b/backup/trac/PageTemplates%2FParticipacaoEmGruposExternos.txt @@ -0,0 +1,57 @@ +[[PageOutline]]
+
+= Participação no $grupo =
+
+Este processo estabelece a participação do Coletivo no $grupo, doravante mencionado neste texto tanto como $grupo ou simplesmente como '''Grupo'''.
+
+= Descrição do Grupo =
+
+A descrever.
+
+= Informações de contato e comunicação =
+
+A descrever.
+
+= Critérios de privacidade e segurança do Grupo =
+
+A descrever.
+
+= Descrição das tarefas relacionadas =
+
+Considerando que:
+
+ 1. Não se pode assumir que todas as pessoas do Coletivo estejam participando ativamente do Grupo e que
+ 2. O Coletivo precisa discutir, propor e emitir posições acerca de questões relativas ao Grupo.
+
+As tarefas para a participação no Grupo consistem em:
+
+ 1. Levar do Grupo para o Coletivo as questões a serem discutidas, decididas e/ou que sejam de interesse do Coletivo ou de pessoas do Coletivo, documentando na medida do possível os processos relacionados nas instâncias e seções correpondentes do Coletivo usadas para tais fins.
+ 2. Levar do Coletivo para o Grupo as propostas, discussões, sugestões e posicionamentos que partirem do Coletivo e cujo envio estiver aprovado, documentando na medida do possível os processos relacionados nas instâncias e seções correpondentes do Grupo usadas para tais fins.
+ 3. Providenciar ao Coletivo ou à pessoas do Coletivo informações disponíveis no Grupo mediante requisição da parte interessada.
+
+= Responsabilização =
+
+Em todos os casos, as pessoas responsabilizadas:
+
+ 1. Se comunicarão do Grupo para o Coletivo (e vice-versa) observando os critérios de privacidade segurança do Coletivo e do Grupo.
+ 2. Informarão explicitamente, caso estejam repassando informações que o Coletivo envia para o Grupo, que tais informações representam uma comunicação oficial e formal do Coletivo. Nos demais casos, recomenda-se que as pessoas responsáveis informem explicitamente que estão se comunicando informalmente e/ou que a comunicação não representa a posição do Coletivo.
+ 3. Realizarão, na medida do possível, a tradução de comunicação de e para o português, nos casos em que a mesma precise ser realizada noutro idioma.
+
+Cabe ainda observar que:
+
+ 1. As pessoas responsáveis por tal comunicação entre o Coletivo e o Grupo são denominadas de ''[http://en.wikipedia.org/wiki/Liaison liaisons]'' entre o Coletivo e o Grupo, podendo atuar também como ''[http://en.wikipedia.org/wiki/Proxy proxies]'' para pessoas do Coletivo, isto é, enviar informações para o Grupo oriundas de pessoas do Coletivo que não queiram se identificar.
+ 2. Cabe aos/às ''liaisons'' dividirem entre si se organizarem para dividir as tarefas relativas ao acompanhamento e repasse de informações do Coletivo para o Grupo e vice-versa.
+ 3. Oas/as '''liasons''' respeitarão e observarão os critérios, regras e sugestões de conduta, comunicação e etiqueta tanto do Grupo quando do Coletivo.
+
+= Compartilhamento de informações =
+
+Caso o Grupo mantenha comunicações em outros idiomas que não o português, é possível ainda compartilhar informações sobre o Grupo que não sejam específicas/internas do Coletivo entre outros grupos lusófonos/brasileiros que também estão no Grupo, desde que isso seja feito atendendo os critérios de segurança e privacidade do Grupo e do Coletivo.
+
+Além disso, tal repasse de informações:
+
+ 1. Não é de responsabilidade dos/as ''liaisons''.
+ 2. Precisa de autorização do Coletivo.
+
+= Sobre este texto =
+
+O texto deste processo foi redigido utilizando o [wiki:PageTemplates/ParticipacaoEmGruposExternos Template para Participação em Grupos Externos]. No caso de alterações que não dizem respeito apenas ao Grupo e que possam enriquecer tal template, favor submetê-las também ''upstream'', isto é, ao texto do template.
\ No newline at end of file diff --git a/backup/trac/PageTemplates%2FRollCall.txt b/backup/trac/PageTemplates%2FRollCall.txt new file mode 100644 index 0000000..2968c53 --- /dev/null +++ b/backup/trac/PageTemplates%2FRollCall.txt @@ -0,0 +1,15 @@ +[[PageOutline]]
+
+= Rodada de Chamadas =
+
+A Rodada de Chamadas, também conhecida como [http://en.wikipedia.org/wiki/Roll_call roll call], é um procedimento utilizado para saber quem ainda participa de um grupo. Em cada rodada, das pessoas ausentes nas atividades do Coletivo, apenas aquelas que responderem permanecem no grupo conforme o [wiki:Organizacao/Participacao Processo de participação no Coletivo].
+
+= Chamado =
+
+As pessoas envolvidas no Coletivo que estiverem ausentes das atividades do Coletivo tem o período entre o início e o término da realização do processo para se pronunciarem a respeito da sua permanência no Coletivo, caso contrário estarão passíveis de retirada do Coletivo.
+
+Esta também pode ser considerada como uma oportunidade para as pessoas apresentarem suas atividades e seus anseios. :)
+
+= Sobre este texto =
+
+O texto deste processo foi redigido utilizando o [wiki:PageTemplates/RollCall Template para Rodada de Chamadas]. No caso de alterações que não dizem respeito apenas ao Grupo e que possam enriquecer tal template, favor submetê-las também upstream, isto é, ao texto do template.
\ No newline at end of file diff --git a/backup/trac/WikiStart.txt b/backup/trac/WikiStart.txt new file mode 100644 index 0000000..36f5d6e --- /dev/null +++ b/backup/trac/WikiStart.txt @@ -0,0 +1,47 @@ +[[PageOutline]]
+
+= Protocolos =
+
+''Protocolos'': repositório de protocolos de gestão coletiva, procedimentos, comportamentos e regras simples que, quando combinados, contribuem para a emergência (no sentido de emergir) de padrões complexos de organização coletiva: [http://pt.wikipedia.org/wiki/Meme memes] que talvez aumentem a fluidez de grupos sociais.
+
+A modularidade de tais protocolos permite que eles sejam adotados tanto como um todo quanto em pequenos conjuntos (ou mesmo unitariamente) sem perda de consistência desde que seja observada a dependência entre protocolos/processos.
+
+Recomenda-se que cada protocolo a ser aplicado num grupo o seja através de um [wiki:Organizacao processo formal] (inclusive o próprio [wiki:Organizacao protocolo de organização]).
+
+Muitos dos protocolos utiliza variáveis, isto é, porções de texto prontas para a subsituição por um valor correspondente. Como exemplo, ocorrências da porção de texto {{{$coletivo}}} podem ser substituídas pelo nome do seu grupo.
+
+Navegue pelos protocolos (e interpretações) disponíveis (there's also an [wiki:English english] page)! :)
+
+== Organização ==
+
+[[TitleIndex(Organizacao)]]
+
+== Comunicação ==
+
+[[TitleIndex(Comunicacao)]]
+
+== Contabilidade ==
+
+[[TitleIndex(Contabilidade)]]
+
+== Camadas ==
+
+[[TitleIndex(Camadas)]]
+
+== Backups ==
+
+[[TitleIndex(Backups)]]
+
+== Hospedagem ==
+
+[[TitleIndex(Hospedagem)]]
+
+== Templates ==
+
+[http://pt.wikipedia.org/wiki/Templates Templates] de processos que podem ser facilmente reutilizados:
+
+[[TitleIndex(PageTemplates)]]
+
+= Licença =
+
+Copyright (c) Grupo Saravá: Desde que não mencionado em contrário, todo o conteúdo deste sítio é distribuído de acordo com a [http://wiki.sarava.org/Main/Licenca Licença de Manipulação de Informações do Grupo Saravá].
\ No newline at end of file diff --git a/casa.mdwn b/casa.mdwn new file mode 100644 index 0000000..47e1ce0 --- /dev/null +++ b/casa.mdwn @@ -0,0 +1,4 @@ +[[!meta title="Casa"]] +======== + +[[!inline pages="page(casa*)" archive="yes"]] diff --git a/casa/checklist.mdwn b/casa/checklist.mdwn new file mode 100644 index 0000000..8ef2b47 --- /dev/null +++ b/casa/checklist.mdwn @@ -0,0 +1,14 @@ +[[!meta title="Checklist Doméstico Básico"]] + +* Água. +* Luz. +* Gás. +* Internet. + +Organização +----------- + +* Kit médico. +* Lista de contatos. +* Caixa de ferramentas. +* OpenHouse em https://festa.fluxo.info. diff --git a/casa/procedimento.mdwn b/casa/procedimento.mdwn new file mode 100644 index 0000000..2d06beb --- /dev/null +++ b/casa/procedimento.mdwn @@ -0,0 +1,57 @@ +Procedimento padrão de limpeza ou reforma +----------------------------------------- + +- Para o serviço 30 minutos antes do expediente para limpeza + do local e das ferramentas. + +- Avisar com antecedência a necessidade de mais material. + +- Manter o ambiente sempre organizado, isso economiza tempo, evita + perdas e deixa o ambiente menos carregado. + +- Não sujar. + +- Não danificar coisas. + +- Trabalhar com cuidado e sem pressa. + +- Forrar tudo. + +Recomendações gerais +-------------------- + +- Saco/lata de lixo +- Lona +- Vassoura e pá +- Panos +- Porta-ferramentas e peças +- Procurar manter as mãos limpas +- Antes de quebrar qualquer coisa, entre em contato e pergunte se pode +- Antes de cortar qualquer coisa, entre em contato e pergunte se pode +- Uso e economia de recursos (por exemplo água) +- Não tomar decisões importantes sem consultar os/as responsáveis pela casa + +Recomendações para jardins +-------------------------- + +- Não usar o rastelo para varrer piso. +- Tirar folhas velhas? +- Podar plantas? Quais? + +Recomendações sobre o uso de ferramentas +---------------------------------------- + +- Boa conservação. +- Não manusear com as mãos sujas. +- Limpar após o uso. +- Não forçá-las. +- Não misturar as ferramentas da casa com as de terceiros. + +Orçamentos +---------- + +- Nenhum trabalho pode começar sem a aprovação de um orçamento. +- Orçamentos devem ter prazo. +- Acertos podem ser feitos após o término dos serviços para compensar + excesso de trabalho, mas estes não podem passar muito do orçamento + acordado. diff --git a/casa/regras.mdwn b/casa/regras.mdwn new file mode 100644 index 0000000..bbf3d9e --- /dev/null +++ b/casa/regras.mdwn @@ -0,0 +1,33 @@ +[[!meta title="Regras Domésticas"]] + +Regras genéricas de convívio a serem combinadas caso a caso. + +* Sobre frituras. +* Andar de sapatos dentro de casa. +* Bagunça dentro e fora do quarto. +* Compartilhamento de material de higiene. +* Padrão de lavagem de panelas para aumentar suas conservação. +* Evitar abrir produtos que já possuem outras embalagens abertas. +* Manter ambiente limpo e organizado para evitar trabalho excessivo. + +Limpeza +------- + +Modos de limpeza: + +* Mutirão coletivo periódico. +* Revezamento semanal periódico. + +Mantimentos +----------- + +* Comprar periódicas em atacadões. +* Compras semanais de frutas, verduras e legumes. + +Social +------ + +* Airbnb? +* Hospedagem solidária. +* [Couchsurfing](https://www.couchsurfing.com)? + diff --git a/etica.mdwn b/etica.mdwn new file mode 100644 index 0000000..3579d5a --- /dev/null +++ b/etica.mdwn @@ -0,0 +1,96 @@ +[[!meta title="Ética"]] + +Motivação +--------- + +Código é lei? Código pode também ser ética. Se existem [protocolos](https://protocolos.fluxo.info) e [códigos de conduta](https://www.debian.org/vote/2014/vote_002) atuando no nível de grupos, é importante também haver procedimentos de auxílio para relações em nível individual. + +Pressupostos +------------ + +* Como cantou Daminhão Experiência, "O mundo foi bem feito / todo mundo tem defeito". +* Saber quando pisar dentro e fora do quadrado. +* Noções básicas de postura social. + +Cuidados +-------- + +Não é a intenção deste breve guia: + +* Se transformar numa rocha inalterável e inflexível de como as relações humanas devem ser. +* Criar um protocolo que dificulte relações e deixe as pessoas apartadas. + +Este guia é mais uma referências de aspectos a serem pensados em relações com pessoas. + +Objetivos +--------- + +Grosso modo: + +* Calma. +* Alegria. +* Agilidade. +* Sangue-bonismo. +* Companheirismo. +* Solidariedade, fraternidade, alteridade, autruísmo. + +Pisando no quadrado +------------------- + +Este é um checklist de procedimentos e código de conduta. Você tem uma ideia de como se portar em cada um desses items? + +* Comunicação implícita e explícita: + * O que pode ser assumido de antemão. + * O que não pode ser assumido de antemão. +* Separação entre aspectos da vida: + * Profissional, político e pessoal. + * Amizades e afinidades. + * Público e privado. +* Lidando com conhecimento: + * Criando um canal e um encorajamento explícito para contatos, sugestões e críticas. + * Fomentando a formação e a inclusão de mais pessoas no ativismo técnico e na difusão do conhecimento. + * Tendo uma melhor comunicação com grupos e pessoas próximas. + * Definir melhor e de forma pública o funcionamento e a participação. +* Relacionamento: + * [Alteridade](http://www.revolucoes.org.br/v1/conferencia/alteridade). + * Generosidade. + * Alimentação. + * Liberdade de associação e de não-associação, tanto para propósitos gerais quanto específicos. + * Responsabilidade e zelo. + * Buscar facilitar as relações e situações, ao invés de dificultar a fluidez dos relacionamentos. + * Comportamentos evitados: trolling, bullying, spamming, etc. + * Gentileza gera gentileza. + * Proceder: humildade, respeito, responsa. + * Assiduidade, pontualidade e atrasos. + * Política de assinatura de chaves. + * Participação em debates e discussões. + * Favores e reciprocidade. + * Fidelidade (compromisso) e lealdade (espontâneo). + * Sobre a confiança (contextual e total) e a alteridade. + * Pronomes de tratamento e linguagem inclusiva. + * Discussão, facilitação, opiniões (e mudança de opiniões), respeito a rodadas e falas: + * Discussão de temas em geral. + * Discussão periódica da relação. + * Comunicação mediada (virtual): + * [Netiqueta](https://tools.ietf.org/html/rfc1855). + * Lei de [Postel](https://en.wikipedia.org/wiki/Jon_Postel): "Be liberal in what you accept, and conservative in what you send". + * Como lidar com ausência de resposta. + * Como a ausência de resposta é interpretada. + * Assuntos públicos, semi-públicos e privados: como lidar com mensagens privadas evitando concentração de informação e canais laterais que possam prejudicar organizações horizontais. + * Emoticons, cordialidade e polidez. + * Quando assinar comunicação, quando não assinar, modo anônimo. + * Comunicação ao vivo: + * Pronomes. + * Cumprimentos (aperto de mão, beijo, saudação). +* Sistematizando formas de lidar com situações diversas: + * [Defence mechanisms](https://en.wikipedia.org/wiki/Defence_mechanisms). + * Círculo Restaurativo. + * Comunicação não-violenta. + * Linguagem inclusiva. + * Situações críticas: como não reproduzir instituições burguesas (tribunal, prisão, manicômio) ou arcaicas (ostracismo, linchamento, etc)? + * Facilitação e resolução de conflitos. + * [Conflito e Consenso](https://docs.indymedia.org/Local/CmiBrasilConflitoConsenso). + * [Conflict resolution](https://simple.wikipedia.org/wiki/Conflict_resolution). + * Referências + * [General Resolution: code of conduct](https://www.debian.org/vote/2014/vote_002). + * [Código de conduta da SquatConf](https://github.com/squatconf/organisation/blob/master/code_of_conduct.md#squatconf-code-of-conduct). @@ -1,7 +1,17 @@ -[[!meta title="Templates"]] +[[!meta title="Templates e Protocolos Sociotécnicos"]] Diversos templates para grupos, projetos, etc. +''Protocolos'': repositório de protocolos de gestão coletiva, procedimentos, comportamentos e regras simples que, quando combinados, contribuem para a emergência (no sentido de emergir) de padrões complexos de organização coletiva: [http://pt.wikipedia.org/wiki/Meme memes] que talvez aumentem a fluidez de grupos sociais. + +A modularidade de tais protocolos permite que eles sejam adotados tanto como um todo quanto em pequenos conjuntos (ou mesmo unitariamente) sem perda de consistência desde que seja observada a dependência entre protocolos/processos. + +Recomenda-se que cada protocolo a ser aplicado num grupo o seja através de um [wiki:Organizacao processo formal] (inclusive o próprio [wiki:Organizacao protocolo de organização]). + +Muitos dos protocolos utiliza variáveis, isto é, porções de texto prontas para a subsituição por um valor correspondente. Como exemplo, ocorrências da porção de texto `$coletivo` podem ser substituídas pelo nome do seu grupo. + +Navegue pelos protocolos (e interpretações) disponíveis (there's also an [wiki:English english] page)! :) + [[!map pages="page(*) and !ikiwiki/* and !index and !sandbox and !templates* and !smileys and !shortcuts and !ikiwiki and !RecentChanges and !*/Discussion" show="title"]] Sobre diff --git a/organizacao.mdwn b/organizacao.mdwn new file mode 100644 index 0000000..bbdc5b6 --- /dev/null +++ b/organizacao.mdwn @@ -0,0 +1,118 @@ +[[!meta title="Organização"]] + +Índice +------ + +[[!inline pages="page(organizacao*)" archive="yes"]] + +Se a [modelagem de ameaças](https://threat.fluxo.info) é a mãe da segurança, organização é a mãe de tudo! + +Grupos +====== + +Texto originalmente [publicado como parte de uma oficina](https://rectech.sarava.org/publico/node/65). + +Uma fala sobre organização (processos, metodologias, etc) para coletivos técnicos radicais. Apenas aspectos organizacionais entre pessoas será abordado, como tomada de decisões, responsabilização, realização, etc, deixando aspectos técnicos para outras falas. + +Introdução +---------- + + Se você está panguando, o problema é seu. + Se você quer deixar de panguar, o problema é nosso. + --- Atarefados Anônimos + +- Houve uma época em que acreditava que a computação ajudaria as pessoas a se organizarem. +- Mas hoje fico impressionado no nível de desorganização de grupos e pessoas. +- Em parte, porque a capacidade de se organizar foi transferida para as máquinas corporativas que escolhem qual e que informação as interagirão. +- Ao mesmo tempo, a desorganização é a forma mais sutil de opressão, já que dificilmente as pessoas enxergam a desorganização como causada por fatores externos: "estou desorganizado/a" é uma fase comum que atribui a culpa às pessoas. +- Mas sim, a organização é uma tarefa nossa. Avante! + +Prática!!! +---------- + +Vamos começar fazendo prática e depois a teoria! + +- Coletores e gestores pessoais + - Caderno + - Post-it: que bagunça! + - Agenda impressa e digital + - Email e a caixa de saída + +- Coletores e gestores coletivos + - Lista de discussão: as tarefas se perdem! + - Sistemas de tickets + +- Relação entre caderno, email, sistema + +- Acumulação: guardar o trabalho organizativo e material feito hoje para usá-lo no futuro. + +Topologia +--------- + +- Desenvolvimento e Operação +- Upstream e downstream: mover a solução para upstream +- Ter mais informes do que questões da debater: divisões em GTs e desacoplamento + +Urgência e emergência +--------------------- + +- Urgências e emergências devem estar previstas na medida do possível. + +Níveis +------ + +- Pessoal: Zen To Done, etc +- Coletivo: https://protocolos.fluxo.info/trac +- Às vezes ajudamos mais os grupos se já estamos organizados/as, mas em muitas situações é a atividade coletiva que nos organiza. + +Problemas +--------- + +- Quais são os problemas a serem resolvidos? +- Problemas que queremos/iremos resolver e aqueles que não resolveremos. +- Fazer o que queremos X fazer o que é necessário. + +Prazos +------ + +- Temporalidade. +- Otimismo pode prejudicar a estimativa de prazos. +- Metas de pequeno, médio e longo prazo. +- Lembrar das coisas. + +Zeladoria rotativa +------------------ + +Será que funciona? + +Os frutos da organização +------------------------ + +- A quem cabe fruir o valor da organização? +- Se tornar eficiente onde? +- Ativistas como trabalhadores/as nos próprios movimentos. + +Algumas ferramentas! :) +----------------------- + +* [Agendador](https://agendador.sarava.org): encontra datas para compromissos coletivos. +* [Anotador](https://anotador.sarava.org): permite a construção colaborativa de textos. +* [Bate-papo](https://irc.sarava.org): chat criptografado no servidor da Rede Indymedia - http://indymedia.org! +* [Colador](https://colador.sarava.org): compartilha publicamente pedaços de texto de forma anônima. +* [Encurtador](https://e.sarava.org): encurta endereços de internet muito longos, sem vigilância. +* Em breve: [Lembrador Saravento](https://lembrador.sarava.org): emissor coletivo de lembretes. + +Comunicação +----------- + + Cohn's Law: + The more time you spend in reporting on what you are doing, the less + time you have to do anything. Stability is achieved when you spend + all your time reporting on the nothing you are doing. + +Dicas básicas: + + - Comunicação direta, porém não ríspida. + - Diferenças de contexto. + - Lembrar que possivelmente os canais de comunicação serão também canais históricos, ou seja, + ajudarão pessoas no futuro a entender os grupos. Da mesma forma, existe a preocupação com segurança. diff --git a/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. diff --git a/pelican/.gitignore b/pelican/.gitignore new file mode 100644 index 0000000..06a38a6 --- /dev/null +++ b/pelican/.gitignore @@ -0,0 +1,2 @@ +output +pelicanconf.pyc diff --git a/pelican/Makefile b/pelican/Makefile new file mode 100644 index 0000000..45fb995 --- /dev/null +++ b/pelican/Makefile @@ -0,0 +1,37 @@ +# +# This Makefile is free software; you can redistribute it and/or modify it +# under the terms of the GNU General Public License as published by the Free +# Software Foundation; either version 3 of the License, or any later version. +# +# This Makefile is distributed in the hope that it will be useful, but WITHOUT +# ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS +# FOR A PARTICULAR PURPOSE. See the GNU General Public License for more details. +# +# You should have received a copy of the GNU General Public License along with +# this program; if not, write to the Free Software Foundation, Inc., 59 Temple +# Place - Suite 330, Boston, MA 02111-1307, USA +# + +PY?=python +PELICAN?=pelican +PELICANOPTS= +BASEDIR=$(CURDIR) +INPUTDIR=$(BASEDIR)/content +OUTPUTDIR=$(BASEDIR)/output +CONFFILE=$(BASEDIR)/pelicanconf.py + +web: clean + $(PELICAN) $(INPUTDIR) -o $(OUTPUTDIR) -s $(CONFFILE) $(PELICANOPTS) + +web_regenerate: + $(PELICAN) -r $(INPUTDIR) -o $(OUTPUTDIR) -s $(CONFFILE) $(PELICANOPTS) + +web_deploy: + @rsync -avz --delete $(OUTPUTDIR)/ templates:/var/sites/templates/www/ + +clean: + [ ! -d $(OUTPUTDIR) ] || rm -rf $(OUTPUTDIR) + +publish: web web_deploy + +.PHONY: web diff --git a/pelican/content/index.md b/pelican/content/index.md new file mode 100644 index 0000000..e69de29 --- /dev/null +++ b/pelican/content/index.md diff --git a/pelican/pelicanconf.py b/pelican/pelicanconf.py new file mode 100644 index 0000000..c5f6dd3 --- /dev/null +++ b/pelican/pelicanconf.py @@ -0,0 +1,26 @@ +#!/usr/bin/env python +# -*- coding: utf-8 -*- # +from __future__ import unicode_literals + +AUTHOR = u'templates' +SITENAME = u'Templates' +SITEURL = '' + +PATH = 'content' + +TIMEZONE = 'America/Sao_Paulo' + +DEFAULT_LANG = u'pt' + +# Feed generation is usually not desired when developing +FEED_ALL_ATOM = None +CATEGORY_FEED_ATOM = None +TRANSLATION_FEED_ATOM = None +AUTHOR_FEED_ATOM = None +AUTHOR_FEED_RSS = None + +DEFAULT_PAGINATION = False + +RELATIVE_URLS = True + +SUMMARY_MAX_LENGTH = None diff --git a/sphinx/.gitignore b/sphinx/.gitignore new file mode 100644 index 0000000..e35d885 --- /dev/null +++ b/sphinx/.gitignore @@ -0,0 +1 @@ +_build diff --git a/sphinx/Makefile b/sphinx/Makefile new file mode 100644 index 0000000..6283b8e --- /dev/null +++ b/sphinx/Makefile @@ -0,0 +1,160 @@ +# Makefile for Sphinx documentation +# + +# You can set these variables from the command line. +SPHINXOPTS = +SPHINXBUILD = sphinx-build +PAPER = +BUILDDIR = _build + +# Internal variables. +PAPEROPT_a4 = -D latex_paper_size=a4 +PAPEROPT_letter = -D latex_paper_size=letter +ALLSPHINXOPTS = -d $(BUILDDIR)/doctrees $(PAPEROPT_$(PAPER)) $(SPHINXOPTS) . +# the i18n builder cannot share the environment and doctrees with the others +I18NSPHINXOPTS = $(PAPEROPT_$(PAPER)) $(SPHINXOPTS) . + +.PHONY: help clean html dirhtml singlehtml pickle json htmlhelp qthelp devhelp epub latex latexpdf text man changes linkcheck doctest gettext + +help: + @echo "Please use \`make <target>' where <target> is one of" + @echo " html to make standalone HTML files" + @echo " dirhtml to make HTML files named index.html in directories" + @echo " singlehtml to make a single large HTML file" + @echo " pickle to make pickle files" + @echo " json to make JSON files" + @echo " htmlhelp to make HTML files and a HTML help project" + @echo " qthelp to make HTML files and a qthelp project" + @echo " devhelp to make HTML files and a Devhelp project" + @echo " epub to make an epub" + @echo " latex to make LaTeX files, you can set PAPER=a4 or PAPER=letter" + @echo " latexpdf to make LaTeX files and run them through pdflatex" + @echo " text to make text files" + @echo " man to make manual pages" + @echo " texinfo to make Texinfo files" + @echo " info to make Texinfo files and run them through makeinfo" + @echo " gettext to make PO message catalogs" + @echo " changes to make an overview of all changed/added/deprecated items" + @echo " linkcheck to check all external links for integrity" + @echo " doctest to run all doctests embedded in the documentation (if enabled)" + +clean: + -rm -rf $(BUILDDIR)/* + +html: + $(SPHINXBUILD) -b html $(ALLSPHINXOPTS) $(BUILDDIR)/html + @echo + @echo "Build finished. The HTML pages are in $(BUILDDIR)/html." + +dirhtml: + $(SPHINXBUILD) -b dirhtml $(ALLSPHINXOPTS) $(BUILDDIR)/dirhtml + @echo + @echo "Build finished. The HTML pages are in $(BUILDDIR)/dirhtml." + +singlehtml: + $(SPHINXBUILD) -b singlehtml $(ALLSPHINXOPTS) $(BUILDDIR)/singlehtml + @echo + @echo "Build finished. The HTML page is in $(BUILDDIR)/singlehtml." + +pickle: + $(SPHINXBUILD) -b pickle $(ALLSPHINXOPTS) $(BUILDDIR)/pickle + @echo + @echo "Build finished; now you can process the pickle files." + +json: + $(SPHINXBUILD) -b json $(ALLSPHINXOPTS) $(BUILDDIR)/json + @echo + @echo "Build finished; now you can process the JSON files." + +htmlhelp: + $(SPHINXBUILD) -b htmlhelp $(ALLSPHINXOPTS) $(BUILDDIR)/htmlhelp + @echo + @echo "Build finished; now you can run HTML Help Workshop with the" \ + ".hhp project file in $(BUILDDIR)/htmlhelp." + +qthelp: + $(SPHINXBUILD) -b qthelp $(ALLSPHINXOPTS) $(BUILDDIR)/qthelp + @echo + @echo "Build finished; now you can run "qcollectiongenerator" with the" \ + ".qhcp project file in $(BUILDDIR)/qthelp, like this:" + @echo "# qcollectiongenerator $(BUILDDIR)/qthelp/ManualdeSegurana.qhcp" + @echo "To view the help file:" + @echo "# assistant -collectionFile $(BUILDDIR)/qthelp/ManualdeSegurana.qhc" + +devhelp: + $(SPHINXBUILD) -b devhelp $(ALLSPHINXOPTS) $(BUILDDIR)/devhelp + @echo + @echo "Build finished." + @echo "To view the help file:" + @echo "# mkdir -p $$HOME/.local/share/devhelp/ManualdeSegurana" + @echo "# ln -s $(BUILDDIR)/devhelp $$HOME/.local/share/devhelp/ManualdeSegurana" + @echo "# devhelp" + +epub: + $(SPHINXBUILD) -b epub $(ALLSPHINXOPTS) $(BUILDDIR)/epub + @echo + @echo "Build finished. The epub file is in $(BUILDDIR)/epub." + +latex: + $(SPHINXBUILD) -b latex $(ALLSPHINXOPTS) $(BUILDDIR)/latex + @echo + @echo "Build finished; the LaTeX files are in $(BUILDDIR)/latex." + @echo "Run \`make' in that directory to run these through (pdf)latex" \ + "(use \`make latexpdf' here to do that automatically)." + +latexpdf: + $(SPHINXBUILD) -b latex $(ALLSPHINXOPTS) $(BUILDDIR)/latex + @echo "Running LaTeX files through pdflatex..." + $(MAKE) -C $(BUILDDIR)/latex all-pdf + @echo "pdflatex finished; the PDF files are in $(BUILDDIR)/latex." + +text: + $(SPHINXBUILD) -b text $(ALLSPHINXOPTS) $(BUILDDIR)/text + @echo + @echo "Build finished. The text files are in $(BUILDDIR)/text." + +man: + $(SPHINXBUILD) -b man $(ALLSPHINXOPTS) $(BUILDDIR)/man + @echo + @echo "Build finished. The manual pages are in $(BUILDDIR)/man." + +texinfo: + $(SPHINXBUILD) -b texinfo $(ALLSPHINXOPTS) $(BUILDDIR)/texinfo + @echo + @echo "Build finished. The Texinfo files are in $(BUILDDIR)/texinfo." + @echo "Run \`make' in that directory to run these through makeinfo" \ + "(use \`make info' here to do that automatically)." + +info: + $(SPHINXBUILD) -b texinfo $(ALLSPHINXOPTS) $(BUILDDIR)/texinfo + @echo "Running Texinfo files through makeinfo..." + make -C $(BUILDDIR)/texinfo info + @echo "makeinfo finished; the Info files are in $(BUILDDIR)/texinfo." + +gettext: + $(SPHINXBUILD) -b gettext $(I18NSPHINXOPTS) $(BUILDDIR)/locale + @echo + @echo "Build finished. The message catalogs are in $(BUILDDIR)/locale." + +changes: + $(SPHINXBUILD) -b changes $(ALLSPHINXOPTS) $(BUILDDIR)/changes + @echo + @echo "The overview file is in $(BUILDDIR)/changes." + +linkcheck: + $(SPHINXBUILD) -b linkcheck $(ALLSPHINXOPTS) $(BUILDDIR)/linkcheck + @echo + @echo "Link check complete; look for any errors in the above output " \ + "or in $(BUILDDIR)/linkcheck/output.txt." + +doctest: + $(SPHINXBUILD) -b doctest $(ALLSPHINXOPTS) $(BUILDDIR)/doctest + @echo "Testing of doctests in the sources finished, look at the " \ + "results in $(BUILDDIR)/doctest/output.txt." + +web: clean html + +web_deploy: + @rsync -avz --delete _build/html/ templates/var/sites/templates/www/ + +publish: web web_deploy diff --git a/sphinx/_static/.empty b/sphinx/_static/.empty new file mode 100644 index 0000000..e69de29 --- /dev/null +++ b/sphinx/_static/.empty diff --git a/sphinx/conf.py b/sphinx/conf.py new file mode 100644 index 0000000..6bc7b9a --- /dev/null +++ b/sphinx/conf.py @@ -0,0 +1,286 @@ +# -*- coding: utf-8 -*- +# +# Manual de Segurança documentation build configuration file, created by +# sphinx-quickstart on Sat Oct 17 11:16:26 2015. +# +# This file is execfile()d with the current directory set to its containing dir. +# +# Note that not all possible configuration values are present in this +# autogenerated file. +# +# All configuration values have a default; values that are commented out +# serve to show the default. + +import sys, os + +# If extensions (or modules to document with autodoc) are in another directory, +# add these directories to sys.path here. If the directory is relative to the +# documentation root, use os.path.abspath to make it absolute, like shown here. +#sys.path.insert(0, os.path.abspath('.')) + +# -- General configuration ----------------------------------------------------- + +# If your documentation needs a minimal Sphinx version, state it here. +#needs_sphinx = '1.0' + +# Add any Sphinx extension module names here, as strings. They can be extensions +# coming with Sphinx (named 'sphinx.ext.*') or your custom ones. +extensions = [] + +# Add any paths that contain templates here, relative to this directory. +templates_path = ['_templates'] + +# The suffix of source filenames. +source_suffix = '.rst' + +# The encoding of source files. +#source_encoding = 'utf-8-sig' + +# The master toctree document. +master_doc = 'index' + +# General information about the project. +project = u'Templates' +copyright = u'2016, Templates' + +# The version info for the project you're documenting, acts as replacement for +# |version| and |release|, also used in various other places throughout the +# built documents. +# +# The short X.Y version. +version = '0.1' +# The full version, including alpha/beta/rc tags. +release = '0.1' + +# The language for content autogenerated by Sphinx. Refer to documentation +# for a list of supported languages. +#language = None + +# There are two options for replacing |today|: either, you set today to some +# non-false value, then it is used: +#today = '' +# Else, today_fmt is used as the format for a strftime call. +#today_fmt = '%B %d, %Y' + +# List of patterns, relative to source directory, that match files and +# directories to ignore when looking for source files. +exclude_patterns = ['_build', '_themes'] + +# The reST default role (used for this markup: `text`) to use for all documents. +#default_role = None + +# If true, '()' will be appended to :func: etc. cross-reference text. +#add_function_parentheses = True + +# If true, the current module name will be prepended to all description +# unit titles (such as .. function::). +#add_module_names = True + +# If true, sectionauthor and moduleauthor directives will be shown in the +# output. They are ignored by default. +#show_authors = False + +# The name of the Pygments (syntax highlighting) style to use. +pygments_style = 'sphinx' + +# A list of ignored prefixes for module index sorting. +#modindex_common_prefix = [] + + +# -- Options for HTML output --------------------------------------------------- + +# The theme to use for HTML and HTML Help pages. See the documentation for +# a list of builtin themes. +#html_theme = "sphinx_rtd_theme" +#html_theme_path = ["_themes/sphinx_rtd_theme", ] +html_theme = 'default' + +# Theme options are theme-specific and customize the look and feel of a theme +# further. For a list of options available for each theme, see the +# documentation. +#html_theme_options = {} + +# Add any paths that contain custom themes here, relative to this directory. +#html_theme_path = [] + +# The name for this set of Sphinx documents. If None, it defaults to +# "<project> v<release> documentation". +#html_title = None + +# A shorter title for the navigation bar. Default is the same as html_title. +#html_short_title = None + +# The name of an image file (relative to this directory) to place at the top +# of the sidebar. +#html_logo = None + +# The name of an image file (within the static path) to use as favicon of the +# docs. This file should be a Windows icon file (.ico) being 16x16 or 32x32 +# pixels large. +#html_favicon = None + +# Add any paths that contain custom static files (such as style sheets) here, +# relative to this directory. They are copied after the builtin static files, +# so a file named "default.css" will overwrite the builtin "default.css". +html_static_path = ['_static'] + +# If not '', a 'Last updated on:' timestamp is inserted at every page bottom, +# using the given strftime format. +#html_last_updated_fmt = '%b %d, %Y' + +# If true, SmartyPants will be used to convert quotes and dashes to +# typographically correct entities. +#html_use_smartypants = True + +# Custom sidebar templates, maps document names to template names. +#html_sidebars = {} + +# Additional templates that should be rendered to pages, maps page names to +# template names. +#html_additional_pages = {} + +# If false, no module index is generated. +#html_domain_indices = True + +# If false, no index is generated. +#html_use_index = True + +# If true, the index is split into individual pages for each letter. +#html_split_index = False + +# If true, links to the reST sources are added to the pages. +#html_show_sourcelink = True + +# If true, "Created using Sphinx" is shown in the HTML footer. Default is True. +#html_show_sphinx = True + +# If true, "(C) Copyright ..." is shown in the HTML footer. Default is True. +#html_show_copyright = True + +# If true, an OpenSearch description file will be output, and all pages will +# contain a <link> tag referring to it. The value of this option must be the +# base URL from which the finished HTML is served. +#html_use_opensearch = '' + +# This is the file name suffix for HTML files (e.g. ".xhtml"). +#html_file_suffix = None + +# Output file base name for HTML help builder. +htmlhelp_basename = 'templates' + +# -- Options for LaTeX output -------------------------------------------------- + +latex_elements = { +# The paper size ('letterpaper' or 'a4paper'). +#'papersize': 'letterpaper', + +# The font size ('10pt', '11pt' or '12pt'). +#'pointsize': '10pt', + +# Additional stuff for the LaTeX preamble. +#'preamble': '', +} + +# Grouping the document tree into LaTeX files. List of tuples +# (source start file, target name, title, author, documentclass [howto/manual]). +latex_documents = [ + ('index', 'templates.tex', u'Templates', + u'Templates', 'templates'), +] + +# The name of an image file (relative to this directory) to place at the top of +# the title page. +#latex_logo = None + +# For "manual" documents, if this is true, then toplevel headings are parts, +# not chapters. +#latex_use_parts = False + +# If true, show page references after internal links. +#latex_show_pagerefs = False + +# If true, show URL addresses after external links. +#latex_show_urls = False + +# Documents to append as an appendix to all manuals. +#latex_appendices = [] + +# If false, no module index is generated. +#latex_domain_indices = True + + +# -- Options for manual page output -------------------------------------------- + +# One entry per manual page. List of tuples +# (source start file, name, description, authors, manual section). +man_pages = [ + ('index', 'templates', u'Templates', + [u'Templates'], 1) +] + +# If true, show URL addresses after external links. +#man_show_urls = False + + +# -- Options for Texinfo output ------------------------------------------------ + +# Grouping the document tree into Texinfo files. List of tuples +# (source start file, target name, title, author, +# dir menu entry, description, category) +texinfo_documents = [ + ('index', 'templates', u'Templates', + u'Templates', 'templates', 'One line description of project.', + 'Miscellaneous'), +] + +# Documents to append as an appendix to all manuals. +#texinfo_appendices = [] + +# If false, no module index is generated. +#texinfo_domain_indices = True + +# How to display URL addresses: 'footnote', 'no', or 'inline'. +#texinfo_show_urls = 'footnote' + + +# -- Options for Epub output --------------------------------------------------- + +# Bibliographic Dublin Core info. +epub_title = u'Templates' +epub_author = u'Templates' +epub_publisher = u'Templates' +epub_copyright = u'2016, Templates' + +# The language of the text. It defaults to the language option +# or en if the language is not set. +#epub_language = '' + +# The scheme of the identifier. Typical schemes are ISBN or URL. +#epub_scheme = '' + +# The unique identifier of the text. This can be a ISBN number +# or the project homepage. +#epub_identifier = '' + +# A unique identification for the text. +#epub_uid = '' + +# A tuple containing the cover image and cover page html template filenames. +#epub_cover = () + +# HTML files that should be inserted before the pages created by sphinx. +# The format is a list of tuples containing the path and title. +#epub_pre_files = [] + +# HTML files shat should be inserted after the pages created by sphinx. +# The format is a list of tuples containing the path and title. +#epub_post_files = [] + +# A list of files that should not be packed into the epub file. +#epub_exclude_files = [] + +# The depth of the table of contents in toc.ncx. +#epub_tocdepth = 3 + +# Allow duplicate toc entries. +#epub_tocdup = True |