From 2eb70c2966be257e6b90fe7b275405a17c6b11b7 Mon Sep 17 00:00:00 2001 From: Silvio Rhatto Date: Sun, 1 Oct 2017 17:17:12 -0300 Subject: Change markdown extension to .md --- casa.md | 3 + casa.mdwn | 3 - casa/checklist.md | 25 ++ casa/checklist.mdwn | 25 -- casa/procedimentos.md | 69 ++++++ casa/procedimentos.mdwn | 69 ------ casa/regras.md | 54 +++++ casa/regras.mdwn | 54 ----- coletivo.md | 3 + coletivo.mdwn | 3 - coletivo/basico.md | 17 ++ coletivo/basico.mdwn | 17 -- coletivo/coletivo.md | 62 +++++ coletivo/coletivo.mdwn | 62 ----- coletivo/comunicacao.md | 3 + coletivo/comunicacao.mdwn | 3 - coletivo/comunicacao/acl.md | 37 +++ coletivo/comunicacao/acl.mdwn | 37 --- coletivo/comunicacao/archive.md | 12 + coletivo/comunicacao/archive.mdwn | 12 - coletivo/comunicacao/backup.md | 31 +++ coletivo/comunicacao/backup.mdwn | 31 --- coletivo/comunicacao/chat.md | 38 ++++ coletivo/comunicacao/chat.mdwn | 38 ---- coletivo/comunicacao/infosec.md | 73 ++++++ coletivo/comunicacao/infosec.mdwn | 73 ------ coletivo/comunicacao/license.md | 136 +++++++++++ coletivo/comunicacao/license.mdwn | 136 ----------- coletivo/comunicacao/list.md | 55 +++++ coletivo/comunicacao/list.mdwn | 55 ----- coletivo/comunicacao/transparency.md | 42 ++++ coletivo/comunicacao/transparency.mdwn | 42 ---- coletivo/comunicacao/vizinhanca.md | 49 ++++ coletivo/comunicacao/vizinhanca.mdwn | 49 ---- coletivo/contabilidade.md | 27 +++ coletivo/contabilidade.mdwn | 27 --- coletivo/contabilidade/criterios.md | 120 ++++++++++ coletivo/contabilidade/criterios.mdwn | 120 ---------- coletivo/contabilidade/planejamento.md | 17 ++ coletivo/contabilidade/planejamento.mdwn | 17 -- coletivo/interpretacoes.md | 378 +++++++++++++++++++++++++++++++ coletivo/interpretacoes.mdwn | 378 ------------------------------- coletivo/misc.md | 3 + coletivo/misc.mdwn | 3 - coletivo/misc/ata.md | 22 ++ coletivo/misc/ata.mdwn | 22 -- coletivo/misc/atualizacao.md | 25 ++ coletivo/misc/atualizacao.mdwn | 25 -- coletivo/misc/autorizacao.md | 31 +++ coletivo/misc/autorizacao.mdwn | 31 --- coletivo/misc/debate.md | 24 ++ coletivo/misc/debate.mdwn | 24 -- coletivo/misc/grupos.md | 55 +++++ coletivo/misc/grupos.mdwn | 55 ----- coletivo/misc/rollcall.md | 13 ++ coletivo/misc/rollcall.mdwn | 13 -- coletivo/organizacao.md | 102 +++++++++ coletivo/organizacao.mdwn | 102 --------- coletivo/participacao.md | 83 +++++++ coletivo/participacao.mdwn | 83 ------- coletivo/responsabilizacao.md | 15 ++ coletivo/responsabilizacao.mdwn | 15 -- english.md | 3 + english.mdwn | 3 - english/network.md | 80 +++++++ english/network.mdwn | 80 ------- english/organization.md | 124 ++++++++++ english/organization.mdwn | 124 ---------- english/provider.md | 3 + english/provider.mdwn | 3 - english/provider/hosting.md | 3 + english/provider/hosting.mdwn | 3 - english/provider/hosting/letter.md | 59 +++++ english/provider/hosting/letter.mdwn | 59 ----- english/provider/hosting/policy.md | 45 ++++ english/provider/hosting/policy.mdwn | 45 ---- english/provider/hosting/refusal.md | 22 ++ english/provider/hosting/refusal.mdwn | 22 -- english/provider/hosting/terms.md | 92 ++++++++ english/provider/hosting/terms.mdwn | 92 -------- etica.md | 3 + etica.mdwn | 3 - etica/coletiva.md | 48 ++++ etica/coletiva.mdwn | 48 ---- etica/pessoal.md | 110 +++++++++ etica/pessoal.mdwn | 110 --------- ikiwiki/index.md | 3 + ikiwiki/index.mdwn | 3 - ikiwiki/sitemap.md | 3 + ikiwiki/sitemap.mdwn | 3 - ikiwiki/timeline.md | 3 + ikiwiki/timeline.mdwn | 3 - index.md | 15 ++ index.mdwn | 15 -- mensagens.md | 5 + mensagens.mdwn | 5 - mensagens/certs.md | 27 +++ mensagens/certs.mdwn | 27 --- mensagens/downtime.md | 37 +++ mensagens/downtime.mdwn | 37 --- muamba.md | 45 ++++ muamba.mdwn | 45 ---- muamba/clube.md | 59 +++++ muamba/clube.mdwn | 59 ----- muamba/emprestimos.md | 19 ++ muamba/emprestimos.mdwn | 19 -- orfanato.md | 24 ++ orfanato.mdwn | 24 -- organizacao.md | 106 +++++++++ organizacao.mdwn | 106 --------- pessoal.md | 145 ++++++++++++ pessoal.mdwn | 145 ------------ pessoal/basico.md | 89 ++++++++ pessoal/basico.mdwn | 89 -------- pessoal/contabilidade.md | 4 + pessoal/contabilidade.mdwn | 4 - pessoal/saude.md | 7 + pessoal/saude.mdwn | 7 - project.md | 21 ++ project.mdwn | 21 -- provedor.md | 3 + provedor.mdwn | 3 - provedor/backups.md | 36 +++ provedor/backups.mdwn | 36 --- provedor/backups/entrega.md | 80 +++++++ provedor/backups/entrega.mdwn | 80 ------- provedor/cert.md | 123 ++++++++++ provedor/cert.mdwn | 123 ---------- provedor/hospedagem.md | 39 ++++ provedor/hospedagem.mdwn | 39 ---- provedor/hospedagem/carta.md | 71 ++++++ provedor/hospedagem/carta.mdwn | 71 ------ provedor/hospedagem/plataforma.md | 27 +++ provedor/hospedagem/plataforma.mdwn | 27 --- provedor/hospedagem/politica.md | 47 ++++ provedor/hospedagem/politica.mdwn | 47 ---- provedor/hospedagem/recusa.md | 26 +++ provedor/hospedagem/recusa.mdwn | 26 --- provedor/hospedagem/termo.md | 105 +++++++++ provedor/hospedagem/termo.mdwn | 105 --------- provedor/servidor.md | 49 ++++ provedor/servidor.mdwn | 49 ---- provedor/sistemas.md | 41 ++++ provedor/sistemas.mdwn | 41 ---- provedor/sistemas/dns.md | 16 ++ provedor/sistemas/dns.mdwn | 16 -- provedor/sistemas/dominios.md | 26 +++ provedor/sistemas/dominios.mdwn | 26 --- rede.md | 82 +++++++ rede.mdwn | 82 ------- todo.md | 3 + todo.mdwn | 3 - travel.md | 16 ++ travel.mdwn | 16 -- travel/checklist.md | 5 + travel/checklist.mdwn | 5 - travel/checklist/basico.md | 16 ++ travel/checklist/basico.mdwn | 16 -- travel/checklist/carteira.md | 13 ++ travel/checklist/carteira.mdwn | 13 -- travel/checklist/completa.md | 21 ++ travel/checklist/completa.mdwn | 21 -- travel/checklist/expedicao.md | 23 ++ travel/checklist/expedicao.mdwn | 23 -- travel/checklist/fuga.md | 8 + travel/checklist/fuga.mdwn | 8 - travel/checklist/minima.md | 46 ++++ travel/checklist/minima.mdwn | 46 ---- travel/checklist/urbano.md | 24 ++ travel/checklist/urbano.mdwn | 24 -- travel/preparacao.md | 34 +++ travel/preparacao.mdwn | 34 --- usando.md | 29 +++ usando.mdwn | 29 --- 174 files changed, 3837 insertions(+), 3837 deletions(-) create mode 100644 casa.md delete mode 100644 casa.mdwn create mode 100644 casa/checklist.md delete mode 100644 casa/checklist.mdwn create mode 100644 casa/procedimentos.md delete mode 100644 casa/procedimentos.mdwn create mode 100644 casa/regras.md delete mode 100644 casa/regras.mdwn create mode 100644 coletivo.md delete mode 100644 coletivo.mdwn create mode 100644 coletivo/basico.md delete mode 100644 coletivo/basico.mdwn create mode 100644 coletivo/coletivo.md delete mode 100644 coletivo/coletivo.mdwn create mode 100644 coletivo/comunicacao.md delete mode 100644 coletivo/comunicacao.mdwn create mode 100644 coletivo/comunicacao/acl.md delete mode 100644 coletivo/comunicacao/acl.mdwn create mode 100644 coletivo/comunicacao/archive.md delete mode 100644 coletivo/comunicacao/archive.mdwn create mode 100644 coletivo/comunicacao/backup.md delete mode 100644 coletivo/comunicacao/backup.mdwn create mode 100644 coletivo/comunicacao/chat.md delete mode 100644 coletivo/comunicacao/chat.mdwn create mode 100644 coletivo/comunicacao/infosec.md delete mode 100644 coletivo/comunicacao/infosec.mdwn create mode 100644 coletivo/comunicacao/license.md delete mode 100644 coletivo/comunicacao/license.mdwn create mode 100644 coletivo/comunicacao/list.md delete mode 100644 coletivo/comunicacao/list.mdwn create mode 100644 coletivo/comunicacao/transparency.md delete mode 100644 coletivo/comunicacao/transparency.mdwn create mode 100644 coletivo/comunicacao/vizinhanca.md delete mode 100644 coletivo/comunicacao/vizinhanca.mdwn create mode 100644 coletivo/contabilidade.md delete mode 100644 coletivo/contabilidade.mdwn create mode 100644 coletivo/contabilidade/criterios.md delete mode 100644 coletivo/contabilidade/criterios.mdwn create mode 100644 coletivo/contabilidade/planejamento.md delete mode 100644 coletivo/contabilidade/planejamento.mdwn create mode 100644 coletivo/interpretacoes.md delete mode 100644 coletivo/interpretacoes.mdwn create mode 100644 coletivo/misc.md delete mode 100644 coletivo/misc.mdwn create mode 100644 coletivo/misc/ata.md delete mode 100644 coletivo/misc/ata.mdwn create mode 100644 coletivo/misc/atualizacao.md delete mode 100644 coletivo/misc/atualizacao.mdwn create mode 100644 coletivo/misc/autorizacao.md delete mode 100644 coletivo/misc/autorizacao.mdwn create mode 100644 coletivo/misc/debate.md delete mode 100644 coletivo/misc/debate.mdwn create mode 100644 coletivo/misc/grupos.md delete mode 100644 coletivo/misc/grupos.mdwn create mode 100644 coletivo/misc/rollcall.md delete mode 100644 coletivo/misc/rollcall.mdwn create mode 100644 coletivo/organizacao.md delete mode 100644 coletivo/organizacao.mdwn create mode 100644 coletivo/participacao.md delete mode 100644 coletivo/participacao.mdwn create mode 100644 coletivo/responsabilizacao.md delete mode 100644 coletivo/responsabilizacao.mdwn create mode 100644 english.md delete mode 100644 english.mdwn create mode 100644 english/network.md delete mode 100644 english/network.mdwn create mode 100644 english/organization.md delete mode 100644 english/organization.mdwn create mode 100644 english/provider.md delete mode 100644 english/provider.mdwn create mode 100644 english/provider/hosting.md delete mode 100644 english/provider/hosting.mdwn create mode 100644 english/provider/hosting/letter.md delete mode 100644 english/provider/hosting/letter.mdwn create mode 100644 english/provider/hosting/policy.md delete mode 100644 english/provider/hosting/policy.mdwn create mode 100644 english/provider/hosting/refusal.md delete mode 100644 english/provider/hosting/refusal.mdwn create mode 100644 english/provider/hosting/terms.md delete mode 100644 english/provider/hosting/terms.mdwn create mode 100644 etica.md delete mode 100644 etica.mdwn create mode 100644 etica/coletiva.md delete mode 100644 etica/coletiva.mdwn create mode 100644 etica/pessoal.md delete mode 100644 etica/pessoal.mdwn create mode 100644 ikiwiki/index.md delete mode 100644 ikiwiki/index.mdwn create mode 100644 ikiwiki/sitemap.md delete mode 100644 ikiwiki/sitemap.mdwn create mode 100644 ikiwiki/timeline.md delete mode 100644 ikiwiki/timeline.mdwn create mode 100644 index.md delete mode 100644 index.mdwn create mode 100644 mensagens.md delete mode 100644 mensagens.mdwn create mode 100644 mensagens/certs.md delete mode 100644 mensagens/certs.mdwn create mode 100644 mensagens/downtime.md delete mode 100644 mensagens/downtime.mdwn create mode 100644 muamba.md delete mode 100644 muamba.mdwn create mode 100644 muamba/clube.md delete mode 100644 muamba/clube.mdwn create mode 100644 muamba/emprestimos.md delete mode 100644 muamba/emprestimos.mdwn create mode 100644 orfanato.md delete mode 100644 orfanato.mdwn create mode 100644 organizacao.md delete mode 100644 organizacao.mdwn create mode 100644 pessoal.md delete mode 100644 pessoal.mdwn create mode 100644 pessoal/basico.md delete mode 100644 pessoal/basico.mdwn create mode 100644 pessoal/contabilidade.md delete mode 100644 pessoal/contabilidade.mdwn create mode 100644 pessoal/saude.md delete mode 100644 pessoal/saude.mdwn create mode 100644 project.md delete mode 100644 project.mdwn create mode 100644 provedor.md delete mode 100644 provedor.mdwn create mode 100644 provedor/backups.md delete mode 100644 provedor/backups.mdwn create mode 100644 provedor/backups/entrega.md delete mode 100644 provedor/backups/entrega.mdwn create mode 100644 provedor/cert.md delete mode 100644 provedor/cert.mdwn create mode 100644 provedor/hospedagem.md delete mode 100644 provedor/hospedagem.mdwn create mode 100644 provedor/hospedagem/carta.md delete mode 100644 provedor/hospedagem/carta.mdwn create mode 100644 provedor/hospedagem/plataforma.md delete mode 100644 provedor/hospedagem/plataforma.mdwn create mode 100644 provedor/hospedagem/politica.md delete mode 100644 provedor/hospedagem/politica.mdwn create mode 100644 provedor/hospedagem/recusa.md delete mode 100644 provedor/hospedagem/recusa.mdwn create mode 100644 provedor/hospedagem/termo.md delete mode 100644 provedor/hospedagem/termo.mdwn create mode 100644 provedor/servidor.md delete mode 100644 provedor/servidor.mdwn create mode 100644 provedor/sistemas.md delete mode 100644 provedor/sistemas.mdwn create mode 100644 provedor/sistemas/dns.md delete mode 100644 provedor/sistemas/dns.mdwn create mode 100644 provedor/sistemas/dominios.md delete mode 100644 provedor/sistemas/dominios.mdwn create mode 100644 rede.md delete mode 100644 rede.mdwn create mode 100644 todo.md delete mode 100644 todo.mdwn create mode 100644 travel.md delete mode 100644 travel.mdwn create mode 100644 travel/checklist.md delete mode 100644 travel/checklist.mdwn create mode 100644 travel/checklist/basico.md delete mode 100644 travel/checklist/basico.mdwn create mode 100644 travel/checklist/carteira.md delete mode 100644 travel/checklist/carteira.mdwn create mode 100644 travel/checklist/completa.md delete mode 100644 travel/checklist/completa.mdwn create mode 100644 travel/checklist/expedicao.md delete mode 100644 travel/checklist/expedicao.mdwn create mode 100644 travel/checklist/fuga.md delete mode 100644 travel/checklist/fuga.mdwn create mode 100644 travel/checklist/minima.md delete mode 100644 travel/checklist/minima.mdwn create mode 100644 travel/checklist/urbano.md delete mode 100644 travel/checklist/urbano.mdwn create mode 100644 travel/preparacao.md delete mode 100644 travel/preparacao.mdwn create mode 100644 usando.md delete mode 100644 usando.mdwn diff --git a/casa.md b/casa.md new file mode 100644 index 0000000..7ec17dd --- /dev/null +++ b/casa.md @@ -0,0 +1,3 @@ +[[!meta title="Casa & Jardim"]] + +[[!map pages="page(casa*)" show="title"]] diff --git a/casa.mdwn b/casa.mdwn deleted file mode 100644 index 7ec17dd..0000000 --- a/casa.mdwn +++ /dev/null @@ -1,3 +0,0 @@ -[[!meta title="Casa & Jardim"]] - -[[!map pages="page(casa*)" show="title"]] diff --git a/casa/checklist.md b/casa/checklist.md new file mode 100644 index 0000000..82b3563 --- /dev/null +++ b/casa/checklist.md @@ -0,0 +1,25 @@ +[[!meta title="Checklist Doméstico Básico"]] + +Pagamentos mensais +------------------ + +* Água. +* Luz. +* Gás. +* Internet. + +Organização +----------- + +* Água potável e comida para duas semanas. +* Rádio portável a pilha ou manivela. +* Kit médico. +* Lista de contatos impressa. +* Caixa de ferramentas. +* OpenHouse. +* Comissão aperiódica de reforma e descarte. + +Referências +----------- + +* [What are the essential items to stockpile in the face of impending nuclear disaster?](http://www.newstatesman.com/politics/uk/2017/08/what-are-essential-items-stockpile-face-impending-nuclear-disaster). diff --git a/casa/checklist.mdwn b/casa/checklist.mdwn deleted file mode 100644 index 82b3563..0000000 --- a/casa/checklist.mdwn +++ /dev/null @@ -1,25 +0,0 @@ -[[!meta title="Checklist Doméstico Básico"]] - -Pagamentos mensais ------------------- - -* Água. -* Luz. -* Gás. -* Internet. - -Organização ------------ - -* Água potável e comida para duas semanas. -* Rádio portável a pilha ou manivela. -* Kit médico. -* Lista de contatos impressa. -* Caixa de ferramentas. -* OpenHouse. -* Comissão aperiódica de reforma e descarte. - -Referências ------------ - -* [What are the essential items to stockpile in the face of impending nuclear disaster?](http://www.newstatesman.com/politics/uk/2017/08/what-are-essential-items-stockpile-face-impending-nuclear-disaster). diff --git a/casa/procedimentos.md b/casa/procedimentos.md new file mode 100644 index 0000000..45d0b0d --- /dev/null +++ b/casa/procedimentos.md @@ -0,0 +1,69 @@ +[[!meta title="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 + +Como forrar a área de trabalho +------------------------------ + +- Lonas presas com fita adesiva no chão +- Fazer um "tapete" contínuo com um rolo de saco de livo grande +- Usar uma bandeja para fazer cimento + +Recomendações para jardins +-------------------------- + +- Não usar o rastelo para varrer piso. +- Tirar folhas velhas? +- Podar plantas? Quais? + +Recomendações sobre o uso de ferramentas +---------------------------------------- + +- Boa conservação. +- Não manusear com as mãos sujas. +- Limpar após o uso. +- Não forçá-las. +- Não misturar as ferramentas da casa com as de terceiros. + +Orçamentos +---------- + +- Nenhum trabalho pode começar sem a aprovação de um orçamento. +- Orçamentos devem ter prazo. +- Acertos podem ser feitos após o término dos serviços para compensar + excesso de trabalho, mas estes não podem passar muito do orçamento + acordado. + +Recomendações para louça +------------------------ + +- Reusar louça que está secando. + +Almoxarifado +------------ + +- Empilhado. +- Enfileirado. +- Não esconder itens uns atrás dos outros. +- Estoque (pode conter duplicatas) versus armário de coisas em uso. +- Itens do mesmo tipo no mesmo lugar. diff --git a/casa/procedimentos.mdwn b/casa/procedimentos.mdwn deleted file mode 100644 index 45d0b0d..0000000 --- a/casa/procedimentos.mdwn +++ /dev/null @@ -1,69 +0,0 @@ -[[!meta title="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 - -Como forrar a área de trabalho ------------------------------- - -- Lonas presas com fita adesiva no chão -- Fazer um "tapete" contínuo com um rolo de saco de livo grande -- Usar uma bandeja para fazer cimento - -Recomendações para jardins --------------------------- - -- Não usar o rastelo para varrer piso. -- Tirar folhas velhas? -- Podar plantas? Quais? - -Recomendações sobre o uso de ferramentas ----------------------------------------- - -- Boa conservação. -- Não manusear com as mãos sujas. -- Limpar após o uso. -- Não forçá-las. -- Não misturar as ferramentas da casa com as de terceiros. - -Orçamentos ----------- - -- Nenhum trabalho pode começar sem a aprovação de um orçamento. -- Orçamentos devem ter prazo. -- Acertos podem ser feitos após o término dos serviços para compensar - excesso de trabalho, mas estes não podem passar muito do orçamento - acordado. - -Recomendações para louça ------------------------- - -- Reusar louça que está secando. - -Almoxarifado ------------- - -- Empilhado. -- Enfileirado. -- Não esconder itens uns atrás dos outros. -- Estoque (pode conter duplicatas) versus armário de coisas em uso. -- Itens do mesmo tipo no mesmo lugar. diff --git a/casa/regras.md b/casa/regras.md new file mode 100644 index 0000000..04302a1 --- /dev/null +++ b/casa/regras.md @@ -0,0 +1,54 @@ +[[!meta title="Regras Domésticas"]] + +* Regras genéricas de convívio a serem combinadas caso a caso. +* Elas podem ser orais ou escritas. Caso escritas, podem ser + afixadas em locais específicos da casa, como por exemplo + como lembretes em locais especiais (por exemplo sobre lavar + a louça num local próximo à pia). + +Básico +------ + +* Trabalho é dividido para não haver exploração. +* Deixe as coisas num estado melhor do que as encontrou. +* Se quer limpar menos, suje menos! + +Definições +---------- + +* Sobre frituras. +* Andar de sapatos dentro de casa. +* Bagunça dentro e fora do quarto. +* Compartilhamento de material de higiene. +* Padrão de lavagem de panelas para aumentar suas conservação. +* Evitar abrir produtos que já possuem outras embalagens abertas. +* Manter ambiente limpo e organizado para evitar trabalho excessivo. + +Limpeza +------- + +Modos de limpeza: + +* Mutirão coletivo periódico. +* Revezamento semanal periódico. +* Coisas largadas por aí estão sujeitas a serem repostas no lugar! + +Louça: + +* Lave o que sujou + 1. +* Secar bem a louça e guardá-la quando possível, evitando acúmulo. +* Deixar esponja seca e sem sabão. +* Deixar pia e ralo limpos para não entupir. + +Mantimentos +----------- + +* Comprar periódicas em atacadões. +* Compras semanais de frutas, verduras e legumes. + +Social +------ + +* Aluguel temporário. +* Hospedagem solidária. +* [Couchsurfing](https://www.couchsurfing.com)? diff --git a/casa/regras.mdwn b/casa/regras.mdwn deleted file mode 100644 index 04302a1..0000000 --- a/casa/regras.mdwn +++ /dev/null @@ -1,54 +0,0 @@ -[[!meta title="Regras Domésticas"]] - -* Regras genéricas de convívio a serem combinadas caso a caso. -* Elas podem ser orais ou escritas. Caso escritas, podem ser - afixadas em locais específicos da casa, como por exemplo - como lembretes em locais especiais (por exemplo sobre lavar - a louça num local próximo à pia). - -Básico ------- - -* Trabalho é dividido para não haver exploração. -* Deixe as coisas num estado melhor do que as encontrou. -* Se quer limpar menos, suje menos! - -Definições ----------- - -* Sobre frituras. -* Andar de sapatos dentro de casa. -* Bagunça dentro e fora do quarto. -* Compartilhamento de material de higiene. -* Padrão de lavagem de panelas para aumentar suas conservação. -* Evitar abrir produtos que já possuem outras embalagens abertas. -* Manter ambiente limpo e organizado para evitar trabalho excessivo. - -Limpeza -------- - -Modos de limpeza: - -* Mutirão coletivo periódico. -* Revezamento semanal periódico. -* Coisas largadas por aí estão sujeitas a serem repostas no lugar! - -Louça: - -* Lave o que sujou + 1. -* Secar bem a louça e guardá-la quando possível, evitando acúmulo. -* Deixar esponja seca e sem sabão. -* Deixar pia e ralo limpos para não entupir. - -Mantimentos ------------ - -* Comprar periódicas em atacadões. -* Compras semanais de frutas, verduras e legumes. - -Social ------- - -* Aluguel temporário. -* Hospedagem solidária. -* [Couchsurfing](https://www.couchsurfing.com)? diff --git a/coletivo.md b/coletivo.md new file mode 100644 index 0000000..a0c2e23 --- /dev/null +++ b/coletivo.md @@ -0,0 +1,3 @@ +[[!meta title="Coletivo"]] + +[[!map pages="page(coletivo*)" show="title"]] diff --git a/coletivo.mdwn b/coletivo.mdwn deleted file mode 100644 index a0c2e23..0000000 --- a/coletivo.mdwn +++ /dev/null @@ -1,3 +0,0 @@ -[[!meta title="Coletivo"]] - -[[!map pages="page(coletivo*)" show="title"]] diff --git a/coletivo/basico.md b/coletivo/basico.md new file mode 100644 index 0000000..e27b4a7 --- /dev/null +++ b/coletivo/basico.md @@ -0,0 +1,17 @@ +[[!meta title="Checklist Básico"]] + +O que um grupo precisa em geral para funcionar: + +* Plataforma de comunicação. +* Sistema de acompanhamento de tarefas. +* [Protocolos](https://protocolos.fluxo.info) de operação! + +Fluxo de trabalho: + +* Reuniões periódicas de trabalho coletivo: pesquisa, desenvolvimento, implementação, manutenção e auditoria. + +Opcional: + +* Site e canais de contato públicos. +* Licença de distribuição de conteúdo. +* Termos de serviço e política de privacidade. diff --git a/coletivo/basico.mdwn b/coletivo/basico.mdwn deleted file mode 100644 index e27b4a7..0000000 --- a/coletivo/basico.mdwn +++ /dev/null @@ -1,17 +0,0 @@ -[[!meta title="Checklist Básico"]] - -O que um grupo precisa em geral para funcionar: - -* Plataforma de comunicação. -* Sistema de acompanhamento de tarefas. -* [Protocolos](https://protocolos.fluxo.info) de operação! - -Fluxo de trabalho: - -* Reuniões periódicas de trabalho coletivo: pesquisa, desenvolvimento, implementação, manutenção e auditoria. - -Opcional: - -* Site e canais de contato públicos. -* Licença de distribuição de conteúdo. -* Termos de serviço e política de privacidade. diff --git a/coletivo/coletivo.md b/coletivo/coletivo.md new file mode 100644 index 0000000..e9ecac5 --- /dev/null +++ b/coletivo/coletivo.md @@ -0,0 +1,62 @@ +[[!meta title="Protocolo de Ação do Coletivo"]] + + * Versão: 1.0. + * Licença: LIMICS[1]. + +O Coletivo `$coletivo` adota a versão 0.1 do "Protocolo de Ação Coletiva"[2], de modo que se tome por "Coletivo `$coletivo`" toda ocorrência da palavra "Coletivo" no referido texto. + +Instâncias de Comunicação +------------------------- + +Conforme a atual configuração tecnológica do Coletivo $coletivo, as principais instâncias de comunicação utilizadas são: + + * Wiki/sistema de tickets fechado: `https://admin.$dominio`. + * Lista de discussão: `$lista_de_discussao`. + * Demais meios de comunicação que satisfaçam requisitos de privacidade e segurança. + +Processos e tickets +------------------- + +A manifestação que os registros de processos assumem no Coletivo `$coletivo` são chamados de tickets ou requisições. Todos os processos devem ser tickets. Processos informais não precisam necessariamente ser tickets antes da sua realização, mas para que posteriormente possam ser considerados como processos precisam virar tickets (isto é, precisam de um mínimo de documentação). + +Formalidade e informalidade de instâncias +----------------------------------------- + +Com relação à formalidade e informalidade das instãncias de comunicação, temos que: + + * Todas as instâncias de comunicação são informais ''a priori'' (isto é, se nada mais for dito a respeito da forma de cada uma delas). + * As instãncias formalizadoras (isto é, as instãncias onde deve ser informada da proposição e aprovação de um processo para que o mesmo tenha validade formal) são o sistema de tickets e a lista de discussão. + +Recomendação sobre jardinagem de discussões +------------------------------------------- + +Levando em consideração que + + * É interessante manter um fluxo de emails baixo com mensagens pequenas para que a lista de discussão possa ser bem usada especialmente em urgências. + * Wiki e sistema de tickets são muito úteis para lidar com grandes quantidades de informação, apesar de não serem muito bons para a obtenção de feedback rápido. + * No caso de pendências e tarefas, o sistema de tickets é mais confortável para o acompanhamento de atividades. + +Recomenda-se que + + * Se possível, as discussões sejam originadas nos meios que lhes forem mais propícios (alguma emergências se iniciam melhor com o envio de um email, onde obtém melhor resposta). + * Caso um meio se torne inadequado para a manutenção da discussão, que a mesma seja transferida para um meio mais adequado mas que tal transferência seja acompanhada pelo referenciamento mútuo em ambas as instâncias (na instância onde ela deixar de ocorrer envia-se uma mensagem indicando para onde a discussão está sendo encaminhada e nesta última se adiciona uma indicação sobre onde a discussão veio. + * Discussões que adquiram vulto sejam transformadas em processos informais (com a criação de um ticket com respectivo link, se aplicável, para o local onde a discussão está sendo realizada). + +Procedimento para Processos Formais +----------------------------------- + +Além de obedecer ao fluxograma de processos formais detalhado no texto "Protocolo de Ação Coletiva", a proposição e a decisão de propostas formais devem ser realizadas da seguinte forma para serem válidas: + + * Para enviar uma proposta formal, primeiramente crie um ticket. + * Em seguida, envie um email para a lista de discussão informando da proposta e incluindo, pelo menos, o link do ticket. + * A discussão e alteração da proposta pode ser feita apenas pelo ticket, pela lista de discussão ou mesmo em instâncias informais, mas recomenda-se que se utilize o ticket como agregador do maior número possível de informações discutidas a respeito da proposta. + * Discussões realizadas em instâncias informais não tem valor formal se não forem documentadas e apresentadas como tal na lista de discussão, no ticket ou eventual página wiki, observando a recomendação sobre jardinagem de discussões. + * Ao passar o prazo de decisão da proposta, é necessário enviar um email de comunicação à lista de discussão para que a decisão seja formalizada. + +Conforme o processo formal em questão for passando pelas etapas formais, o estado do ticket deve ser alterado pelas pessoas que se interessarem por fazê-lo. Se necessário, a proposta também pode ter ao menos uma página no wiki fechado, sendo possível usar o wiki para acompanhar diferentes versões de uma proposta, por exemplo. + +Referências +----------- + + * [1] [Licença de Manipulação de Informações do Coletivo $coletivo](/organizacao/comunicacao/license). + * [2] [Protocolo de Ação Coletiva](/organizacao/coletiva. diff --git a/coletivo/coletivo.mdwn b/coletivo/coletivo.mdwn deleted file mode 100644 index e9ecac5..0000000 --- a/coletivo/coletivo.mdwn +++ /dev/null @@ -1,62 +0,0 @@ -[[!meta title="Protocolo de Ação do Coletivo"]] - - * Versão: 1.0. - * Licença: LIMICS[1]. - -O Coletivo `$coletivo` adota a versão 0.1 do "Protocolo de Ação Coletiva"[2], de modo que se tome por "Coletivo `$coletivo`" toda ocorrência da palavra "Coletivo" no referido texto. - -Instâncias de Comunicação -------------------------- - -Conforme a atual configuração tecnológica do Coletivo $coletivo, as principais instâncias de comunicação utilizadas são: - - * Wiki/sistema de tickets fechado: `https://admin.$dominio`. - * Lista de discussão: `$lista_de_discussao`. - * Demais meios de comunicação que satisfaçam requisitos de privacidade e segurança. - -Processos e tickets -------------------- - -A manifestação que os registros de processos assumem no Coletivo `$coletivo` são chamados de tickets ou requisições. Todos os processos devem ser tickets. Processos informais não precisam necessariamente ser tickets antes da sua realização, mas para que posteriormente possam ser considerados como processos precisam virar tickets (isto é, precisam de um mínimo de documentação). - -Formalidade e informalidade de instâncias ------------------------------------------ - -Com relação à formalidade e informalidade das instãncias de comunicação, temos que: - - * Todas as instâncias de comunicação são informais ''a priori'' (isto é, se nada mais for dito a respeito da forma de cada uma delas). - * As instãncias formalizadoras (isto é, as instãncias onde deve ser informada da proposição e aprovação de um processo para que o mesmo tenha validade formal) são o sistema de tickets e a lista de discussão. - -Recomendação sobre jardinagem de discussões -------------------------------------------- - -Levando em consideração que - - * É interessante manter um fluxo de emails baixo com mensagens pequenas para que a lista de discussão possa ser bem usada especialmente em urgências. - * Wiki e sistema de tickets são muito úteis para lidar com grandes quantidades de informação, apesar de não serem muito bons para a obtenção de feedback rápido. - * No caso de pendências e tarefas, o sistema de tickets é mais confortável para o acompanhamento de atividades. - -Recomenda-se que - - * Se possível, as discussões sejam originadas nos meios que lhes forem mais propícios (alguma emergências se iniciam melhor com o envio de um email, onde obtém melhor resposta). - * Caso um meio se torne inadequado para a manutenção da discussão, que a mesma seja transferida para um meio mais adequado mas que tal transferência seja acompanhada pelo referenciamento mútuo em ambas as instâncias (na instância onde ela deixar de ocorrer envia-se uma mensagem indicando para onde a discussão está sendo encaminhada e nesta última se adiciona uma indicação sobre onde a discussão veio. - * Discussões que adquiram vulto sejam transformadas em processos informais (com a criação de um ticket com respectivo link, se aplicável, para o local onde a discussão está sendo realizada). - -Procedimento para Processos Formais ------------------------------------ - -Além de obedecer ao fluxograma de processos formais detalhado no texto "Protocolo de Ação Coletiva", a proposição e a decisão de propostas formais devem ser realizadas da seguinte forma para serem válidas: - - * Para enviar uma proposta formal, primeiramente crie um ticket. - * Em seguida, envie um email para a lista de discussão informando da proposta e incluindo, pelo menos, o link do ticket. - * A discussão e alteração da proposta pode ser feita apenas pelo ticket, pela lista de discussão ou mesmo em instâncias informais, mas recomenda-se que se utilize o ticket como agregador do maior número possível de informações discutidas a respeito da proposta. - * Discussões realizadas em instâncias informais não tem valor formal se não forem documentadas e apresentadas como tal na lista de discussão, no ticket ou eventual página wiki, observando a recomendação sobre jardinagem de discussões. - * Ao passar o prazo de decisão da proposta, é necessário enviar um email de comunicação à lista de discussão para que a decisão seja formalizada. - -Conforme o processo formal em questão for passando pelas etapas formais, o estado do ticket deve ser alterado pelas pessoas que se interessarem por fazê-lo. Se necessário, a proposta também pode ter ao menos uma página no wiki fechado, sendo possível usar o wiki para acompanhar diferentes versões de uma proposta, por exemplo. - -Referências ------------ - - * [1] [Licença de Manipulação de Informações do Coletivo $coletivo](/organizacao/comunicacao/license). - * [2] [Protocolo de Ação Coletiva](/organizacao/coletiva. diff --git a/coletivo/comunicacao.md b/coletivo/comunicacao.md new file mode 100644 index 0000000..fe1319c --- /dev/null +++ b/coletivo/comunicacao.md @@ -0,0 +1,3 @@ +[[!meta title="Comunicação"]] + +[[!map pages="page(comunicacao*)" show="title"]] diff --git a/coletivo/comunicacao.mdwn b/coletivo/comunicacao.mdwn deleted file mode 100644 index fe1319c..0000000 --- a/coletivo/comunicacao.mdwn +++ /dev/null @@ -1,3 +0,0 @@ -[[!meta title="Comunicação"]] - -[[!map pages="page(comunicacao*)" show="title"]] diff --git a/coletivo/comunicacao/acl.md b/coletivo/comunicacao/acl.md new file mode 100644 index 0000000..ecdc442 --- /dev/null +++ b/coletivo/comunicacao/acl.md @@ -0,0 +1,37 @@ +[[!meta title="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/coletivo/comunicacao/acl.mdwn b/coletivo/comunicacao/acl.mdwn deleted file mode 100644 index ecdc442..0000000 --- a/coletivo/comunicacao/acl.mdwn +++ /dev/null @@ -1,37 +0,0 @@ -[[!meta title="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/coletivo/comunicacao/archive.md b/coletivo/comunicacao/archive.md new file mode 100644 index 0000000..6fc8662 --- /dev/null +++ b/coletivo/comunicacao/archive.md @@ -0,0 +1,12 @@ +[[!meta title="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/coletivo/comunicacao/archive.mdwn b/coletivo/comunicacao/archive.mdwn deleted file mode 100644 index 6fc8662..0000000 --- a/coletivo/comunicacao/archive.mdwn +++ /dev/null @@ -1,12 +0,0 @@ -[[!meta title="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/coletivo/comunicacao/backup.md b/coletivo/comunicacao/backup.md new file mode 100644 index 0000000..309f1c1 --- /dev/null +++ b/coletivo/comunicacao/backup.md @@ -0,0 +1,31 @@ +[[!meta title="Instâncias de comunicação de backup"]] + +Este processo estabelece procedimentos para comunicação de backup para + + * Lista de email. + * Bate-papo. + +Responsabilização +----------------- + +O Grupo de Trabalho responsável por este processo deve manter uma lista de +email e uma sala de bate-papo de [ACL](/organizacao/comunicacao/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 +[Politica Política de segurança da informação](/organizacao/comunicacao/infosec) +e que possam ser utilizados como backup. + +Dependências +------------ + +A realização deste processo depende da realização dos seguintes processos: + + * [Política de segurança da informação](/organizacao/comunicacao/infosec). + * [ACL Lista de acesso à participação (ACL)](/organizacao/comunicacao/acl). diff --git a/coletivo/comunicacao/backup.mdwn b/coletivo/comunicacao/backup.mdwn deleted file mode 100644 index 309f1c1..0000000 --- a/coletivo/comunicacao/backup.mdwn +++ /dev/null @@ -1,31 +0,0 @@ -[[!meta title="Instâncias de comunicação de backup"]] - -Este processo estabelece procedimentos para comunicação de backup para - - * Lista de email. - * Bate-papo. - -Responsabilização ------------------ - -O Grupo de Trabalho responsável por este processo deve manter uma lista de -email e uma sala de bate-papo de [ACL](/organizacao/comunicacao/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 -[Politica Política de segurança da informação](/organizacao/comunicacao/infosec) -e que possam ser utilizados como backup. - -Dependências ------------- - -A realização deste processo depende da realização dos seguintes processos: - - * [Política de segurança da informação](/organizacao/comunicacao/infosec). - * [ACL Lista de acesso à participação (ACL)](/organizacao/comunicacao/acl). diff --git a/coletivo/comunicacao/chat.md b/coletivo/comunicacao/chat.md new file mode 100644 index 0000000..05aafa0 --- /dev/null +++ b/coletivo/comunicacao/chat.md @@ -0,0 +1,38 @@ +[[!meta title="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/coletivo/comunicacao/chat.mdwn b/coletivo/comunicacao/chat.mdwn deleted file mode 100644 index 05aafa0..0000000 --- a/coletivo/comunicacao/chat.mdwn +++ /dev/null @@ -1,38 +0,0 @@ -[[!meta title="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/coletivo/comunicacao/infosec.md b/coletivo/comunicacao/infosec.md new file mode 100644 index 0000000..e0eeaaa --- /dev/null +++ b/coletivo/comunicacao/infosec.md @@ -0,0 +1,73 @@ +[[!meta title="Política de segurança da informação"]] + +O presente processo estabelece uma série de definições e recomendações relacionadas à segurança da informação circulada por instâncias mantidas pelo Coletivo. + +Política de senhas e chaves +--------------------------- + +Recomenda-se que as pessoas participantes de instâncias de informação mantidas pelo Coletivo assumam uma política de senhas como a seguinte: + + 1. Não utilizar a mesma senha para sistemas sensíveis. + 2. Não utilizar senhas frágeis. + +Recomenda-se ainda, que sejam utilizadas aplicações como as seguintes: + + * [http://web.monkeysphere.info Monkeysphere] para auxiliar na autenticação de sistemas remotos. + * [http://point-at-infinity.org/ssss ssss], para o compartilhamento de senhas em sistemas sensíveis. + * Programas como o [http://www.adel.nursat.kz/apg apg] para a geração de senhas fortes. + * Programas como o [http://oss.codepoet.no/revelation/wiki/Home Revelation] ou o [http://kedpm.sourceforge.net kedpm] para o armazenamento seguro de senhas. + +Emails suficientemente seguros +------------------------------ + +Define-se como uma conta de email suficientemente segura aquela que utiliza: + + 1. [http://en.wikipedia.org/wiki/STARTTLS STARTTLS] nas transmissões para outras contas de email suficientemente seguros. + 2. É acessada apenas através de conexão SSL, seja HTTPS, IMAPS, POPS ou SMTPS. + 3. Criptografia de disco para armazenamento de mensagens no servidor. + +A participação em instâncias de comunicação mantidas pelo Coletivo e que não são totalmente públicas requerem o uso de contas de email suficientemente seguros. + +Criptografia +------------ + +Recomenda-se que as pessoas participantes de instâncias de informação mantidas pelo Coletivo: + + 1. Armazenem informações internas relacionadas ao mesmo apenas em volumes criptografados. Se não tiverem condições de assim procederem com suas máquinas pessoais, recomenda-se que armazenem tais informações apenas em instâncias de comunicação do Coletivo que possuam transmissão e armazenamento criptografado de dados. + + 2. Utilizem o sistema OpenPGP de criptografia assimétrica para proteção, integridade e verificação de procedência de dados sensíveis. + + 3. Utilizem canais de comunicação criptografados sempre que possível e que não utilizem canais não-criptografados para tratar remotamente de questões internas ao Coletivo. + +Lista de recomendações e práticas sugeridas +------------------------------------------- + +Por se tratar de uma questão complexa e sensível mas por contar com documentação dispersa, listas adicionais de recomendações e práticas sugeridas sobre segurança da informação podem ser anexadas ao presente processo. + +Eventualmente, recomenda-se que este processo seja atualizado para contemplar progressos neste campo. + +Criação de contas +----------------- + +A criação de contas em sistemas mantidos pelo Coletivo deve obedecer o seguinte procedimento: + + 1. Priorizar a escolha de senha pelo titular da conta sem que outra pessoa precise conhecê-la, desde que possível. + 2. Enviar para o/a usuário: + a. Pedido de mudança de senha logo que consiga se autenticar nos sistemas em questão, caso isso seja possível. + b. Fornecer fingerprints de chaves de criptografia utilizadas para o acesso da conta. + c. Se possível, as informações da conta utilizando criptografia e para uma conta de email suficientemente seguro do/a usuário. + d. Uma cópia da lista de recomendações e boas práticas. + +Persistência de dados +--------------------- + +Informações armazenados num determinado nível de acesso ou segurança (exemplo, disco criptografado) devem, por padrão, permanecer nesse mesmo nível ou serem transferidas para um nível mais seguro, exceto quando constitui informação desclassificada e permitida para descer de nível. + +Telefone e outros meios de comunicação privada que não possuam segurança suficiente do conteúdo, da origem e do destinatário da informação devem ser considerados, para todos os efeitos, como meios de comunicação públicos e portanto não serem utilizados para veicular informações sensíveis. + +Dependências +------------ + +A realização deste processo depende da realização dos seguintes processos: + +* [ACL Lista de acesso à participação (ACL)](/organizacao/comunicacao/acl). diff --git a/coletivo/comunicacao/infosec.mdwn b/coletivo/comunicacao/infosec.mdwn deleted file mode 100644 index e0eeaaa..0000000 --- a/coletivo/comunicacao/infosec.mdwn +++ /dev/null @@ -1,73 +0,0 @@ -[[!meta title="Política de segurança da informação"]] - -O presente processo estabelece uma série de definições e recomendações relacionadas à segurança da informação circulada por instâncias mantidas pelo Coletivo. - -Política de senhas e chaves ---------------------------- - -Recomenda-se que as pessoas participantes de instâncias de informação mantidas pelo Coletivo assumam uma política de senhas como a seguinte: - - 1. Não utilizar a mesma senha para sistemas sensíveis. - 2. Não utilizar senhas frágeis. - -Recomenda-se ainda, que sejam utilizadas aplicações como as seguintes: - - * [http://web.monkeysphere.info Monkeysphere] para auxiliar na autenticação de sistemas remotos. - * [http://point-at-infinity.org/ssss ssss], para o compartilhamento de senhas em sistemas sensíveis. - * Programas como o [http://www.adel.nursat.kz/apg apg] para a geração de senhas fortes. - * Programas como o [http://oss.codepoet.no/revelation/wiki/Home Revelation] ou o [http://kedpm.sourceforge.net kedpm] para o armazenamento seguro de senhas. - -Emails suficientemente seguros ------------------------------- - -Define-se como uma conta de email suficientemente segura aquela que utiliza: - - 1. [http://en.wikipedia.org/wiki/STARTTLS STARTTLS] nas transmissões para outras contas de email suficientemente seguros. - 2. É acessada apenas através de conexão SSL, seja HTTPS, IMAPS, POPS ou SMTPS. - 3. Criptografia de disco para armazenamento de mensagens no servidor. - -A participação em instâncias de comunicação mantidas pelo Coletivo e que não são totalmente públicas requerem o uso de contas de email suficientemente seguros. - -Criptografia ------------- - -Recomenda-se que as pessoas participantes de instâncias de informação mantidas pelo Coletivo: - - 1. Armazenem informações internas relacionadas ao mesmo apenas em volumes criptografados. Se não tiverem condições de assim procederem com suas máquinas pessoais, recomenda-se que armazenem tais informações apenas em instâncias de comunicação do Coletivo que possuam transmissão e armazenamento criptografado de dados. - - 2. Utilizem o sistema OpenPGP de criptografia assimétrica para proteção, integridade e verificação de procedência de dados sensíveis. - - 3. Utilizem canais de comunicação criptografados sempre que possível e que não utilizem canais não-criptografados para tratar remotamente de questões internas ao Coletivo. - -Lista de recomendações e práticas sugeridas -------------------------------------------- - -Por se tratar de uma questão complexa e sensível mas por contar com documentação dispersa, listas adicionais de recomendações e práticas sugeridas sobre segurança da informação podem ser anexadas ao presente processo. - -Eventualmente, recomenda-se que este processo seja atualizado para contemplar progressos neste campo. - -Criação de contas ------------------ - -A criação de contas em sistemas mantidos pelo Coletivo deve obedecer o seguinte procedimento: - - 1. Priorizar a escolha de senha pelo titular da conta sem que outra pessoa precise conhecê-la, desde que possível. - 2. Enviar para o/a usuário: - a. Pedido de mudança de senha logo que consiga se autenticar nos sistemas em questão, caso isso seja possível. - b. Fornecer fingerprints de chaves de criptografia utilizadas para o acesso da conta. - c. Se possível, as informações da conta utilizando criptografia e para uma conta de email suficientemente seguro do/a usuário. - d. Uma cópia da lista de recomendações e boas práticas. - -Persistência de dados ---------------------- - -Informações armazenados num determinado nível de acesso ou segurança (exemplo, disco criptografado) devem, por padrão, permanecer nesse mesmo nível ou serem transferidas para um nível mais seguro, exceto quando constitui informação desclassificada e permitida para descer de nível. - -Telefone e outros meios de comunicação privada que não possuam segurança suficiente do conteúdo, da origem e do destinatário da informação devem ser considerados, para todos os efeitos, como meios de comunicação públicos e portanto não serem utilizados para veicular informações sensíveis. - -Dependências ------------- - -A realização deste processo depende da realização dos seguintes processos: - -* [ACL Lista de acesso à participação (ACL)](/organizacao/comunicacao/acl). diff --git a/coletivo/comunicacao/license.md b/coletivo/comunicacao/license.md new file mode 100644 index 0000000..9a6fe97 --- /dev/null +++ b/coletivo/comunicacao/license.md @@ -0,0 +1,136 @@ +[[!meta title="Conjunto de Licenciamento Livre"]] + +Originalmente em [Cultura Livre e Capitalismo | Principal / ConjuntoDeLicenciamentoLivre](https://encontro.fluxo.info/Principal/ConjuntoDeLicenciamentoLivre). + +## Seções das licenças + +Para contemplar inúmeros pontos de vista dos grupos e pessoas participantes deste espaço, a proposta de licença envolve as seguintes partes: + +1. Liberdades atribuídas ao/à licenciado/a +2. Obrigações do/a licenciado +3. Liberdades e obrigações atribuídas ao/à licenciante + +## Liberdades atribuídas ao/à licenciado/a + +Atribui ao detentor/a da informação as seguintes liberdades: + +1. A liberdade de armazenar a informação. +2. A liberdade de manipular a informação. +3. A liberdade de distribuir a informação, modificada ou não. + +## Obrigações do/a licenciado + +### Restrição obrigatória: "viralidade" + +Desde que esta licença acompanhe a informação. +Restrição ética ou mercantil + +### As seguintes opções mutuamente exclusivas são possíveis para a montagem de uma licença: + +1. Contanto que o detentor da informação pactue com os princípios das mídias e grupos livres. +2. Restrição comercial: Desde que para fins não-comerciais. +3. Restrição de lucro: Desde que para fins não-lucrativos. + +### Restrição de autoria e fonte + +As seguintes opções não-exclusivas são possíveis para a montagem de uma licença: + +1. Desde que o autor seja citado. +2. Desde que a fonte seja citada. + +### Restrição de distribuição + +Essa restrição obriga que a pessoa que utilizar a informação a: + +1. Caso ocorra uma modificação, distribuir a informação modificada. +2. Ou, eventualmente, distribuir a informação para qualquer um dos usos que ela estiver sujeita. + +Opcionalmente, uma das seguintes restrições de notificação podem ser utilizadas: + +1. Caso o conteúdo seja distribuído, a fonte deve ser notificada antecipadamente. +2. Ou, caso o conteúdo seja distribuído, a fonte deve ser notificada antecipadamente caso existam modificações. + +## Liberdades e obrigações atribuídas ao/à licenciante + +As seguintes opções não-exclusivas são possíveis para a montagem de uma licença e apenas fazem sentido se a informação preserva autoria ou fonte: + +1. O/a autor/a pode a qualquer momento revogar o licenciamento da informação para uma determinada pessoa ou entidade. +2. O/a autor/a apenas pode licenciar sua informação sob a licença se ele declarar que não relicenciará a informação. + +## Licença do Conjunto de Licenciamento Livre + +Atribui ao detentor/a do texto do Conjunto de Licenciamento Livre as seguintes liberdades: + +1. A liberdade de armazenar o texto do Conjunto. +2. A liberdade de manipular o texto do Conjunto, inclusive para criar novas licenças. +3. A liberdade de distribuir o texto do Conjunto, modificada ou não. + +### Obrigações do/a licenciado + +1. Desde que esta licença acompanhe a informação. +2. Restrição de lucro: Este Conjunto de Licenciamento Livre e esta licença podem ser utilizados apenas para criar licenças e licenciar conteúdos com finalidades não lucrativas. + +### Licença da licença + +O texto desta licença está licenciado por ele mesmo. + +## Exemplo + +Estabelece o seguinte texto como a licença padrão de distribuição de conteúdo produzido pelo Coletivo: + + 1. Licença de Manipulação de Informações do Grupo $coletivo + + Licença baseada no Conjunto de Licenciamento Livre[1] do Encontro: Cultura + Livre e Capitalismo[2]. + + 2. Liberdades atribuídas ao/à licenciado/a + + Atribui ao detentor/a da informação as seguintes liberdades: + + 1. A liberdade de armazenar a informação. + 2. A liberdade de manipular a informação. + 3. A liberdade de distribuir a informação, modificada ou não. + + Desde que as condições listada na seção Obrigações do/a licenciado/a a seguir + sejam respeitadas. + + 3. Obrigações do/a licenciado/a + + 3.1 Viralidade + + Desde que esta licença acompanhe a informação. + + 3.2 Restrição mercantil + + * Desde que para fins não-comerciais. + + 3.3 Restrição de citação + + * Desde que a fonte seja citada. + + 3.4 Restrição de distribuição + + * Caso o conteúdo seja distribuído por você, o Grupo $coletivo deve ser + notificado antecipadamente. + * Caso ocorra uma modificação, distribuir a + informação modificada e notificar antecipadamente o Grupo $coletivo. + + 4. Liberdades e obrigações atribuídas ao/à licenciante + + * O Grupo $coletivo pode a qualquer momento revogar o licenciamento da + informação para uma determinada pessoa ou entidade. + + [1] https://protocolos.fluxo.info/organizacao/comunicacao/license/ + [2] http://encontro.fluxo.info + +Não é obrigatória nem compulsória a utilização desta licença, mas conteúdo veiculado pelo ou em nome do Coletivo a utiliza por padrão caso não haja menção formal em contrário. + +### Responsabilização + +A(s) pessoa(s) responsável(is) pelo processo ficam encarregadas de manter o texto da licença em um local público acessível via web para que possa ser referenciado por outros textos do Coletivo, além de adicionar a seguinte nota antes do texto da licença: + +` +Desde que não mencionado em contrário, todo o conteúdo produzido pelo Grupo +$coletivo é distribuído de acordo com a Licença de Manipulação de Informações do +Grupo $coletivo. +` diff --git a/coletivo/comunicacao/license.mdwn b/coletivo/comunicacao/license.mdwn deleted file mode 100644 index 9a6fe97..0000000 --- a/coletivo/comunicacao/license.mdwn +++ /dev/null @@ -1,136 +0,0 @@ -[[!meta title="Conjunto de Licenciamento Livre"]] - -Originalmente em [Cultura Livre e Capitalismo | Principal / ConjuntoDeLicenciamentoLivre](https://encontro.fluxo.info/Principal/ConjuntoDeLicenciamentoLivre). - -## Seções das licenças - -Para contemplar inúmeros pontos de vista dos grupos e pessoas participantes deste espaço, a proposta de licença envolve as seguintes partes: - -1. Liberdades atribuídas ao/à licenciado/a -2. Obrigações do/a licenciado -3. Liberdades e obrigações atribuídas ao/à licenciante - -## Liberdades atribuídas ao/à licenciado/a - -Atribui ao detentor/a da informação as seguintes liberdades: - -1. A liberdade de armazenar a informação. -2. A liberdade de manipular a informação. -3. A liberdade de distribuir a informação, modificada ou não. - -## Obrigações do/a licenciado - -### Restrição obrigatória: "viralidade" - -Desde que esta licença acompanhe a informação. -Restrição ética ou mercantil - -### As seguintes opções mutuamente exclusivas são possíveis para a montagem de uma licença: - -1. Contanto que o detentor da informação pactue com os princípios das mídias e grupos livres. -2. Restrição comercial: Desde que para fins não-comerciais. -3. Restrição de lucro: Desde que para fins não-lucrativos. - -### Restrição de autoria e fonte - -As seguintes opções não-exclusivas são possíveis para a montagem de uma licença: - -1. Desde que o autor seja citado. -2. Desde que a fonte seja citada. - -### Restrição de distribuição - -Essa restrição obriga que a pessoa que utilizar a informação a: - -1. Caso ocorra uma modificação, distribuir a informação modificada. -2. Ou, eventualmente, distribuir a informação para qualquer um dos usos que ela estiver sujeita. - -Opcionalmente, uma das seguintes restrições de notificação podem ser utilizadas: - -1. Caso o conteúdo seja distribuído, a fonte deve ser notificada antecipadamente. -2. Ou, caso o conteúdo seja distribuído, a fonte deve ser notificada antecipadamente caso existam modificações. - -## Liberdades e obrigações atribuídas ao/à licenciante - -As seguintes opções não-exclusivas são possíveis para a montagem de uma licença e apenas fazem sentido se a informação preserva autoria ou fonte: - -1. O/a autor/a pode a qualquer momento revogar o licenciamento da informação para uma determinada pessoa ou entidade. -2. O/a autor/a apenas pode licenciar sua informação sob a licença se ele declarar que não relicenciará a informação. - -## Licença do Conjunto de Licenciamento Livre - -Atribui ao detentor/a do texto do Conjunto de Licenciamento Livre as seguintes liberdades: - -1. A liberdade de armazenar o texto do Conjunto. -2. A liberdade de manipular o texto do Conjunto, inclusive para criar novas licenças. -3. A liberdade de distribuir o texto do Conjunto, modificada ou não. - -### Obrigações do/a licenciado - -1. Desde que esta licença acompanhe a informação. -2. Restrição de lucro: Este Conjunto de Licenciamento Livre e esta licença podem ser utilizados apenas para criar licenças e licenciar conteúdos com finalidades não lucrativas. - -### Licença da licença - -O texto desta licença está licenciado por ele mesmo. - -## Exemplo - -Estabelece o seguinte texto como a licença padrão de distribuição de conteúdo produzido pelo Coletivo: - - 1. Licença de Manipulação de Informações do Grupo $coletivo - - Licença baseada no Conjunto de Licenciamento Livre[1] do Encontro: Cultura - Livre e Capitalismo[2]. - - 2. Liberdades atribuídas ao/à licenciado/a - - Atribui ao detentor/a da informação as seguintes liberdades: - - 1. A liberdade de armazenar a informação. - 2. A liberdade de manipular a informação. - 3. A liberdade de distribuir a informação, modificada ou não. - - Desde que as condições listada na seção Obrigações do/a licenciado/a a seguir - sejam respeitadas. - - 3. Obrigações do/a licenciado/a - - 3.1 Viralidade - - Desde que esta licença acompanhe a informação. - - 3.2 Restrição mercantil - - * Desde que para fins não-comerciais. - - 3.3 Restrição de citação - - * Desde que a fonte seja citada. - - 3.4 Restrição de distribuição - - * Caso o conteúdo seja distribuído por você, o Grupo $coletivo deve ser - notificado antecipadamente. - * Caso ocorra uma modificação, distribuir a - informação modificada e notificar antecipadamente o Grupo $coletivo. - - 4. Liberdades e obrigações atribuídas ao/à licenciante - - * O Grupo $coletivo pode a qualquer momento revogar o licenciamento da - informação para uma determinada pessoa ou entidade. - - [1] https://protocolos.fluxo.info/organizacao/comunicacao/license/ - [2] http://encontro.fluxo.info - -Não é obrigatória nem compulsória a utilização desta licença, mas conteúdo veiculado pelo ou em nome do Coletivo a utiliza por padrão caso não haja menção formal em contrário. - -### Responsabilização - -A(s) pessoa(s) responsável(is) pelo processo ficam encarregadas de manter o texto da licença em um local público acessível via web para que possa ser referenciado por outros textos do Coletivo, além de adicionar a seguinte nota antes do texto da licença: - -` -Desde que não mencionado em contrário, todo o conteúdo produzido pelo Grupo -$coletivo é distribuído de acordo com a Licença de Manipulação de Informações do -Grupo $coletivo. -` diff --git a/coletivo/comunicacao/list.md b/coletivo/comunicacao/list.md new file mode 100644 index 0000000..7a229f2 --- /dev/null +++ b/coletivo/comunicacao/list.md @@ -0,0 +1,55 @@ +[[!meta title="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: + +* [ACL Lista de acesso à participação (ACL)](/organizacao/comunicacao/acl). diff --git a/coletivo/comunicacao/list.mdwn b/coletivo/comunicacao/list.mdwn deleted file mode 100644 index 7a229f2..0000000 --- a/coletivo/comunicacao/list.mdwn +++ /dev/null @@ -1,55 +0,0 @@ -[[!meta title="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: - -* [ACL Lista de acesso à participação (ACL)](/organizacao/comunicacao/acl). diff --git a/coletivo/comunicacao/transparency.md b/coletivo/comunicacao/transparency.md new file mode 100644 index 0000000..b60f179 --- /dev/null +++ b/coletivo/comunicacao/transparency.md @@ -0,0 +1,42 @@ +[[!meta title="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: + +* [ACL Lista de acesso à participação (ACL)](/organizacao/comunicacao/acl). diff --git a/coletivo/comunicacao/transparency.mdwn b/coletivo/comunicacao/transparency.mdwn deleted file mode 100644 index b60f179..0000000 --- a/coletivo/comunicacao/transparency.mdwn +++ /dev/null @@ -1,42 +0,0 @@ -[[!meta title="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: - -* [ACL Lista de acesso à participação (ACL)](/organizacao/comunicacao/acl). diff --git a/coletivo/comunicacao/vizinhanca.md b/coletivo/comunicacao/vizinhanca.md new file mode 100644 index 0000000..a40d21b --- /dev/null +++ b/coletivo/comunicacao/vizinhanca.md @@ -0,0 +1,49 @@ +[[!meta title="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 [emails suficientemente seguros](/organizacao/comunicacao/infosec) 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: + +* [ACL Lista de acesso à participação (ACL)](/organizacao/comunicacao/acl). +* [Política de segurança da informação](/organizacao/comunicacao/infosec). diff --git a/coletivo/comunicacao/vizinhanca.mdwn b/coletivo/comunicacao/vizinhanca.mdwn deleted file mode 100644 index a40d21b..0000000 --- a/coletivo/comunicacao/vizinhanca.mdwn +++ /dev/null @@ -1,49 +0,0 @@ -[[!meta title="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 [emails suficientemente seguros](/organizacao/comunicacao/infosec) 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: - -* [ACL Lista de acesso à participação (ACL)](/organizacao/comunicacao/acl). -* [Política de segurança da informação](/organizacao/comunicacao/infosec). diff --git a/coletivo/contabilidade.md b/coletivo/contabilidade.md new file mode 100644 index 0000000..fb85ace --- /dev/null +++ b/coletivo/contabilidade.md @@ -0,0 +1,27 @@ +[[!meta title="Contabilidade"]] + +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/coletivo/contabilidade.mdwn b/coletivo/contabilidade.mdwn deleted file mode 100644 index fb85ace..0000000 --- a/coletivo/contabilidade.mdwn +++ /dev/null @@ -1,27 +0,0 @@ -[[!meta title="Contabilidade"]] - -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/coletivo/contabilidade/criterios.md b/coletivo/contabilidade/criterios.md new file mode 100644 index 0000000..d9eaa3f --- /dev/null +++ b/coletivo/contabilidade/criterios.md @@ -0,0 +1,120 @@ +[[!meta title="Critérios financeiros"]] + +Este processo estabelece os critérios financeiros sobre + + 1. Doação (de e para o Coletivo). + 2. Arrecadação. + 3. Gastos. + 4. Transparência. + 5. Remuneração. + 6. Ajuda de custos. + 7. Lucro e contas bancárias. + +## Doação + +Com relação à doações é adotado o seguinte critério (oriundo dos [http://encontro.fluxo.org/Principal/ConjuntoDePrincipiosEticos Princípios das mídias e grupos livres]): + + 10. Sobre doações: Se recebem dinheiro, o fazem apenas como doação, ou seja: + qualquer apoiador deve saber que seus recursos não serão empregados senão para + os fins estritos de criação de espaços comunicativos livres, sendo vedadas as + práticas de mercantismo cultural, social ou político. Tais doações são aceitas + apenas se anônimas (isto é, não publicizadas). Dinheiro governamental ou + empresarial não é aceito. + +Ou seja, o Coletivo apenas recebe doações que satisfaçam o critério acima. No caso de doações que o Coletivo pode efetuar, as mesmas devem ser de acordo com o critério de gastos. + +## Arrecadação + +Com relação à arrecadação de recursos, é adotado o seguinte critério (oriundo dos [http://encontro.fluxo.org/Principal/ConjuntoDePrincipiosEticos Princípios das mídias e grupos livres]): + + 11. Sobre auto-sustentabilidade: As mídias e grupos livres estimulam a geração de + mecanismos de autosustentabilidade (ou "autodependência") local e comunitária. + Exemplos: venda de camisetas, comidas, rifas, organização de festas, mostra de + vídeos, etc. Tratam-se de atividades criadas e organizadas para estimular a + vivência em coletivo e a escapar das práticas capitalistas. É recomendável que, + dentro dos grupos e entre eles, exista uma socialização dos recursos e que os + individuos também adotem essa prática, compartilhando recursos pessoais com o + coletivo, para criar ambientes de solidariedade comunitária, onde ninguém seja + excluído por falta de recursos. + +## Gastos + +Os gastos (reembolso, doações, aquisições, etc) são efetuados através de procedimento formal. + +## Transparência + +Com relação à transparência da contabilidade, é adotado o seguinte critério (oriundo dos [http://encontro.fluxo.org/Principal/ConjuntoDePrincipiosEticos Princípios das mídias e grupos livres]): + + 12. Sobre a gestão financeira: Para garantir essas condições de financiamento, + toda a gestão financeira das mídias e grupos livres é publica: tanto as + informações contábeis quanto a participação nas decisões são acessíveis às + pessoas concernidas nas ações desta organização. + +Portanto, o Coletivo adota o critério de fornecer/publicar: + + 1. Seus critérios financeiros. + 2. [wiki:Contabilidade/Planejamento Seu planejamento financeiro]. + 3. [wiki:Contabilidade/Balanco Seu balanço financeiro]. + +às pessoas afetadas pela organização do Coletivo (por exemplo, grupos hospedados e parcerios) levando em conta as restrições de privacidade e segurança, isto é, a publicação/disponibilização do balanço é restrita aos grupos e pessoas próximas. + +## Remuneração + +Sobre à remuneração pelo trabalho realizado dentro do Coletivo, é adotado o seguinte critério (oriundo dos [http://encontro.fluxo.org/Principal/ConjuntoDePrincipiosEticos Princípios das mídias e grupos livres]): + + 21. Sobre a remuneração pelo trabalho: As mídias e os grupos livres funcionam + exclusivamente a partir de trabalho voluntário. + +Em outras palavras, o Coletivo não remunera pelo trabalho nele e por ele realizado. A remuneração, contudo, não pode ser confundida com a ajuda de custos. + +## Ajuda de custos + +A ajuda de custos é um recurso utilizado para criar um ambiente de igualdade de participação no Coletivo, por exemplo nos casos de custeio de ida à reuniões para pessoas que no momento não estejam em condições de fazê-lo, etc. Assim, integrantes do Coletivo que não possam participar de alguma atividade do Coletivo por não disporem de recursos materiais para fazê-lo podem solicitar ajuda de custos para o Coletivo. + +## Lucro e contas bancárias + +O Coletivo não possui fins lucrativos. Por isso, o Coletivo não se utiliza de operações financeiras com o intuito de auferir lucro, mas pode se utilizar de meios lícitos que lhe garantam a atualização monetária. + +Assim, quanto ao uso de transações e contas bancárias, o Coletivo reconhece que, apesar da segurança do dinheiro poder ser garantida de outras formas, a utilização de contas bancárias pode ser útil para + + * Facilitar a arrecadação financeira por dispor da rede bancária. + * Permitir a atualização financeira. + +O Coletivo reconhece as contradições de utilizar o sistema financeiro e por isso se compromete a utilizar somente o recurso da caderneta de poupança, que possui as seguintes características: + + * Baixo risco. + * Rendimentos baixos, uma vez que ela é basicamente apenas uma atualização monetária do dinheiro e por isso é praticamente o fundo de investimentos menos prejudicial à sociedade. + +## Licença + +Como estes critérios se utilizam de trechos oriundos dos [http://encontro.fluxo.org/Principal/ConjuntoDePrincipiosEticos Princípios das mídias e grupos livres]), segue a seguinte licença de manipulação dos mesmos (disponível também [http://encontro.fluxo.org/Principal/Licenca aqui]): + + 1. Licença de Manipulação do Conteúdo Deste Sítio + + Copyright (c) Encontro: Cultura Livre e Capitalismo: desde que não mencionado + em contrário, este conteúdo é distribuído de acordo com a licença a seguir. + + 2. Liberdades atribuídas ao/à licenciado/a + + Atribui ao detentor/a da informação as seguintes liberdades: + + 1. A liberdade de armazenar a informação. + 2. A liberdade de manipular a informação. + 3. A liberdade de distribuir a informação, modificada ou não. + + Desde que as condições listada na seção Obrigações do/a licenciado/a a seguir + sejam respeitadas. + + 3. Obrigações do/a licenciado + + 3.1 Viralidade + + * Desde que esta licença acompanhe a informação. + + 3.2 Restrição mercantil + + * Desde que para fins não-lucrativos. + + 3.3 Restrição de autoria e fonte + + * Desde que a fonte seja citada. diff --git a/coletivo/contabilidade/criterios.mdwn b/coletivo/contabilidade/criterios.mdwn deleted file mode 100644 index d9eaa3f..0000000 --- a/coletivo/contabilidade/criterios.mdwn +++ /dev/null @@ -1,120 +0,0 @@ -[[!meta title="Critérios financeiros"]] - -Este processo estabelece os critérios financeiros sobre - - 1. Doação (de e para o Coletivo). - 2. Arrecadação. - 3. Gastos. - 4. Transparência. - 5. Remuneração. - 6. Ajuda de custos. - 7. Lucro e contas bancárias. - -## Doação - -Com relação à doações é adotado o seguinte critério (oriundo dos [http://encontro.fluxo.org/Principal/ConjuntoDePrincipiosEticos Princípios das mídias e grupos livres]): - - 10. Sobre doações: Se recebem dinheiro, o fazem apenas como doação, ou seja: - qualquer apoiador deve saber que seus recursos não serão empregados senão para - os fins estritos de criação de espaços comunicativos livres, sendo vedadas as - práticas de mercantismo cultural, social ou político. Tais doações são aceitas - apenas se anônimas (isto é, não publicizadas). Dinheiro governamental ou - empresarial não é aceito. - -Ou seja, o Coletivo apenas recebe doações que satisfaçam o critério acima. No caso de doações que o Coletivo pode efetuar, as mesmas devem ser de acordo com o critério de gastos. - -## Arrecadação - -Com relação à arrecadação de recursos, é adotado o seguinte critério (oriundo dos [http://encontro.fluxo.org/Principal/ConjuntoDePrincipiosEticos Princípios das mídias e grupos livres]): - - 11. Sobre auto-sustentabilidade: As mídias e grupos livres estimulam a geração de - mecanismos de autosustentabilidade (ou "autodependência") local e comunitária. - Exemplos: venda de camisetas, comidas, rifas, organização de festas, mostra de - vídeos, etc. Tratam-se de atividades criadas e organizadas para estimular a - vivência em coletivo e a escapar das práticas capitalistas. É recomendável que, - dentro dos grupos e entre eles, exista uma socialização dos recursos e que os - individuos também adotem essa prática, compartilhando recursos pessoais com o - coletivo, para criar ambientes de solidariedade comunitária, onde ninguém seja - excluído por falta de recursos. - -## Gastos - -Os gastos (reembolso, doações, aquisições, etc) são efetuados através de procedimento formal. - -## Transparência - -Com relação à transparência da contabilidade, é adotado o seguinte critério (oriundo dos [http://encontro.fluxo.org/Principal/ConjuntoDePrincipiosEticos Princípios das mídias e grupos livres]): - - 12. Sobre a gestão financeira: Para garantir essas condições de financiamento, - toda a gestão financeira das mídias e grupos livres é publica: tanto as - informações contábeis quanto a participação nas decisões são acessíveis às - pessoas concernidas nas ações desta organização. - -Portanto, o Coletivo adota o critério de fornecer/publicar: - - 1. Seus critérios financeiros. - 2. [wiki:Contabilidade/Planejamento Seu planejamento financeiro]. - 3. [wiki:Contabilidade/Balanco Seu balanço financeiro]. - -às pessoas afetadas pela organização do Coletivo (por exemplo, grupos hospedados e parcerios) levando em conta as restrições de privacidade e segurança, isto é, a publicação/disponibilização do balanço é restrita aos grupos e pessoas próximas. - -## Remuneração - -Sobre à remuneração pelo trabalho realizado dentro do Coletivo, é adotado o seguinte critério (oriundo dos [http://encontro.fluxo.org/Principal/ConjuntoDePrincipiosEticos Princípios das mídias e grupos livres]): - - 21. Sobre a remuneração pelo trabalho: As mídias e os grupos livres funcionam - exclusivamente a partir de trabalho voluntário. - -Em outras palavras, o Coletivo não remunera pelo trabalho nele e por ele realizado. A remuneração, contudo, não pode ser confundida com a ajuda de custos. - -## Ajuda de custos - -A ajuda de custos é um recurso utilizado para criar um ambiente de igualdade de participação no Coletivo, por exemplo nos casos de custeio de ida à reuniões para pessoas que no momento não estejam em condições de fazê-lo, etc. Assim, integrantes do Coletivo que não possam participar de alguma atividade do Coletivo por não disporem de recursos materiais para fazê-lo podem solicitar ajuda de custos para o Coletivo. - -## Lucro e contas bancárias - -O Coletivo não possui fins lucrativos. Por isso, o Coletivo não se utiliza de operações financeiras com o intuito de auferir lucro, mas pode se utilizar de meios lícitos que lhe garantam a atualização monetária. - -Assim, quanto ao uso de transações e contas bancárias, o Coletivo reconhece que, apesar da segurança do dinheiro poder ser garantida de outras formas, a utilização de contas bancárias pode ser útil para - - * Facilitar a arrecadação financeira por dispor da rede bancária. - * Permitir a atualização financeira. - -O Coletivo reconhece as contradições de utilizar o sistema financeiro e por isso se compromete a utilizar somente o recurso da caderneta de poupança, que possui as seguintes características: - - * Baixo risco. - * Rendimentos baixos, uma vez que ela é basicamente apenas uma atualização monetária do dinheiro e por isso é praticamente o fundo de investimentos menos prejudicial à sociedade. - -## Licença - -Como estes critérios se utilizam de trechos oriundos dos [http://encontro.fluxo.org/Principal/ConjuntoDePrincipiosEticos Princípios das mídias e grupos livres]), segue a seguinte licença de manipulação dos mesmos (disponível também [http://encontro.fluxo.org/Principal/Licenca aqui]): - - 1. Licença de Manipulação do Conteúdo Deste Sítio - - Copyright (c) Encontro: Cultura Livre e Capitalismo: desde que não mencionado - em contrário, este conteúdo é distribuído de acordo com a licença a seguir. - - 2. Liberdades atribuídas ao/à licenciado/a - - Atribui ao detentor/a da informação as seguintes liberdades: - - 1. A liberdade de armazenar a informação. - 2. A liberdade de manipular a informação. - 3. A liberdade de distribuir a informação, modificada ou não. - - Desde que as condições listada na seção Obrigações do/a licenciado/a a seguir - sejam respeitadas. - - 3. Obrigações do/a licenciado - - 3.1 Viralidade - - * Desde que esta licença acompanhe a informação. - - 3.2 Restrição mercantil - - * Desde que para fins não-lucrativos. - - 3.3 Restrição de autoria e fonte - - * Desde que a fonte seja citada. diff --git a/coletivo/contabilidade/planejamento.md b/coletivo/contabilidade/planejamento.md new file mode 100644 index 0000000..d54fe25 --- /dev/null +++ b/coletivo/contabilidade/planejamento.md @@ -0,0 +1,17 @@ +[[!meta title="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/coletivo/contabilidade/planejamento.mdwn b/coletivo/contabilidade/planejamento.mdwn deleted file mode 100644 index d54fe25..0000000 --- a/coletivo/contabilidade/planejamento.mdwn +++ /dev/null @@ -1,17 +0,0 @@ -[[!meta title="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/coletivo/interpretacoes.md b/coletivo/interpretacoes.md new file mode 100644 index 0000000..88cf2d2 --- /dev/null +++ b/coletivo/interpretacoes.md @@ -0,0 +1,378 @@ +[[!meta title="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/coletivo/interpretacoes.mdwn b/coletivo/interpretacoes.mdwn deleted file mode 100644 index 88cf2d2..0000000 --- a/coletivo/interpretacoes.mdwn +++ /dev/null @@ -1,378 +0,0 @@ -[[!meta title="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/coletivo/misc.md b/coletivo/misc.md new file mode 100644 index 0000000..b2dbfff --- /dev/null +++ b/coletivo/misc.md @@ -0,0 +1,3 @@ +[[!meta title="Misc"]] + +[[!map pages="page(misc*)" show="title"]] diff --git a/coletivo/misc.mdwn b/coletivo/misc.mdwn deleted file mode 100644 index b2dbfff..0000000 --- a/coletivo/misc.mdwn +++ /dev/null @@ -1,3 +0,0 @@ -[[!meta title="Misc"]] - -[[!map pages="page(misc*)" show="title"]] diff --git a/coletivo/misc/ata.md b/coletivo/misc/ata.md new file mode 100644 index 0000000..57d9dd2 --- /dev/null +++ b/coletivo/misc/ata.md @@ -0,0 +1,22 @@ +[[!meta title="Ata de reunião"]] + +# Reunião de ../../.... + + * Horário: ..:.. + * Local: ... (Cidade). + * Caráter: ... + * Presentes: ... + +# Ata + +## Informes + +... + +## Próximas reuniões + +... + +## Outras questões + +... diff --git a/coletivo/misc/ata.mdwn b/coletivo/misc/ata.mdwn deleted file mode 100644 index 57d9dd2..0000000 --- a/coletivo/misc/ata.mdwn +++ /dev/null @@ -1,22 +0,0 @@ -[[!meta title="Ata de reunião"]] - -# Reunião de ../../.... - - * Horário: ..:.. - * Local: ... (Cidade). - * Caráter: ... - * Presentes: ... - -# Ata - -## Informes - -... - -## Próximas reuniões - -... - -## Outras questões - -... diff --git a/coletivo/misc/atualizacao.md b/coletivo/misc/atualizacao.md new file mode 100644 index 0000000..560e64c --- /dev/null +++ b/coletivo/misc/atualizacao.md @@ -0,0 +1,25 @@ +[[!meta title="Atualização de processo"]] + +O presente processo efetua a atualização do seguinte processo: + + * `$processo` + +O novo texto para o processo é o seguinte: + + $novo_texto + +Condições de atualização +------------------------ + + * O processo só pode ser atualizado se as pessoas responsabilizadas pelo mesmo concordarem explicitamente com isso. Caso elas não concordem este processo deve ser arquivado. + * No ticket do processo deve haver uma menção à atualização efetuada e com referência ao processo que o alterou. + +Responsabilização +----------------- + +As pessoas responsáveis pelo presente processo devem efetivar a atualização do processo de acordo com as condições mencionadas anteriormente. + +Sobre este texto +---------------- + +O texto deste processo foi redigido utilizando o [Template para Atualização de Processo](/organizacao/misc/atualizacao). No caso de alterações que não dizem respeito apenas ao Grupo e que possam enriquecer tal template, favor submetê-las também upstream, isto é, ao texto do template. diff --git a/coletivo/misc/atualizacao.mdwn b/coletivo/misc/atualizacao.mdwn deleted file mode 100644 index 560e64c..0000000 --- a/coletivo/misc/atualizacao.mdwn +++ /dev/null @@ -1,25 +0,0 @@ -[[!meta title="Atualização de processo"]] - -O presente processo efetua a atualização do seguinte processo: - - * `$processo` - -O novo texto para o processo é o seguinte: - - $novo_texto - -Condições de atualização ------------------------- - - * O processo só pode ser atualizado se as pessoas responsabilizadas pelo mesmo concordarem explicitamente com isso. Caso elas não concordem este processo deve ser arquivado. - * No ticket do processo deve haver uma menção à atualização efetuada e com referência ao processo que o alterou. - -Responsabilização ------------------ - -As pessoas responsáveis pelo presente processo devem efetivar a atualização do processo de acordo com as condições mencionadas anteriormente. - -Sobre este texto ----------------- - -O texto deste processo foi redigido utilizando o [Template para Atualização de Processo](/organizacao/misc/atualizacao). No caso de alterações que não dizem respeito apenas ao Grupo e que possam enriquecer tal template, favor submetê-las também upstream, isto é, ao texto do template. diff --git a/coletivo/misc/autorizacao.md b/coletivo/misc/autorizacao.md new file mode 100644 index 0000000..cb87a66 --- /dev/null +++ b/coletivo/misc/autorizacao.md @@ -0,0 +1,31 @@ +[[!meta title="Template para Autorização de Uso de Conteúdo"]] + +Por este processo, `$entidade` fica autorizada a utilizar os seguintes conteúdos do Coletivo: + + 1. `$conteudo` + +Com as seguintes permissões: + + 1. Distribuição do conteúdo nos seguintes meios: + a. Digital. + b. Impresso. + c. Audiovisual. + 2. Alteração do conteúdo mediante inclusão de nota descrevendo as mudanças efetuadas. + 3. Vigente para versões anteriores e futuras do conteúdo. + +Com as seguintes restrições: + + 1. Impedido o uso comercial ou fins lucrativos. + 2. A preservação da licença original do conteúdo. + 3. Uso restrito apenas para a publicação intitulada `$publicacao`. + 4. A validade desta permissão é de `$validade`, podendo ou não ser renovada. + +# Dependências + +A realização deste processo depende da realização dos seguintes processos: + +* [Licenciamento de informações](/organizacao/license). + +# Sobre este texto + +O texto deste processo foi redigido utilizando o [Template para Autorização de Uso de Conteúdo/organizacao/misc/autorizacao]. No caso de alterações que não dizem respeito apenas ao Grupo e que possam enriquecer tal template, favor submetê-las também upstream, isto é, ao texto do template. diff --git a/coletivo/misc/autorizacao.mdwn b/coletivo/misc/autorizacao.mdwn deleted file mode 100644 index cb87a66..0000000 --- a/coletivo/misc/autorizacao.mdwn +++ /dev/null @@ -1,31 +0,0 @@ -[[!meta title="Template para Autorização de Uso de Conteúdo"]] - -Por este processo, `$entidade` fica autorizada a utilizar os seguintes conteúdos do Coletivo: - - 1. `$conteudo` - -Com as seguintes permissões: - - 1. Distribuição do conteúdo nos seguintes meios: - a. Digital. - b. Impresso. - c. Audiovisual. - 2. Alteração do conteúdo mediante inclusão de nota descrevendo as mudanças efetuadas. - 3. Vigente para versões anteriores e futuras do conteúdo. - -Com as seguintes restrições: - - 1. Impedido o uso comercial ou fins lucrativos. - 2. A preservação da licença original do conteúdo. - 3. Uso restrito apenas para a publicação intitulada `$publicacao`. - 4. A validade desta permissão é de `$validade`, podendo ou não ser renovada. - -# Dependências - -A realização deste processo depende da realização dos seguintes processos: - -* [Licenciamento de informações](/organizacao/license). - -# Sobre este texto - -O texto deste processo foi redigido utilizando o [Template para Autorização de Uso de Conteúdo/organizacao/misc/autorizacao]. No caso de alterações que não dizem respeito apenas ao Grupo e que possam enriquecer tal template, favor submetê-las também upstream, isto é, ao texto do template. diff --git a/coletivo/misc/debate.md b/coletivo/misc/debate.md new file mode 100644 index 0000000..cac39a0 --- /dev/null +++ b/coletivo/misc/debate.md @@ -0,0 +1,24 @@ +[[!meta title="Debate"]] + +Realização de um debate no `$local` ou em outro lugar conveniente (mas não pago e nem corporativo), eventualmente em parceria com o `$grupo`, de um debate sobre `$tema`. O evento seria oficialmente organizado pelo Coletivo e talvez pelo `$grupo` (caso topem) e portanto se trata de um processo formal. + +Tal evento é politicamente interessante ao Coletivo ao marcar presença no `$local`, além de preencher uma lacuna pela falta de debates sobre o assunto. + +As tarefas envolvidas são: + + * Marcar uma boa data. + * Reservar o `$local` ou local apropriado, juntamente equipamento necessário. + * Convidar palestrantes que entendam do assunto e possuam visão crítica. + * Fazer, imprimir e afixar cartazes em locais chaves. + * Divulgação pela internet e eventualmente pelo Portal do Coletivo. + * Realizar o debate, fazendo a mediação se necessário. + +Observações: + + * O debate não terá o apoio de organizações corporativas ou estatais e não contará com financiamento. + * As pessoas do Coletivo que estiverem presentes na mesa não falarão em nome do Coletivo. + +Sobre este texto +---------------- + +O texto deste processo foi redigido utilizando o [Template para Debate](/organizacao/misc/debate). No caso de alterações que não dizem respeito apenas ao Grupo e que possam enriquecer tal template, favor submetê-las também upstream, isto é, ao texto do template. diff --git a/coletivo/misc/debate.mdwn b/coletivo/misc/debate.mdwn deleted file mode 100644 index cac39a0..0000000 --- a/coletivo/misc/debate.mdwn +++ /dev/null @@ -1,24 +0,0 @@ -[[!meta title="Debate"]] - -Realização de um debate no `$local` ou em outro lugar conveniente (mas não pago e nem corporativo), eventualmente em parceria com o `$grupo`, de um debate sobre `$tema`. O evento seria oficialmente organizado pelo Coletivo e talvez pelo `$grupo` (caso topem) e portanto se trata de um processo formal. - -Tal evento é politicamente interessante ao Coletivo ao marcar presença no `$local`, além de preencher uma lacuna pela falta de debates sobre o assunto. - -As tarefas envolvidas são: - - * Marcar uma boa data. - * Reservar o `$local` ou local apropriado, juntamente equipamento necessário. - * Convidar palestrantes que entendam do assunto e possuam visão crítica. - * Fazer, imprimir e afixar cartazes em locais chaves. - * Divulgação pela internet e eventualmente pelo Portal do Coletivo. - * Realizar o debate, fazendo a mediação se necessário. - -Observações: - - * O debate não terá o apoio de organizações corporativas ou estatais e não contará com financiamento. - * As pessoas do Coletivo que estiverem presentes na mesa não falarão em nome do Coletivo. - -Sobre este texto ----------------- - -O texto deste processo foi redigido utilizando o [Template para Debate](/organizacao/misc/debate). No caso de alterações que não dizem respeito apenas ao Grupo e que possam enriquecer tal template, favor submetê-las também upstream, isto é, ao texto do template. diff --git a/coletivo/misc/grupos.md b/coletivo/misc/grupos.md new file mode 100644 index 0000000..45ba939 --- /dev/null +++ b/coletivo/misc/grupos.md @@ -0,0 +1,55 @@ +[[!meta title="Participação no $grupo"]] + +Este processo estabelece a participação do Coletivo no $grupo, doravante mencionado neste texto tanto como $grupo ou simplesmente como '''Grupo'''. + +# Descrição do Grupo + +A descrever. + +# Informações de contato e comunicação + +A descrever. + +# Critérios de privacidade e segurança do Grupo + +A descrever. + +# Descrição das tarefas relacionadas + +Considerando que: + + 1. Não se pode assumir que todas as pessoas do Coletivo estejam participando ativamente do Grupo e que + 2. O Coletivo precisa discutir, propor e emitir posições acerca de questões relativas ao Grupo. + +As tarefas para a participação no Grupo consistem em: + + 1. Levar do Grupo para o Coletivo as questões a serem discutidas, decididas e/ou que sejam de interesse do Coletivo ou de pessoas do Coletivo, documentando na medida do possível os processos relacionados nas instâncias e seções correpondentes do Coletivo usadas para tais fins. + 2. Levar do Coletivo para o Grupo as propostas, discussões, sugestões e posicionamentos que partirem do Coletivo e cujo envio estiver aprovado, documentando na medida do possível os processos relacionados nas instâncias e seções correpondentes do Grupo usadas para tais fins. + 3. Providenciar ao Coletivo ou à pessoas do Coletivo informações disponíveis no Grupo mediante requisição da parte interessada. + +# Responsabilização + +Em todos os casos, as pessoas responsabilizadas: + + 1. Se comunicarão do Grupo para o Coletivo (e vice-versa) observando os critérios de privacidade segurança do Coletivo e do Grupo. + 2. Informarão explicitamente, caso estejam repassando informações que o Coletivo envia para o Grupo, que tais informações representam uma comunicação oficial e formal do Coletivo. Nos demais casos, recomenda-se que as pessoas responsáveis informem explicitamente que estão se comunicando informalmente e/ou que a comunicação não representa a posição do Coletivo. + 3. Realizarão, na medida do possível, a tradução de comunicação de e para o português, nos casos em que a mesma precise ser realizada noutro idioma. + +Cabe ainda observar que: + + 1. As pessoas responsáveis por tal comunicação entre o Coletivo e o Grupo são denominadas de ''[http://en.wikipedia.org/wiki/Liaison liaisons]'' entre o Coletivo e o Grupo, podendo atuar também como ''[http://en.wikipedia.org/wiki/Proxy proxies]'' para pessoas do Coletivo, isto é, enviar informações para o Grupo oriundas de pessoas do Coletivo que não queiram se identificar. + 2. Cabe aos/às ''liaisons'' dividirem entre si se organizarem para dividir as tarefas relativas ao acompanhamento e repasse de informações do Coletivo para o Grupo e vice-versa. + 3. Oas/as '''liasons''' respeitarão e observarão os critérios, regras e sugestões de conduta, comunicação e etiqueta tanto do Grupo quando do Coletivo. + +# Compartilhamento de informações + +Caso o Grupo mantenha comunicações em outros idiomas que não o português, é possível ainda compartilhar informações sobre o Grupo que não sejam específicas/internas do Coletivo entre outros grupos lusófonos/brasileiros que também estão no Grupo, desde que isso seja feito atendendo os critérios de segurança e privacidade do Grupo e do Coletivo. + +Além disso, tal repasse de informações: + + 1. Não é de responsabilidade dos/as ''liaisons''. + 2. Precisa de autorização do Coletivo. + +# Sobre este texto + +O texto deste processo foi redigido utilizando o [wiki:PageTemplates/ParticipacaoEmGruposExternos Template para Participação em Grupos Externos]. No caso de alterações que não dizem respeito apenas ao Grupo e que possam enriquecer tal template, favor submetê-las também ''upstream'', isto é, ao texto do template. diff --git a/coletivo/misc/grupos.mdwn b/coletivo/misc/grupos.mdwn deleted file mode 100644 index 45ba939..0000000 --- a/coletivo/misc/grupos.mdwn +++ /dev/null @@ -1,55 +0,0 @@ -[[!meta title="Participação no $grupo"]] - -Este processo estabelece a participação do Coletivo no $grupo, doravante mencionado neste texto tanto como $grupo ou simplesmente como '''Grupo'''. - -# Descrição do Grupo - -A descrever. - -# Informações de contato e comunicação - -A descrever. - -# Critérios de privacidade e segurança do Grupo - -A descrever. - -# Descrição das tarefas relacionadas - -Considerando que: - - 1. Não se pode assumir que todas as pessoas do Coletivo estejam participando ativamente do Grupo e que - 2. O Coletivo precisa discutir, propor e emitir posições acerca de questões relativas ao Grupo. - -As tarefas para a participação no Grupo consistem em: - - 1. Levar do Grupo para o Coletivo as questões a serem discutidas, decididas e/ou que sejam de interesse do Coletivo ou de pessoas do Coletivo, documentando na medida do possível os processos relacionados nas instâncias e seções correpondentes do Coletivo usadas para tais fins. - 2. Levar do Coletivo para o Grupo as propostas, discussões, sugestões e posicionamentos que partirem do Coletivo e cujo envio estiver aprovado, documentando na medida do possível os processos relacionados nas instâncias e seções correpondentes do Grupo usadas para tais fins. - 3. Providenciar ao Coletivo ou à pessoas do Coletivo informações disponíveis no Grupo mediante requisição da parte interessada. - -# Responsabilização - -Em todos os casos, as pessoas responsabilizadas: - - 1. Se comunicarão do Grupo para o Coletivo (e vice-versa) observando os critérios de privacidade segurança do Coletivo e do Grupo. - 2. Informarão explicitamente, caso estejam repassando informações que o Coletivo envia para o Grupo, que tais informações representam uma comunicação oficial e formal do Coletivo. Nos demais casos, recomenda-se que as pessoas responsáveis informem explicitamente que estão se comunicando informalmente e/ou que a comunicação não representa a posição do Coletivo. - 3. Realizarão, na medida do possível, a tradução de comunicação de e para o português, nos casos em que a mesma precise ser realizada noutro idioma. - -Cabe ainda observar que: - - 1. As pessoas responsáveis por tal comunicação entre o Coletivo e o Grupo são denominadas de ''[http://en.wikipedia.org/wiki/Liaison liaisons]'' entre o Coletivo e o Grupo, podendo atuar também como ''[http://en.wikipedia.org/wiki/Proxy proxies]'' para pessoas do Coletivo, isto é, enviar informações para o Grupo oriundas de pessoas do Coletivo que não queiram se identificar. - 2. Cabe aos/às ''liaisons'' dividirem entre si se organizarem para dividir as tarefas relativas ao acompanhamento e repasse de informações do Coletivo para o Grupo e vice-versa. - 3. Oas/as '''liasons''' respeitarão e observarão os critérios, regras e sugestões de conduta, comunicação e etiqueta tanto do Grupo quando do Coletivo. - -# Compartilhamento de informações - -Caso o Grupo mantenha comunicações em outros idiomas que não o português, é possível ainda compartilhar informações sobre o Grupo que não sejam específicas/internas do Coletivo entre outros grupos lusófonos/brasileiros que também estão no Grupo, desde que isso seja feito atendendo os critérios de segurança e privacidade do Grupo e do Coletivo. - -Além disso, tal repasse de informações: - - 1. Não é de responsabilidade dos/as ''liaisons''. - 2. Precisa de autorização do Coletivo. - -# Sobre este texto - -O texto deste processo foi redigido utilizando o [wiki:PageTemplates/ParticipacaoEmGruposExternos Template para Participação em Grupos Externos]. No caso de alterações que não dizem respeito apenas ao Grupo e que possam enriquecer tal template, favor submetê-las também ''upstream'', isto é, ao texto do template. diff --git a/coletivo/misc/rollcall.md b/coletivo/misc/rollcall.md new file mode 100644 index 0000000..f3ffda7 --- /dev/null +++ b/coletivo/misc/rollcall.md @@ -0,0 +1,13 @@ +[[!meta title="Rodada de Chamadas"]] + +A Rodada de Chamadas, também conhecida como [http://en.wikipedia.org/wiki/Roll_call roll call], é um procedimento utilizado para saber quem ainda participa de um grupo. Em cada rodada, das pessoas ausentes nas atividades do Coletivo, apenas aquelas que responderem permanecem no grupo conforme o [Processo de participação no Coletivo](/organizacao/coletiva/participacao). + +# Chamado + +As pessoas envolvidas no Coletivo que estiverem ausentes das atividades do Coletivo tem o período entre o início e o término da realização do processo para se pronunciarem a respeito da sua permanência no Coletivo, caso contrário estarão passíveis de retirada do Coletivo. + +Esta também pode ser considerada como uma oportunidade para as pessoas apresentarem suas atividades e seus anseios. :) + +# Sobre este texto + +O texto deste processo foi redigido utilizando o [Template para Rodada de Chamadas](/organizacao/misc/rollcall). No caso de alterações que não dizem respeito apenas ao Grupo e que possam enriquecer tal template, favor submetê-las também upstream, isto é, ao texto do template. diff --git a/coletivo/misc/rollcall.mdwn b/coletivo/misc/rollcall.mdwn deleted file mode 100644 index f3ffda7..0000000 --- a/coletivo/misc/rollcall.mdwn +++ /dev/null @@ -1,13 +0,0 @@ -[[!meta title="Rodada de Chamadas"]] - -A Rodada de Chamadas, também conhecida como [http://en.wikipedia.org/wiki/Roll_call roll call], é um procedimento utilizado para saber quem ainda participa de um grupo. Em cada rodada, das pessoas ausentes nas atividades do Coletivo, apenas aquelas que responderem permanecem no grupo conforme o [Processo de participação no Coletivo](/organizacao/coletiva/participacao). - -# Chamado - -As pessoas envolvidas no Coletivo que estiverem ausentes das atividades do Coletivo tem o período entre o início e o término da realização do processo para se pronunciarem a respeito da sua permanência no Coletivo, caso contrário estarão passíveis de retirada do Coletivo. - -Esta também pode ser considerada como uma oportunidade para as pessoas apresentarem suas atividades e seus anseios. :) - -# Sobre este texto - -O texto deste processo foi redigido utilizando o [Template para Rodada de Chamadas](/organizacao/misc/rollcall). No caso de alterações que não dizem respeito apenas ao Grupo e que possam enriquecer tal template, favor submetê-las também upstream, isto é, ao texto do template. diff --git a/coletivo/organizacao.md b/coletivo/organizacao.md new file mode 100644 index 0000000..a2efc7d --- /dev/null +++ b/coletivo/organizacao.md @@ -0,0 +1,102 @@ +[[!meta title="Protocolo de Ação Coletiva"]] + +Possíveis interpretações sobre o significado e o efeito deste protocolo se encontram [aqui](/organizacao/coletiva/interpretacoes). + +* Versão: 1.0. +* Licença: LIMICS[1]. +* Protocolos apresentados neste projeto podem ser aplicados através do esquema de "processos formais" definidos neste documento, o que inclui até mesmo o presente protocolo. + +Processos e autonomia +--------------------- + +Tudo o que ocorre no Coletivo é um processo. Os processos assumem diversas manifestações, mas principalmente são fluxos e registros desses fluxos (memória/informação). + +Existem dois tipos de processos: + +* Processos formais + * Forma necessariamente definida de antemão via consenso do coletivo E + * Lidam com a autonomia do coletivo. PORTANTO + * Precisam ser acompanhados pela responsabilização mínima para o processo não falhar por falta de iniciativa + +* Processos informais + * Forma não necessariamente definida de antemão E + * Não afetam a autonomia do coletivo. PORTANTO + * Não precisam necessariamente estar atrelados à responsabilidade de alguém (isto é, a não-realização de um processo informal não afeta a autonomia do Coletivo) + +Atividades sem informação disponibilizada no Coletivo não podem ser consideradas como processos (formais ou informais) do Coletivo porque não dispõem de igualdade de acesso à informação, requisito para a possibilidade de participação (isonomia informacional). + +A autonomia básica do Coletivo, isto é, a autonomia mínima que garante a sua existência de acordo com este protocolo, é a posse de canais (instâncias) de comunicação privados e seguros que permitam a existência dos registros de processos coletivos (formais ou informais). Sem esses canais, a autonomia básica do Coletivo é seriamente abalada, assim como a aplicação deste protocolo. Toda autonomia adicional do Coletivo (isto é, que não for a autonomia básica) deve ser definida através de processos formais. + +Um/a integrante do Coletivo atua dentro dele quando utiliza os recursos e o nome do Coletivo. Por outro lado, um/a integrante do Coletivo atua fora dele quando não utiliza os recursos ou o nome do Coletivo. Intregrantes do Coletivo não realizam ações (dentro ou fora do Coletivo) que, conscientemente, possam prejudicar a autonomia do Coletivo. + +Processos Formais +----------------- + +Os processos formais possuem as etapas e os andamentos de acordo com o fluxograma a seguir: + + .------------------->-----------------. + / .----------<--------------<-------. \ + | ' \ \ + | | .------>-----. \ \ + | | | \ \ \ + Proposta -----> Discussão ->--. \ \ \ + | ^ | \ \ \ \ + | | | \ \ \ \ + | `----<-----' | \ \ \ + | | | \ \ + `------>------ Decisão --<--' | \ \ + | | | \ \ + | | | | | + Atribuição de --<---' '---> Arquivamento --->---' ; + Responsabilidades ----->-------' ^ \ / + ^ | ___________/ `---<-----' + | \ .' + | `--> Realização -->--. + | | | \ + | | | / + `----<-----' `-----<---' + + * Proposta: etapa na qual a idéia de um procedimento formal é lançado ao Coletivo. A idéia -- ou descrição -- do processo pode vir do Arquivo de propostas, de uma Discussão anterior, de um procedimento informal que se julga importante formalizar ou mesmo de uma pessoa ou grupo de pessoas de dentro ou de fora do Coletivo. Recomenda-se que ela seja bem explicada e contenha: sugestão de prazo de decisão, ciclo de vida do processo, critérios e prazo para atribuição de responsabilidade assim como recomendações para situações emergenciais (quando aplicável). + + * Discussão: + * Não é uma etapa estritamente necessária, mas não deixa de ter importância. + * Alterações em propostas fazem com que o procedimento formal em questão volte para a etapa de Proposta. Propostas que não seguirem para a etapa de Decisão ou que não forem alteradas até o prazo proposto devem ser arquivadas. + * Propostas que vem de fora do Coletivo ou que tenham como participantes grupos ou pessoas de fora do coletivo e que forem discutidas e alteradas devem ser enviadas também para o grupo ou à pessoa de fora do Coletivo responsável pela sua introdução, apesar destas pessoas não participarem da discussão interna do Coletivo. Se tal pessoa ou grupo concordar com a proposta alterada, então o processo formal em questão retorna à etapa de Discussão com a nova proposta. Caso contrário, isto é, a pessoa ou grupo de fora do Coletivo não concordar com a proposta alterada, então o processo formal em questão é arquivado (exceto se as partes externas apresentarem uma nova alteração à proposta ou mais argumentos à discussão). + + * Decisão: + * Via consenso e a participação ativa depende do acompanhamento das informações do Coletivo requeridas pela proposta em questão. + * Se não há consenso sobre a aprovação de uma proposta, a mesma permanece bloqueada, podendo ter seu prazo estendido. + * 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/coletivo/organizacao.mdwn b/coletivo/organizacao.mdwn deleted file mode 100644 index a2efc7d..0000000 --- a/coletivo/organizacao.mdwn +++ /dev/null @@ -1,102 +0,0 @@ -[[!meta title="Protocolo de Ação Coletiva"]] - -Possíveis interpretações sobre o significado e o efeito deste protocolo se encontram [aqui](/organizacao/coletiva/interpretacoes). - -* Versão: 1.0. -* Licença: LIMICS[1]. -* Protocolos apresentados neste projeto podem ser aplicados através do esquema de "processos formais" definidos neste documento, o que inclui até mesmo o presente protocolo. - -Processos e autonomia ---------------------- - -Tudo o que ocorre no Coletivo é um processo. Os processos assumem diversas manifestações, mas principalmente são fluxos e registros desses fluxos (memória/informação). - -Existem dois tipos de processos: - -* Processos formais - * Forma necessariamente definida de antemão via consenso do coletivo E - * Lidam com a autonomia do coletivo. PORTANTO - * Precisam ser acompanhados pela responsabilização mínima para o processo não falhar por falta de iniciativa - -* Processos informais - * Forma não necessariamente definida de antemão E - * Não afetam a autonomia do coletivo. PORTANTO - * Não precisam necessariamente estar atrelados à responsabilidade de alguém (isto é, a não-realização de um processo informal não afeta a autonomia do Coletivo) - -Atividades sem informação disponibilizada no Coletivo não podem ser consideradas como processos (formais ou informais) do Coletivo porque não dispõem de igualdade de acesso à informação, requisito para a possibilidade de participação (isonomia informacional). - -A autonomia básica do Coletivo, isto é, a autonomia mínima que garante a sua existência de acordo com este protocolo, é a posse de canais (instâncias) de comunicação privados e seguros que permitam a existência dos registros de processos coletivos (formais ou informais). Sem esses canais, a autonomia básica do Coletivo é seriamente abalada, assim como a aplicação deste protocolo. Toda autonomia adicional do Coletivo (isto é, que não for a autonomia básica) deve ser definida através de processos formais. - -Um/a integrante do Coletivo atua dentro dele quando utiliza os recursos e o nome do Coletivo. Por outro lado, um/a integrante do Coletivo atua fora dele quando não utiliza os recursos ou o nome do Coletivo. Intregrantes do Coletivo não realizam ações (dentro ou fora do Coletivo) que, conscientemente, possam prejudicar a autonomia do Coletivo. - -Processos Formais ------------------ - -Os processos formais possuem as etapas e os andamentos de acordo com o fluxograma a seguir: - - .------------------->-----------------. - / .----------<--------------<-------. \ - | ' \ \ - | | .------>-----. \ \ - | | | \ \ \ - Proposta -----> Discussão ->--. \ \ \ - | ^ | \ \ \ \ - | | | \ \ \ \ - | `----<-----' | \ \ \ - | | | \ \ - `------>------ Decisão --<--' | \ \ - | | | \ \ - | | | | | - Atribuição de --<---' '---> Arquivamento --->---' ; - Responsabilidades ----->-------' ^ \ / - ^ | ___________/ `---<-----' - | \ .' - | `--> Realização -->--. - | | | \ - | | | / - `----<-----' `-----<---' - - * Proposta: etapa na qual a idéia de um procedimento formal é lançado ao Coletivo. A idéia -- ou descrição -- do processo pode vir do Arquivo de propostas, de uma Discussão anterior, de um procedimento informal que se julga importante formalizar ou mesmo de uma pessoa ou grupo de pessoas de dentro ou de fora do Coletivo. Recomenda-se que ela seja bem explicada e contenha: sugestão de prazo de decisão, ciclo de vida do processo, critérios e prazo para atribuição de responsabilidade assim como recomendações para situações emergenciais (quando aplicável). - - * Discussão: - * Não é uma etapa estritamente necessária, mas não deixa de ter importância. - * Alterações em propostas fazem com que o procedimento formal em questão volte para a etapa de Proposta. Propostas que não seguirem para a etapa de Decisão ou que não forem alteradas até o prazo proposto devem ser arquivadas. - * Propostas que vem de fora do Coletivo ou que tenham como participantes grupos ou pessoas de fora do coletivo e que forem discutidas e alteradas devem ser enviadas também para o grupo ou à pessoa de fora do Coletivo responsável pela sua introdução, apesar destas pessoas não participarem da discussão interna do Coletivo. Se tal pessoa ou grupo concordar com a proposta alterada, então o processo formal em questão retorna à etapa de Discussão com a nova proposta. Caso contrário, isto é, a pessoa ou grupo de fora do Coletivo não concordar com a proposta alterada, então o processo formal em questão é arquivado (exceto se as partes externas apresentarem uma nova alteração à proposta ou mais argumentos à discussão). - - * Decisão: - * Via consenso e a participação ativa depende do acompanhamento das informações do Coletivo requeridas pela proposta em questão. - * Se não há consenso sobre a aprovação de uma proposta, a mesma permanece bloqueada, podendo ter seu prazo estendido. - * 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/coletivo/participacao.md b/coletivo/participacao.md new file mode 100644 index 0000000..20dd03f --- /dev/null +++ b/coletivo/participacao.md @@ -0,0 +1,83 @@ +[[!meta title="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 [roll call](/organizacao/misc/rollcall). + +Critérios de segurança +---------------------- + +Levando em conta que o Coletivo abriga informações de muita gente, é importante que exista um nível de segurança mais alto do que a média): + + 1. Ter a pasta pessoal e área de troca (swap) criptografadas. + 2. Utilizar senhas seguras. + 3. Utilizar criptografia GPG. + 4. Verificar fingerprints em servidores, etc. + 5. Demais [recomendações](/organizacao/comunicacao/infosec). + +Privacidade +----------- + +É uma escolha de cada participante se manter como membro privado ou mencionar que faz parte do Coletivo, seja publicamente ou em círculos restritos. + +Congelamento e término de participação +-------------------------------------- + +Nos casos de problemas pessoais, o Coletivo pode, mediante processo formal, congelar temporariamente a participação de alguma pessoa no Coletivo. + +No caso de congelamento ou término de participação, a pessoa perde os acessos às camadas e interface de ACL 3 do Coletivo. + +Responsabilização +----------------- + +O Grupo de Trabalho formado pelas pessoas responsáveis pelo presente processo fica encarregado de zelar pela aplicabilidade do presente processo e de certificar que os acessos às interfaces e camadas das pessoas que se desligarem ou se afastarem do Coletivo sejam removidos. + +Retroatividade +-------------- + +O presente processo é retroativo, isto é, mesmo quem já participa do Coletivo antes da vigência do processo precisa passar por ele, por uma questão de isonomia. diff --git a/coletivo/participacao.mdwn b/coletivo/participacao.mdwn deleted file mode 100644 index 20dd03f..0000000 --- a/coletivo/participacao.mdwn +++ /dev/null @@ -1,83 +0,0 @@ -[[!meta title="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 [roll call](/organizacao/misc/rollcall). - -Critérios de segurança ----------------------- - -Levando em conta que o Coletivo abriga informações de muita gente, é importante que exista um nível de segurança mais alto do que a média): - - 1. Ter a pasta pessoal e área de troca (swap) criptografadas. - 2. Utilizar senhas seguras. - 3. Utilizar criptografia GPG. - 4. Verificar fingerprints em servidores, etc. - 5. Demais [recomendações](/organizacao/comunicacao/infosec). - -Privacidade ------------ - -É uma escolha de cada participante se manter como membro privado ou mencionar que faz parte do Coletivo, seja publicamente ou em círculos restritos. - -Congelamento e término de participação --------------------------------------- - -Nos casos de problemas pessoais, o Coletivo pode, mediante processo formal, congelar temporariamente a participação de alguma pessoa no Coletivo. - -No caso de congelamento ou término de participação, a pessoa perde os acessos às camadas e interface de ACL 3 do Coletivo. - -Responsabilização ------------------ - -O Grupo de Trabalho formado pelas pessoas responsáveis pelo presente processo fica encarregado de zelar pela aplicabilidade do presente processo e de certificar que os acessos às interfaces e camadas das pessoas que se desligarem ou se afastarem do Coletivo sejam removidos. - -Retroatividade --------------- - -O presente processo é retroativo, isto é, mesmo quem já participa do Coletivo antes da vigência do processo precisa passar por ele, por uma questão de isonomia. diff --git a/coletivo/responsabilizacao.md b/coletivo/responsabilizacao.md new file mode 100644 index 0000000..6fb994e --- /dev/null +++ b/coletivo/responsabilizacao.md @@ -0,0 +1,15 @@ +[[!meta title="Termo de responsabilização"]] + + Me compromento a me responsabilizar pela realização da tarefa/processo X + de acordo com os termos indicados na descrição da tarefa/processo e + mantendo o coletivo informado do seu andamento. + + Caso não possa mais manter minha responsabilização, me comprometo a + informar o coletivo com antecedência. + + No caso do encerramento da minha responsabilização acarretar numa + responsabilidade mínima menor do que aquela especificada pela tarefa/processo, + me comprometo também e a passá-la para frente ou, na ausência de pessoas + que componham a responsabilidade mínima, me comprometo a arquivar a + tarefa/processo, levando em conta os procedimentos específicos para + o caso. diff --git a/coletivo/responsabilizacao.mdwn b/coletivo/responsabilizacao.mdwn deleted file mode 100644 index 6fb994e..0000000 --- a/coletivo/responsabilizacao.mdwn +++ /dev/null @@ -1,15 +0,0 @@ -[[!meta title="Termo de responsabilização"]] - - Me compromento a me responsabilizar pela realização da tarefa/processo X - de acordo com os termos indicados na descrição da tarefa/processo e - mantendo o coletivo informado do seu andamento. - - Caso não possa mais manter minha responsabilização, me comprometo a - informar o coletivo com antecedência. - - No caso do encerramento da minha responsabilização acarretar numa - responsabilidade mínima menor do que aquela especificada pela tarefa/processo, - me comprometo também e a passá-la para frente ou, na ausência de pessoas - que componham a responsabilidade mínima, me comprometo a arquivar a - tarefa/processo, levando em conta os procedimentos específicos para - o caso. diff --git a/english.md b/english.md new file mode 100644 index 0000000..f73e68b --- /dev/null +++ b/english.md @@ -0,0 +1,3 @@ +[[!meta title="English Templates"]] + +[[!map pages="page(english*)" show="title"]] diff --git a/english.mdwn b/english.mdwn deleted file mode 100644 index f73e68b..0000000 --- a/english.mdwn +++ /dev/null @@ -1,3 +0,0 @@ -[[!meta title="English Templates"]] - -[[!map pages="page(english*)" show="title"]] diff --git a/english/network.md b/english/network.md new file mode 100644 index 0000000..b3ab78c --- /dev/null +++ b/english/network.md @@ -0,0 +1,80 @@ +[[!meta title="Principles and process for a network of collectives"]] + +Originally [Network intentions and process letter](https://rectech.sarava.org/publico/processo). + +About +----- + +The `$network` network is a forum of anti-capitalist, anti-fascist, anti-sexists, +anti-homophobic and anti-racists tech collectives that rejects any form of +social domination and prejudice. + +The goal of the forum is to allow interchange, mutual aid and cooperation among +collective members and also to be a public interface for debates. + +Then, `$network` is not a collective but a network. + +How it works +------------ + +The network by default is in a dormant state until be activated, when for example +some collective(s) suggest an activity, meeting or cooperation. + +Membership process +------------------ + +Membership in the `$network` network is restrictet to collectives that comply with +afinity, trust and commitment to the network. New collectives can join the network +after positive decision making process and if they agree with this letter. + +Once inside the network, collectives can determine which of its members has to +be subscribed or unsubscribed from the `$network` network communication platforms. + +When joining on the `$network` network communication platforms, each individual has +to present her or himself and state that will act in a constructive way, +otherwise will be subjected to unsubscription. + +Decision making process +----------------------- + +No person or group can take decisions that affect the network autonomy before +consulting the network and getting a positive consensus. + +Decisions in the network are based on proposals that have to be sent to the +network's closed discussion list. + +The minimum deadline for decisions is two weeks up to postponing and the +decisions are taken by consensus. If a collective doesn't manifests about a +proposal it will be considered that the collective agrees with the proposal. + +Privacy +------- + +The `$network` network is semi-public, i.e, part of it's communication and +organization is restricted to the member collectives while other part is public +and open to any group or person. + +Informations that flows in private communication instances needs authorization +to be shared in public media (declassification). + +It's a choice of each member to stay or not as a private member. + +Communication interfaces +------------------------ + +The `$network` network has the following communication instances: + + - Closed list with archives restricted to its members. + - Moderated announcement list with open subscription and open archives. + - Collaborative web platform. + +Such interfaces are hosted by member or trusted collectives and it's access and +existence are crucial to the maintenance of the network memory. Then, it's +imprescindibile to the network to have backups of these platform when needed. + +About this text +--------------- + +This process was based on the "Template for Network Intentions and process letter v1.0". +License for the document: GNU Free Documentation License: +http://www.gnu.org/copyleft/fdl.html diff --git a/english/network.mdwn b/english/network.mdwn deleted file mode 100644 index b3ab78c..0000000 --- a/english/network.mdwn +++ /dev/null @@ -1,80 +0,0 @@ -[[!meta title="Principles and process for a network of collectives"]] - -Originally [Network intentions and process letter](https://rectech.sarava.org/publico/processo). - -About ------ - -The `$network` network is a forum of anti-capitalist, anti-fascist, anti-sexists, -anti-homophobic and anti-racists tech collectives that rejects any form of -social domination and prejudice. - -The goal of the forum is to allow interchange, mutual aid and cooperation among -collective members and also to be a public interface for debates. - -Then, `$network` is not a collective but a network. - -How it works ------------- - -The network by default is in a dormant state until be activated, when for example -some collective(s) suggest an activity, meeting or cooperation. - -Membership process ------------------- - -Membership in the `$network` network is restrictet to collectives that comply with -afinity, trust and commitment to the network. New collectives can join the network -after positive decision making process and if they agree with this letter. - -Once inside the network, collectives can determine which of its members has to -be subscribed or unsubscribed from the `$network` network communication platforms. - -When joining on the `$network` network communication platforms, each individual has -to present her or himself and state that will act in a constructive way, -otherwise will be subjected to unsubscription. - -Decision making process ------------------------ - -No person or group can take decisions that affect the network autonomy before -consulting the network and getting a positive consensus. - -Decisions in the network are based on proposals that have to be sent to the -network's closed discussion list. - -The minimum deadline for decisions is two weeks up to postponing and the -decisions are taken by consensus. If a collective doesn't manifests about a -proposal it will be considered that the collective agrees with the proposal. - -Privacy -------- - -The `$network` network is semi-public, i.e, part of it's communication and -organization is restricted to the member collectives while other part is public -and open to any group or person. - -Informations that flows in private communication instances needs authorization -to be shared in public media (declassification). - -It's a choice of each member to stay or not as a private member. - -Communication interfaces ------------------------- - -The `$network` network has the following communication instances: - - - Closed list with archives restricted to its members. - - Moderated announcement list with open subscription and open archives. - - Collaborative web platform. - -Such interfaces are hosted by member or trusted collectives and it's access and -existence are crucial to the maintenance of the network memory. Then, it's -imprescindibile to the network to have backups of these platform when needed. - -About this text ---------------- - -This process was based on the "Template for Network Intentions and process letter v1.0". -License for the document: GNU Free Documentation License: -http://www.gnu.org/copyleft/fdl.html diff --git a/english/organization.md b/english/organization.md new file mode 100644 index 0000000..fbe7395 --- /dev/null +++ b/english/organization.md @@ -0,0 +1,124 @@ +[[!meta title="Collective Action Protocol"]] + +The protocol was written to make possible a generic adoption by groups but at the same time it attempt to solve specific problems that aren't necessarily shared by a gvin group. Then, it's not intended to be "The Collective Protocol" but instead a suggestion about how to shape a collective protocol. + +Suggestion is to read it as how could a collective protocol look like instead a sugestion of adoption, especially because usually the needs for a process are different as here we're trying to solve a different set of problems. + +The Collective Action Protocol seems to be both a stateless (at it's informal part) and stateful (at it's formal part) protocol. It has some inspiration from: + +* Games, altough it's unknow how a parallel with game theory could be traced (could this protocol be considered a game where the objective is a win-win outcome attempting to maximize the collective effort?). +* Free and open source software development processes (although this protocol makes the 'benevolent dictator' obsolete as behaviour, purpose and telealogy turns to be mean properties emerging internally from the processes and peoples' wishes and mutual relationship). It can be thought as a social software (culture). +* Ways labor division can be organized to better fill collective needs and autonomy while encouraging people to work together. + +Characteristics +--------------- + +For sinthetic purposes, most of the discussion was split from the protocol text. Perhaps this compression let a lot of helpful information to be missing, so here comes a list of the main properties this protocol tries to achieve: + +* Resilience, robustness and failover. +* Ensure some collective autonomy is guaranteed (through formal process having responsibility attached) while not blocking the self-organizing efforts using to kinds of processes (formal and informal). This means in some way to overcome the [The Tyranny of Structurelessness](http://en.wikipedia.org/wiki/Tyranny_of_Structurelessness) while not failing back to over-structuration, bureaucracy, etc and at the same time tries to deal with apathy and missparticipation. +* For formal processes, splits decision-making (i.e, the step where the collective evals if a given proposal is pertinent an deserves the collective moral support) from the resposibility assignment (step where people actually volunteer to do the tasks) in a way that just formal processses that are under responsibility can be counted as processes that will very probably happen, so if in the proposal/discussion/decision steps just the content of the proposal is evalued, the responsibility assignment is a filter where just processes that finds people to achieve them are able to pass. +* Leting a process be also a registry eases the integration with a ticket system. + +Limitations +----------- + +Some limitations of the protocol are: + +* Not sure whether it's scalable. Maybe it was set for usage inside a small affinity group so it might not fit to big groups where people has not affinity between themselves. +* It does not deal with connections/disconnections, i.e, the protocol do not define how someone joins or leaves the group. +* As all protocols depends on it's usage, it is not a guarantee by itself that things are going to happen in the collective. The protocol just states how the energy is spent in the collective process but have no influence in the desire to act or not to act. +* It does not state what are the communication channels (both for formal and informal communications) and how they should be used. In fact, as this really varies a lot from collective to collective so it was chosen to leave that specific communication structure out of the Collective Action Protocol so it would be easier to share and have another protocol taking care of informational channels. + +Formality and informality +------------------------- + +In this protocol, what is a formal and what is an informal process really depends in how the collective wants to extend it's autonomy, so it's not a thing defined withing the protocol. Examples of formal and informal processes can be: + + * Informal processes: meetings, dinners, researching, write texts, code, talk with people, wikifarming and everything else that the collective thinks that does not changes the collective autonomy. + * Formal processes: the main activities the group is commited to do and what is crucial for them to happen and to keep the collective autonomy. + +Collective Action Protocol +-------------------------- + +* Version: 0.1. +* Raw english translation version (related to protocol version): 0.1. +* License: Sarava Content Distribution License (no translation for now :/) + +Processes and autonomy +---------------------- + +Everything that happens in the Collective is a process. Processes has different manifestations but are mainly fluxes and the registry of these fluxes (memory/information). + +There are two kinds of processes: + +* Formal processes + * Shape/form predefined by collective consensus AND + * Needs/use the collective autonomy THUS + * Needs to be followed by a minimum responsabilization so the process do not fail + +* Informal processes + * Shape/form not needed to be predefined AND + * Do not need/use the collective autonomy THUS + * Do not need to be under the resposability of someone, i.e, an informal process that do not happen doesn't affect the collective autonomy + +Activities without information in the collective cannot be considered by processes (formal or informal) as these activities do not have information equality/isonomy in the collective. To have information about a process is a requisite for participation and then an activity without information inside the collective cannot be considered as process. + +The basic autonomy of the Collective, i.e, the minimum autonomy that allows it's existence according to this protocol is the existence of secure and private communication channels that allows the existence of collective processes (formal or informal). Without these channels, the basic collective autonomy is seriously damaged as well as the application of this protocol. All aditional autonomy in the collective (i.e, autonomy that is not contained in the basic autonomy) should be defined with formal processes. + +A collective member act inside the collective when use it's resources or the collective name. By the other hand, a collective member act outside of the collective when do not use such resources or the collective name. Collective members do not make actions (inside or outside the collective) that consciouslly can cause damage to the collective autonomy. + +Formal processes +---------------- + +Each formal processs is an instance of the following state diagram: + + .------------------->-----------------. + / .----------<--------------<-------. \ + | ' \ \ + | | .------>-----. \ \ + | | | \ \ \ + Proposal -----> Discussion ->-. \ \ \ + | ^ | \ \ \ \ + | | | \ \ \ \ + | `----<-----' | \ \ \ + | | | \ \ + `------>----- Decision --<--' | \ \ + | | | \ \ + | | | | | + Responsibility --<---' '------> Archiving --->---' ; + Assignment --------->---------' ^ \ / + ^ | ___________/ `---<-----' + | \ .' + | `--> Achievement ->--. + | | | \ + | | | / + `----<-----' `-----<---' + +* Proposal: step where an idea of a formal process is presented to the collective. The idea ' or description ' can come for the Archive, from a previous Discussion, from an informal process that needs to be formalized or from a person or group from inside or outside the collective. General recomendation is to give a good explanation of the idea containing: deadline sugestion, process life cycle, responsibility assignment criteria and deadline and recomendations for emergencies (when appliable). + +* Discussion: + * It's not a mandatory step, but has importance anyway. + * Changes to proposals make the formal process go back to the Proposal state. Proposals that do not follow to the Decision step or do not get changes until it's deadline should be archived. + * Changed proposals that come from outside the collective or that have external groups or persons participation should be sent back also to the external group/person, despite these persons/groups do not participate in the internal discussion at the collective. If these external people/groups agree with the changed proposal, then the formal process proceeds with the discussion using the changed proposal. If that doesn't happen, i.e, these external people/groups don't agree with the changed proposal, then the formal process is archived (except if the external parties provide another changed proposal or more arguments to the discussion). + +* Decision: + * Through consensus and the active participation depends in following the information required by the proposal. + * If there's no consensus about the decision of a proposal it's automatically blocked with the possibility to extend it's deadline. + * Silence regarding a proposal is considered as an agreement. + * Deadline: general recomendation is to set deadlines relative to the average time needed by active people in the collective to take into account, discuss, make changes and ask for eventual postponing. Processes are elegible to postponing or advance it's deadline with an explicitly request from someone from the collective. If there's no such request, the initial deadline is assumed. + * Approvals from proposals coming from outside the collective or that have external people/groups involved are communicated about the approval just after the responsibility assignment. + +* Responsibility assignment + * Concerns the minimization of points of failure. + * Responsibilization is a volunteer action but requires the submission of a commitment/responsibilization term affirming that the person: + * Has knowledge about the procedure in question. + * Is gonna achieve it under the estimated deadline and is gonna keep the collective informed about the task. + * Will inform the collective in a reasonable timeframe if cannot continue to be involved with the process so the collective can keep the process going, assign new responsibilities or finnish it and send to the archive. + * Non-accomplishment with a process compromises the ability of someone to be responsible for other tasks. + * Formal processes that are approved but, after the responsibility assignment deadline, have unsufficient responsibilization assigned, should be sent to the archive. Proceesses in the archive were previously approved cannot be sent back directly to the responsibilty assigment and should instead go to the proposal step. + * In case of proposals coming from outside the collective or that have external people/groups involved, these people/groups should be informed of the approval just after the responsibility assignment, i.e, at the end of this step. + +* Achievement + * Just formal processes with sufficient responsibility assignment can go to the achievement step. Processes that were already achived goes to the archive. + * Formal processes that were not achieved in the deadline should come back to the Responsibility assignment step. In a similar way, processes whose assigned people cannot doing it should come back to the Responsibility assignment step if the number of assigned people is smaller than the required. diff --git a/english/organization.mdwn b/english/organization.mdwn deleted file mode 100644 index fbe7395..0000000 --- a/english/organization.mdwn +++ /dev/null @@ -1,124 +0,0 @@ -[[!meta title="Collective Action Protocol"]] - -The protocol was written to make possible a generic adoption by groups but at the same time it attempt to solve specific problems that aren't necessarily shared by a gvin group. Then, it's not intended to be "The Collective Protocol" but instead a suggestion about how to shape a collective protocol. - -Suggestion is to read it as how could a collective protocol look like instead a sugestion of adoption, especially because usually the needs for a process are different as here we're trying to solve a different set of problems. - -The Collective Action Protocol seems to be both a stateless (at it's informal part) and stateful (at it's formal part) protocol. It has some inspiration from: - -* Games, altough it's unknow how a parallel with game theory could be traced (could this protocol be considered a game where the objective is a win-win outcome attempting to maximize the collective effort?). -* Free and open source software development processes (although this protocol makes the 'benevolent dictator' obsolete as behaviour, purpose and telealogy turns to be mean properties emerging internally from the processes and peoples' wishes and mutual relationship). It can be thought as a social software (culture). -* Ways labor division can be organized to better fill collective needs and autonomy while encouraging people to work together. - -Characteristics ---------------- - -For sinthetic purposes, most of the discussion was split from the protocol text. Perhaps this compression let a lot of helpful information to be missing, so here comes a list of the main properties this protocol tries to achieve: - -* Resilience, robustness and failover. -* Ensure some collective autonomy is guaranteed (through formal process having responsibility attached) while not blocking the self-organizing efforts using to kinds of processes (formal and informal). This means in some way to overcome the [The Tyranny of Structurelessness](http://en.wikipedia.org/wiki/Tyranny_of_Structurelessness) while not failing back to over-structuration, bureaucracy, etc and at the same time tries to deal with apathy and missparticipation. -* For formal processes, splits decision-making (i.e, the step where the collective evals if a given proposal is pertinent an deserves the collective moral support) from the resposibility assignment (step where people actually volunteer to do the tasks) in a way that just formal processses that are under responsibility can be counted as processes that will very probably happen, so if in the proposal/discussion/decision steps just the content of the proposal is evalued, the responsibility assignment is a filter where just processes that finds people to achieve them are able to pass. -* Leting a process be also a registry eases the integration with a ticket system. - -Limitations ------------ - -Some limitations of the protocol are: - -* Not sure whether it's scalable. Maybe it was set for usage inside a small affinity group so it might not fit to big groups where people has not affinity between themselves. -* It does not deal with connections/disconnections, i.e, the protocol do not define how someone joins or leaves the group. -* As all protocols depends on it's usage, it is not a guarantee by itself that things are going to happen in the collective. The protocol just states how the energy is spent in the collective process but have no influence in the desire to act or not to act. -* It does not state what are the communication channels (both for formal and informal communications) and how they should be used. In fact, as this really varies a lot from collective to collective so it was chosen to leave that specific communication structure out of the Collective Action Protocol so it would be easier to share and have another protocol taking care of informational channels. - -Formality and informality -------------------------- - -In this protocol, what is a formal and what is an informal process really depends in how the collective wants to extend it's autonomy, so it's not a thing defined withing the protocol. Examples of formal and informal processes can be: - - * Informal processes: meetings, dinners, researching, write texts, code, talk with people, wikifarming and everything else that the collective thinks that does not changes the collective autonomy. - * Formal processes: the main activities the group is commited to do and what is crucial for them to happen and to keep the collective autonomy. - -Collective Action Protocol --------------------------- - -* Version: 0.1. -* Raw english translation version (related to protocol version): 0.1. -* License: Sarava Content Distribution License (no translation for now :/) - -Processes and autonomy ----------------------- - -Everything that happens in the Collective is a process. Processes has different manifestations but are mainly fluxes and the registry of these fluxes (memory/information). - -There are two kinds of processes: - -* Formal processes - * Shape/form predefined by collective consensus AND - * Needs/use the collective autonomy THUS - * Needs to be followed by a minimum responsabilization so the process do not fail - -* Informal processes - * Shape/form not needed to be predefined AND - * Do not need/use the collective autonomy THUS - * Do not need to be under the resposability of someone, i.e, an informal process that do not happen doesn't affect the collective autonomy - -Activities without information in the collective cannot be considered by processes (formal or informal) as these activities do not have information equality/isonomy in the collective. To have information about a process is a requisite for participation and then an activity without information inside the collective cannot be considered as process. - -The basic autonomy of the Collective, i.e, the minimum autonomy that allows it's existence according to this protocol is the existence of secure and private communication channels that allows the existence of collective processes (formal or informal). Without these channels, the basic collective autonomy is seriously damaged as well as the application of this protocol. All aditional autonomy in the collective (i.e, autonomy that is not contained in the basic autonomy) should be defined with formal processes. - -A collective member act inside the collective when use it's resources or the collective name. By the other hand, a collective member act outside of the collective when do not use such resources or the collective name. Collective members do not make actions (inside or outside the collective) that consciouslly can cause damage to the collective autonomy. - -Formal processes ----------------- - -Each formal processs is an instance of the following state diagram: - - .------------------->-----------------. - / .----------<--------------<-------. \ - | ' \ \ - | | .------>-----. \ \ - | | | \ \ \ - Proposal -----> Discussion ->-. \ \ \ - | ^ | \ \ \ \ - | | | \ \ \ \ - | `----<-----' | \ \ \ - | | | \ \ - `------>----- Decision --<--' | \ \ - | | | \ \ - | | | | | - Responsibility --<---' '------> Archiving --->---' ; - Assignment --------->---------' ^ \ / - ^ | ___________/ `---<-----' - | \ .' - | `--> Achievement ->--. - | | | \ - | | | / - `----<-----' `-----<---' - -* Proposal: step where an idea of a formal process is presented to the collective. The idea ' or description ' can come for the Archive, from a previous Discussion, from an informal process that needs to be formalized or from a person or group from inside or outside the collective. General recomendation is to give a good explanation of the idea containing: deadline sugestion, process life cycle, responsibility assignment criteria and deadline and recomendations for emergencies (when appliable). - -* Discussion: - * It's not a mandatory step, but has importance anyway. - * Changes to proposals make the formal process go back to the Proposal state. Proposals that do not follow to the Decision step or do not get changes until it's deadline should be archived. - * Changed proposals that come from outside the collective or that have external groups or persons participation should be sent back also to the external group/person, despite these persons/groups do not participate in the internal discussion at the collective. If these external people/groups agree with the changed proposal, then the formal process proceeds with the discussion using the changed proposal. If that doesn't happen, i.e, these external people/groups don't agree with the changed proposal, then the formal process is archived (except if the external parties provide another changed proposal or more arguments to the discussion). - -* Decision: - * Through consensus and the active participation depends in following the information required by the proposal. - * If there's no consensus about the decision of a proposal it's automatically blocked with the possibility to extend it's deadline. - * Silence regarding a proposal is considered as an agreement. - * Deadline: general recomendation is to set deadlines relative to the average time needed by active people in the collective to take into account, discuss, make changes and ask for eventual postponing. Processes are elegible to postponing or advance it's deadline with an explicitly request from someone from the collective. If there's no such request, the initial deadline is assumed. - * Approvals from proposals coming from outside the collective or that have external people/groups involved are communicated about the approval just after the responsibility assignment. - -* Responsibility assignment - * Concerns the minimization of points of failure. - * Responsibilization is a volunteer action but requires the submission of a commitment/responsibilization term affirming that the person: - * Has knowledge about the procedure in question. - * Is gonna achieve it under the estimated deadline and is gonna keep the collective informed about the task. - * Will inform the collective in a reasonable timeframe if cannot continue to be involved with the process so the collective can keep the process going, assign new responsibilities or finnish it and send to the archive. - * Non-accomplishment with a process compromises the ability of someone to be responsible for other tasks. - * Formal processes that are approved but, after the responsibility assignment deadline, have unsufficient responsibilization assigned, should be sent to the archive. Proceesses in the archive were previously approved cannot be sent back directly to the responsibilty assigment and should instead go to the proposal step. - * In case of proposals coming from outside the collective or that have external people/groups involved, these people/groups should be informed of the approval just after the responsibility assignment, i.e, at the end of this step. - -* Achievement - * Just formal processes with sufficient responsibility assignment can go to the achievement step. Processes that were already achived goes to the archive. - * Formal processes that were not achieved in the deadline should come back to the Responsibility assignment step. In a similar way, processes whose assigned people cannot doing it should come back to the Responsibility assignment step if the number of assigned people is smaller than the required. diff --git a/english/provider.md b/english/provider.md new file mode 100644 index 0000000..b190458 --- /dev/null +++ b/english/provider.md @@ -0,0 +1,3 @@ +[[!meta title="Internet Services Provider"]] + +[[!map pages="page(english/provider*)" show="title"]] diff --git a/english/provider.mdwn b/english/provider.mdwn deleted file mode 100644 index b190458..0000000 --- a/english/provider.mdwn +++ /dev/null @@ -1,3 +0,0 @@ -[[!meta title="Internet Services Provider"]] - -[[!map pages="page(english/provider*)" show="title"]] diff --git a/english/provider/hosting.md b/english/provider/hosting.md new file mode 100644 index 0000000..b655236 --- /dev/null +++ b/english/provider/hosting.md @@ -0,0 +1,3 @@ +[[!meta title="Hosting"]] + +[[!map pages="page(hosting*)" show="title"]] diff --git a/english/provider/hosting.mdwn b/english/provider/hosting.mdwn deleted file mode 100644 index b655236..0000000 --- a/english/provider/hosting.mdwn +++ /dev/null @@ -1,3 +0,0 @@ -[[!meta title="Hosting"]] - -[[!map pages="page(hosting*)" show="title"]] diff --git a/english/provider/hosting/letter.md b/english/provider/hosting/letter.md new file mode 100644 index 0000000..6198a0f --- /dev/null +++ b/english/provider/hosting/letter.md @@ -0,0 +1,59 @@ +[[!meta title="Hosting Letter"]] + + $collective Hosting Letter + -------------------------- + + $collective is part of an intersection of various groups that discuss politics and + technology in different ways. We work with internet servers turned to various + cooperative goals. Then, our ideia is to colaborate with groups/projects that + are part of mutual and multiple aid and support. + + $collective is an autonomous project kept by a collective of volunteers. One of our + main goals is the collective creation of public spaces, common areas with projects and + groups that intend to enforce and straighten coexistence. + + Our intention is not just offer a "hosting service" and then we're not available + for groups that just want such thing. We want that groups we host colaborate with + the construction of a neighborhood, a rhizome, meaning that technology doesn't have to be + a barrier, but exactly the opposite. As technology is also a social construction, + its purposes, its configurations and the processes it interferes with can't + impose themselves independently of the choices made by the social groups where it's used. + + The internet is not only an environment of cooperation, but also of apropriation and + exploitation of common goods. We understand that it just turns essentially into a + public space when people can control their production and access means, things that + don't happen on corporate and governmental spaces. Because of this we try to + create public spaces, non-corporative and non-governmental and we hope that + groups we host colaborate to the construction of such spaces. + + During the construction of these kind of spaces, we make discussions where we try to + discover themes such as culture, society, technology, activism, social change + and many others. Such a research, when possible, is shared pubicly. + + We research the political implications of technology and develop systems and + instruments using different political values. We also keep a political dialogue + in the logics of theory/practice. + + So, one of our proposals is to collectivelly establish a network of mutual + support among groups and individuals interested in sharing the same physical + structure to share their knowledges, activities and researches. + + We attempt then to break the relation between service provider/clients, + because we're not service providers and the groups/individuals we host are not + our clients. We both make part of the same collaboration network where diverse + interests converge towards mutual empowerment. And who knows if such way of + organizing things won't spread to other parts of society. + + Thinking about knowledge distribution and with an incentive to new groups + interested in keeping their own server infrastructure, we try to share the most of + our organization scheme. + + And remember: for us, $collective is not just a hosting system or a service provider. + + Interesting links: + + - Researches available: http://wiki.$domain + - Configurations and operational procedures: http://padrao.$domain + + In solidarity, + $collective Group diff --git a/english/provider/hosting/letter.mdwn b/english/provider/hosting/letter.mdwn deleted file mode 100644 index 6198a0f..0000000 --- a/english/provider/hosting/letter.mdwn +++ /dev/null @@ -1,59 +0,0 @@ -[[!meta title="Hosting Letter"]] - - $collective Hosting Letter - -------------------------- - - $collective is part of an intersection of various groups that discuss politics and - technology in different ways. We work with internet servers turned to various - cooperative goals. Then, our ideia is to colaborate with groups/projects that - are part of mutual and multiple aid and support. - - $collective is an autonomous project kept by a collective of volunteers. One of our - main goals is the collective creation of public spaces, common areas with projects and - groups that intend to enforce and straighten coexistence. - - Our intention is not just offer a "hosting service" and then we're not available - for groups that just want such thing. We want that groups we host colaborate with - the construction of a neighborhood, a rhizome, meaning that technology doesn't have to be - a barrier, but exactly the opposite. As technology is also a social construction, - its purposes, its configurations and the processes it interferes with can't - impose themselves independently of the choices made by the social groups where it's used. - - The internet is not only an environment of cooperation, but also of apropriation and - exploitation of common goods. We understand that it just turns essentially into a - public space when people can control their production and access means, things that - don't happen on corporate and governmental spaces. Because of this we try to - create public spaces, non-corporative and non-governmental and we hope that - groups we host colaborate to the construction of such spaces. - - During the construction of these kind of spaces, we make discussions where we try to - discover themes such as culture, society, technology, activism, social change - and many others. Such a research, when possible, is shared pubicly. - - We research the political implications of technology and develop systems and - instruments using different political values. We also keep a political dialogue - in the logics of theory/practice. - - So, one of our proposals is to collectivelly establish a network of mutual - support among groups and individuals interested in sharing the same physical - structure to share their knowledges, activities and researches. - - We attempt then to break the relation between service provider/clients, - because we're not service providers and the groups/individuals we host are not - our clients. We both make part of the same collaboration network where diverse - interests converge towards mutual empowerment. And who knows if such way of - organizing things won't spread to other parts of society. - - Thinking about knowledge distribution and with an incentive to new groups - interested in keeping their own server infrastructure, we try to share the most of - our organization scheme. - - And remember: for us, $collective is not just a hosting system or a service provider. - - Interesting links: - - - Researches available: http://wiki.$domain - - Configurations and operational procedures: http://padrao.$domain - - In solidarity, - $collective Group diff --git a/english/provider/hosting/policy.md b/english/provider/hosting/policy.md new file mode 100644 index 0000000..c8726b7 --- /dev/null +++ b/english/provider/hosting/policy.md @@ -0,0 +1,45 @@ +[[!meta title="Hosting Policy"]] + + $collective Group Hosting Policy + -------------------------------- + + 1. The Collective reserves to istelf the power to host or discontinue the + hosting of any group or individual according to the ethical, political and + practical principles of the Collective. + + 2. In the case of hosting discontinuation for a given group, the Collective + commits itself to inform the hosted part with sufficient time and to make + available the hosted data. + + 3. Groups and individuals are just hosted by the Collective if they want to + have a mutual relation of resources and activity sharing. + + 4. Once the hosting partnership is created, the Collective must be informed of + actions and ways the hosted part is taking if those affects the Collective. By + the other hand, the Collective commits to inform the hosted part of anything + that can affect it. + + 5. The terms of partnership must be clear in the sense of the commitment + between both sides on support, maintenance and development of the host and + sites. + + 6. The hosted part is responsible for the hosted content and the Collective + cannot suffer legal consequences of improper or illegal content. Anyway the + Collective will make everything possible to protect the identity and privacy of + the hosted part. + + 7. The relations should be established as transparently as possible, avoiding + hidden or manipulated information by both parts. + + 8. The relations have the purpose of solidarity on knowledge, complementarity + on actions and exchange among groups, being vital to achieve ways of mutual + teaching-learning and develop policies that unite groups towards social and + political changes. + + 9. The Collective commits itself to inform at least in general ways its + security and privacy policies on the hosting platforms. + + 10. Hosting of social movements with sensitive content are kept, when possible, + hosted on platforms abroad. + + 11. The hosting consists in cooperation and not in service providing. diff --git a/english/provider/hosting/policy.mdwn b/english/provider/hosting/policy.mdwn deleted file mode 100644 index c8726b7..0000000 --- a/english/provider/hosting/policy.mdwn +++ /dev/null @@ -1,45 +0,0 @@ -[[!meta title="Hosting Policy"]] - - $collective Group Hosting Policy - -------------------------------- - - 1. The Collective reserves to istelf the power to host or discontinue the - hosting of any group or individual according to the ethical, political and - practical principles of the Collective. - - 2. In the case of hosting discontinuation for a given group, the Collective - commits itself to inform the hosted part with sufficient time and to make - available the hosted data. - - 3. Groups and individuals are just hosted by the Collective if they want to - have a mutual relation of resources and activity sharing. - - 4. Once the hosting partnership is created, the Collective must be informed of - actions and ways the hosted part is taking if those affects the Collective. By - the other hand, the Collective commits to inform the hosted part of anything - that can affect it. - - 5. The terms of partnership must be clear in the sense of the commitment - between both sides on support, maintenance and development of the host and - sites. - - 6. The hosted part is responsible for the hosted content and the Collective - cannot suffer legal consequences of improper or illegal content. Anyway the - Collective will make everything possible to protect the identity and privacy of - the hosted part. - - 7. The relations should be established as transparently as possible, avoiding - hidden or manipulated information by both parts. - - 8. The relations have the purpose of solidarity on knowledge, complementarity - on actions and exchange among groups, being vital to achieve ways of mutual - teaching-learning and develop policies that unite groups towards social and - political changes. - - 9. The Collective commits itself to inform at least in general ways its - security and privacy policies on the hosting platforms. - - 10. Hosting of social movements with sensitive content are kept, when possible, - hosted on platforms abroad. - - 11. The hosting consists in cooperation and not in service providing. diff --git a/english/provider/hosting/refusal.md b/english/provider/hosting/refusal.md new file mode 100644 index 0000000..a1801ff --- /dev/null +++ b/english/provider/hosting/refusal.md @@ -0,0 +1,22 @@ +[[!meta title="Refusal hosting letter"]] + + Hi $requisitante, + + Unfortunatelly we can't host the project you requested because: + + - We think it doesn't match the etical principles we adopt[1]. + + - And/or we consider it matches the kind of projects we have a critical + position with[2]. + + We believe that there's not just one way to fight. We also don't believe that + our etical principles and our criticisms represent the "right" viewpoint. + Our viewpoint just reflect the conclusions we got after a lot of discussions. + We try just to be coherent with what we believe and that's the reason why we + can't accept your request. + + We don't want for this statement to mean that we want to give no value for + the thing your project do or about what do you believe. + + [1] See http://encontro.fluxo.info/Principal/ConjuntoDePrincipiosEticos + [2] See http://wiki.$dominio diff --git a/english/provider/hosting/refusal.mdwn b/english/provider/hosting/refusal.mdwn deleted file mode 100644 index a1801ff..0000000 --- a/english/provider/hosting/refusal.mdwn +++ /dev/null @@ -1,22 +0,0 @@ -[[!meta title="Refusal hosting letter"]] - - Hi $requisitante, - - Unfortunatelly we can't host the project you requested because: - - - We think it doesn't match the etical principles we adopt[1]. - - - And/or we consider it matches the kind of projects we have a critical - position with[2]. - - We believe that there's not just one way to fight. We also don't believe that - our etical principles and our criticisms represent the "right" viewpoint. - Our viewpoint just reflect the conclusions we got after a lot of discussions. - We try just to be coherent with what we believe and that's the reason why we - can't accept your request. - - We don't want for this statement to mean that we want to give no value for - the thing your project do or about what do you believe. - - [1] See http://encontro.fluxo.info/Principal/ConjuntoDePrincipiosEticos - [2] See http://wiki.$dominio diff --git a/english/provider/hosting/terms.md b/english/provider/hosting/terms.md new file mode 100644 index 0000000..a38258f --- /dev/null +++ b/english/provider/hosting/terms.md @@ -0,0 +1,92 @@ +[[!meta title="Hosting Terms"]] + + Hi :) + + Agreement on Hosting + -------------------- + + We discussed and we agree to offer hosting as you requested. Now, in order for we to + effectivelly maintain this hosting, we need to: + + 1. State what is our commitment in relation to this hosting. + 2. That you and/or your group agree with the present term of agreement and + with our Hosting Policy. + + These are mutual commitment agreements, where we explain what is our commitment + with the hosting and that the hosted part needs to agree so we can keep such + relation. + + In case you agree with the terms of this letter and accept our Hosting Policy, + just reply saying so and the hosting will start as soon as possible. :) + + Our commitment + -------------- + + We commit ourselves to keep the hosting working. The hosting maintenance + happens through volunteer and responsible work. + + The used infra-structure is stable, but subject to eventual power and network + outages or even more sensitive problems. + + Then, sometimes hosting can go offline. We will always be allert and we care + for security and integrity of the hosted data. But, for a lot of reasons, we + cannot garantee the total availability or even the eternity of such data. + + We commit ourselves as much as possible to keep security copies of the data we + host. But we ask for you to also arrange, as much as possible, backup copies of + your data. + + Our group is composed by people that do a lot of tasks. The most important and + sensitive tasks, such as hosting, are dependent to other taks and each one is + associated to a workgroup of responsible persons. + + It may happen that someone leaves a workgroup and eventually some tasks will lack + commited people to get them accomplished. It's on this sense that we garantee + hosting: according to the available workforce at our group. It's possible that, + in the future, something happens and we stop hosting in a given platform. + But, if we do so, we garantee that it won't happen from night to day and we'll + give enough time for you and your project to migrate the data somewhere else. + + We also have the commitment to inform, when you ask, our procedures according to + our accounting policy. Such procedures vary from privacy and security policies + to choices of platforms and our group's situation. + + As our procedures can change with time, we recommend you to ask for procedures + descriptions when you feel necessary. + + We have our limitations but we'll keep things working as much as we can. :) + + Your commitment + --------------- + + We hope that you and/or your project use the offered resource with wisdom. + Don't ask for websites and tools if you will abandon them. If you install your own + programs, please have the responsibility to keep it up-to-date as security holes at + your place can compromise other hosted projects. + + Please don't forget that the maintenance of multiple projects needs a lot of work + and is difficult to keep secure. Then we ask for everyone's collaboration. We would be + very pleased if you informed us about your plans to install tools in your space. :) + + Sharing interfaces + ------------------ + + A possible space for interactions among projects is the Neighborhood Mailing + List[1] (subscription just for sufficiently secure mail accounts, get in touch for + more information). When we host groups and individuals, we hope that they will also + be responsible in what comes to taking care of such spaces. + + Our neighborhood is also a place for articulations, where all groups and + individuals sharing the same infra-structure can communicate between + themselves. + + If the subjects we research are inspiring for you too, we invite you to + participate in such discussions. To avoid centralization, we propose you to + collectivelly discuss with your group and publish the conclusions you + get. For us it is fundamental to try to build a metodology that makes possible the + dissemination of such discussions. + + [1] $neighborhood_mailing_list_address + + In solidarity, + $grupo Collective diff --git a/english/provider/hosting/terms.mdwn b/english/provider/hosting/terms.mdwn deleted file mode 100644 index a38258f..0000000 --- a/english/provider/hosting/terms.mdwn +++ /dev/null @@ -1,92 +0,0 @@ -[[!meta title="Hosting Terms"]] - - Hi :) - - Agreement on Hosting - -------------------- - - We discussed and we agree to offer hosting as you requested. Now, in order for we to - effectivelly maintain this hosting, we need to: - - 1. State what is our commitment in relation to this hosting. - 2. That you and/or your group agree with the present term of agreement and - with our Hosting Policy. - - These are mutual commitment agreements, where we explain what is our commitment - with the hosting and that the hosted part needs to agree so we can keep such - relation. - - In case you agree with the terms of this letter and accept our Hosting Policy, - just reply saying so and the hosting will start as soon as possible. :) - - Our commitment - -------------- - - We commit ourselves to keep the hosting working. The hosting maintenance - happens through volunteer and responsible work. - - The used infra-structure is stable, but subject to eventual power and network - outages or even more sensitive problems. - - Then, sometimes hosting can go offline. We will always be allert and we care - for security and integrity of the hosted data. But, for a lot of reasons, we - cannot garantee the total availability or even the eternity of such data. - - We commit ourselves as much as possible to keep security copies of the data we - host. But we ask for you to also arrange, as much as possible, backup copies of - your data. - - Our group is composed by people that do a lot of tasks. The most important and - sensitive tasks, such as hosting, are dependent to other taks and each one is - associated to a workgroup of responsible persons. - - It may happen that someone leaves a workgroup and eventually some tasks will lack - commited people to get them accomplished. It's on this sense that we garantee - hosting: according to the available workforce at our group. It's possible that, - in the future, something happens and we stop hosting in a given platform. - But, if we do so, we garantee that it won't happen from night to day and we'll - give enough time for you and your project to migrate the data somewhere else. - - We also have the commitment to inform, when you ask, our procedures according to - our accounting policy. Such procedures vary from privacy and security policies - to choices of platforms and our group's situation. - - As our procedures can change with time, we recommend you to ask for procedures - descriptions when you feel necessary. - - We have our limitations but we'll keep things working as much as we can. :) - - Your commitment - --------------- - - We hope that you and/or your project use the offered resource with wisdom. - Don't ask for websites and tools if you will abandon them. If you install your own - programs, please have the responsibility to keep it up-to-date as security holes at - your place can compromise other hosted projects. - - Please don't forget that the maintenance of multiple projects needs a lot of work - and is difficult to keep secure. Then we ask for everyone's collaboration. We would be - very pleased if you informed us about your plans to install tools in your space. :) - - Sharing interfaces - ------------------ - - A possible space for interactions among projects is the Neighborhood Mailing - List[1] (subscription just for sufficiently secure mail accounts, get in touch for - more information). When we host groups and individuals, we hope that they will also - be responsible in what comes to taking care of such spaces. - - Our neighborhood is also a place for articulations, where all groups and - individuals sharing the same infra-structure can communicate between - themselves. - - If the subjects we research are inspiring for you too, we invite you to - participate in such discussions. To avoid centralization, we propose you to - collectivelly discuss with your group and publish the conclusions you - get. For us it is fundamental to try to build a metodology that makes possible the - dissemination of such discussions. - - [1] $neighborhood_mailing_list_address - - In solidarity, - $grupo Collective diff --git a/etica.md b/etica.md new file mode 100644 index 0000000..6717c6a --- /dev/null +++ b/etica.md @@ -0,0 +1,3 @@ +[[!meta title="Ética"]] + +[[!map pages="page(etica*)" show="title"]] diff --git a/etica.mdwn b/etica.mdwn deleted file mode 100644 index 6717c6a..0000000 --- a/etica.mdwn +++ /dev/null @@ -1,3 +0,0 @@ -[[!meta title="Ética"]] - -[[!map pages="page(etica*)" show="title"]] diff --git a/etica/coletiva.md b/etica/coletiva.md new file mode 100644 index 0000000..525bd16 --- /dev/null +++ b/etica/coletiva.md @@ -0,0 +1,48 @@ +[[!meta title="Conjunto de Princípios Éticos"]] + +Baseado nos [princípios das mídias e grupos livres](https://encontro.fluxo.info/Principal/ConjuntoDePrincipiosEticos). + +0. Sobre a mobilidade dos princípios: Todos os princípios podem ser a qualquer momento modificados ou abandonados desde que não sejam mais a expressão imanente das relações que se constituem através das ações coletivas. + +1. Sobre a autonomia: grupos e mídias livres renunciam e se recusam a recorrer a qualquer entidade política que não a si próprias para constituir sua legalidade e sua normatividade, por acreditar que a sua única fonte legítima é sua emergencia a partir dos laços de confiança e solidarieade entre participantes e de cada participante com os coletivos por eles constituídos. + +2. Sobre a apropriação pública: As mídias e os grupos livres defendem e promovem a apropriação pública dos meios de produção (rejeita a sua apropriação privada) e, em específico dos meios de produção de bens simbólicos e culturais e aos produtos do trabalho intelectual e imaterial. + +3. Sobre o licenciamento: As mídias e os grupos livres usam licenciamento livre, apoiam explicitamente os novos direitos autorais e consideram especialmente inaceitável a apropriação privada do trabalho intelectual / imaterial. aqui, bem que podia aparecer alguma vinculação das licenças com propostas de escambo, economia solidária, moeadas locais, permacultura, comércio justo... tipo: inventar uma licença que permitisse a circulação em sistemas de mercado não-capitalistas. Talvez, exigindo para isso o consentimento (tácito?) dos envolvidos + +4. Sobre o acesso público: As mídias e os grupos livres criam plataformas de comunicação mediática e espaços simbólicos de acesso público em que se rejeita absolutamente a monopolização vertical da produção mediática; embora estabeleçam princípios éticos e políticos para o acesso aos suportes, não há controle sobre a produção de "conteúdo", permitindo que uma pluralidade de organizações possam se utilizar dos mesmos canais de comunicação. + +5. Sobre a diversidade: As mídias e os grupos livres visam aumentar a diversidade dos pontos de vista e estimular o debate argumentativo, recusa apoiar práticas da política institucional e veda o proselitismo religioso, político-institucional e/ou propaganda comercial. + +6. Sobre a gestão: As mídias e os grupos livres usam e desenvolvem sistematicamente mecanismos de gestão anti-hierárquicos e baseados na geração de consensos a partir da argumentação pública; ou seja, rejeitam (ou evitam ao máximo), como práticas de organização: a representação política e a votação plebiscitária. A divisão funcional é adotada com ponderação, sob avaliação coletiva e de maneira ocasional. + +7. Sobre as invenções: As mídias e os grupos livres propiciam e estimulam a invenção estética, tecnológica e política, na medida em que tomam a organização social, a cultura e o corpo como realidades dignas de serem transformados e aperfeiçoados. Nesse sentido, as mídias e os grupos livres defendem a liberdade de conhecimento e de acesso a ele; para contribuir com a concretização destas liberdades, as mídias e os grupos livres incentivam o uso de softwares livres e a publicação em formatos livres (.ogg para áudio, .png para imagens, etc.) e em, caso isso não seja possível, em formatos proprietários mas que sejam públicos (.rtf e .pdf para textos, .mpg para vídeos, etc.). As mídias e os grupos livres não incentivam o uso de formatos proprietários (.doc para texto, .ppt para apresentação de slides, etc.). + +8. Sobre as pesquisas e as metodologias: As mídias e os grupos livres promovem a pesquisa, o desenvolvimento e pratica de metodologias para a apropriação dos recursos de comunicação pelos públicos, através do que buscam transformar em práticas cotidianas dos cidadãos a produção de comunicação mediática e o seu uso público político. + +9. Sobre a expansão e a organização em redes: A lógica de expansão das mídias e grupos livres segue a de formação dos rizomas (e não da árvores): formam novas organizações quando o contingente de participantes aumenta, adensam as interconexões (comunicação lateral) entre as organizações e evitam que indivíduos e grupos de influência se coloquem no lugar de intermediários políticos. + +10. Sobre doações: Se recebem dinheiro, o fazem apenas como doação, ou seja: qualquer apoiador deve saber que seus recursos não serão empregados senão para os fins estritos de criação de espaços comunicativos livres, sendo vedadas as práticas de mercantismo cultural, social ou político. Tais doações são aceitas apenas se anônimas (isto é, não publicizadas). Dinheiro governamental ou empresarial não é aceito. + +11. Sobre auto-sustentabilidade: As mídias e grupos livres estimulam a geraçãoo de mecanismos de autosustentabilidade (ou "autodependência") local e comunitária. Exemplos: venda de camisetas, comidas, rifas, organização de festas, mostra de videos, etc. Tratam-se de atividades criadas e organizadas para estimular a vivência em coletivo e a escapar das práticas capitalistas. É recomendável que, dentro dos grupos e entre eles, exista uma socialização dos recursos e que os individuos também adotem essa prática, compartilhando recursos pessoais com o coletivo, para criar ambientes de solidariedade comunitária, onde ninguém seja excluído por falta de recursos. + +12. Sobre a gestão financeira: Para garantir essas condições de financiamento, toda a gestão financeira das mídias e grupos livres é publica: tanto as informações contábeis quanto a participação nas decisões são acessíveis às pessoas concernidas nas ações desta organização. + +13. Sobre a privacidade: As mídias e os grupos livres defendem a inviolabilidade da intimidade e a privacidade do indivíduo, especialmente contra sua exploração capitalista, por meio de dispositivos de identificação de padrões comportamentais. No caso da implementação de sistemas emergentes de identificação de padrões de uso nas plataformas das mídias e grupos livres, todos os concernidos têm pleno acesso ao seu funcionamento e os podem alterar sempre que desejarem (através de processos de formação argumentativa de consensos, vide acima). + +14. Sobre a espetacularização: As mídias e os grupos livres não se utilizam da espetacularização ou maravilhização. Quer dizer, realmente estamos precisados de conceituar e expressar verbalmente o que estamos tomando sob "espetacularização" e "maravilhização": quase a totalidade dos grupos de hoje trabalham demais com a espetacularização: as ações que escolhem são as mais espetacularizadas possíveis (tanto é que não vemos os grupos trabalharem com a mesma intensidade em coisas de base ou em estrutura), eles tem uma preocupação imensa em mostrar o que estão fazendo, em trabalhar com mídia, etc. Isso deve ser uma herança da dita mídia tática e de mais um monte de coisa e acho que deveriam ser analisados, tem que ter uma crítica. Porque às vezes os logotipos parecem surgir antes mesmo das ações. + +15. Sobre uma sociedade livre: As mídias e os grupos livres comprometem-se com o projeto de construção de uma sociedade livre, igualitária e com respeito ao meio ambiente. + +16. Sobre a garantia de expressão: As mídias e os grupos livres trabalham no sentido de garantir um espaço para que qualquer pessoa, grupo (de afinidade política, de ação direta, de artivismo) e movimento social - que estejam em sintonia com esses objetivos - possam publicar sua própria versão dos fatos. + +17. Sobre a distinção entre produtor/a e consumidor/a: As mídias e os grupos livres trabalham no sentido de romper o papel de espectador(a) passivo/a e transformando a prática midiática ao romper com a mediação do/a jornalista profissional e com a interferência de editores/as no conteúdo das matérias. + +18. Sobre a transformação da sociedade: As mídias e os grupos livres favorecem conteúdos informacionais sobre transformação social ou que retratem as realidades dos/as oprimidos/as ou as lutas dos novos movimentos. +Sobre a união: As mídias e os grupos livres trabalham no sentido de unir esforços para uma real democratização da sociedade, primando sempre por privilegiar a perspectiva dos/as oprimidos/as. Em função disso, esperamos uma atitude construtiva e tolerante entre os/as participantes do sítio; afinal, queremos juntar forças, não lutar entre nós. + +19. Sobre a intolerância: As mídias e os grupos livres lutam contra o racismo, o sexismo e outros tipos de intolerância. + +20. Sobre a remuneração pelo trabalho: As mídias e os grupos livres funcionam exclusivamente a partir de trabalho voluntário. + +21. Sobre a capitalização sobre trabalho: As mídias e os grupos livres não devem permitir que seus voluntários/as capitalizem em cima do seu trabalho voluntário, seja adicionando tal trabalho em seu currículo ou seja por obter benesses através do uso do nome do grupo ou da mídia livre. diff --git a/etica/coletiva.mdwn b/etica/coletiva.mdwn deleted file mode 100644 index 525bd16..0000000 --- a/etica/coletiva.mdwn +++ /dev/null @@ -1,48 +0,0 @@ -[[!meta title="Conjunto de Princípios Éticos"]] - -Baseado nos [princípios das mídias e grupos livres](https://encontro.fluxo.info/Principal/ConjuntoDePrincipiosEticos). - -0. Sobre a mobilidade dos princípios: Todos os princípios podem ser a qualquer momento modificados ou abandonados desde que não sejam mais a expressão imanente das relações que se constituem através das ações coletivas. - -1. Sobre a autonomia: grupos e mídias livres renunciam e se recusam a recorrer a qualquer entidade política que não a si próprias para constituir sua legalidade e sua normatividade, por acreditar que a sua única fonte legítima é sua emergencia a partir dos laços de confiança e solidarieade entre participantes e de cada participante com os coletivos por eles constituídos. - -2. Sobre a apropriação pública: As mídias e os grupos livres defendem e promovem a apropriação pública dos meios de produção (rejeita a sua apropriação privada) e, em específico dos meios de produção de bens simbólicos e culturais e aos produtos do trabalho intelectual e imaterial. - -3. Sobre o licenciamento: As mídias e os grupos livres usam licenciamento livre, apoiam explicitamente os novos direitos autorais e consideram especialmente inaceitável a apropriação privada do trabalho intelectual / imaterial. aqui, bem que podia aparecer alguma vinculação das licenças com propostas de escambo, economia solidária, moeadas locais, permacultura, comércio justo... tipo: inventar uma licença que permitisse a circulação em sistemas de mercado não-capitalistas. Talvez, exigindo para isso o consentimento (tácito?) dos envolvidos - -4. Sobre o acesso público: As mídias e os grupos livres criam plataformas de comunicação mediática e espaços simbólicos de acesso público em que se rejeita absolutamente a monopolização vertical da produção mediática; embora estabeleçam princípios éticos e políticos para o acesso aos suportes, não há controle sobre a produção de "conteúdo", permitindo que uma pluralidade de organizações possam se utilizar dos mesmos canais de comunicação. - -5. Sobre a diversidade: As mídias e os grupos livres visam aumentar a diversidade dos pontos de vista e estimular o debate argumentativo, recusa apoiar práticas da política institucional e veda o proselitismo religioso, político-institucional e/ou propaganda comercial. - -6. Sobre a gestão: As mídias e os grupos livres usam e desenvolvem sistematicamente mecanismos de gestão anti-hierárquicos e baseados na geração de consensos a partir da argumentação pública; ou seja, rejeitam (ou evitam ao máximo), como práticas de organização: a representação política e a votação plebiscitária. A divisão funcional é adotada com ponderação, sob avaliação coletiva e de maneira ocasional. - -7. Sobre as invenções: As mídias e os grupos livres propiciam e estimulam a invenção estética, tecnológica e política, na medida em que tomam a organização social, a cultura e o corpo como realidades dignas de serem transformados e aperfeiçoados. Nesse sentido, as mídias e os grupos livres defendem a liberdade de conhecimento e de acesso a ele; para contribuir com a concretização destas liberdades, as mídias e os grupos livres incentivam o uso de softwares livres e a publicação em formatos livres (.ogg para áudio, .png para imagens, etc.) e em, caso isso não seja possível, em formatos proprietários mas que sejam públicos (.rtf e .pdf para textos, .mpg para vídeos, etc.). As mídias e os grupos livres não incentivam o uso de formatos proprietários (.doc para texto, .ppt para apresentação de slides, etc.). - -8. Sobre as pesquisas e as metodologias: As mídias e os grupos livres promovem a pesquisa, o desenvolvimento e pratica de metodologias para a apropriação dos recursos de comunicação pelos públicos, através do que buscam transformar em práticas cotidianas dos cidadãos a produção de comunicação mediática e o seu uso público político. - -9. Sobre a expansão e a organização em redes: A lógica de expansão das mídias e grupos livres segue a de formação dos rizomas (e não da árvores): formam novas organizações quando o contingente de participantes aumenta, adensam as interconexões (comunicação lateral) entre as organizações e evitam que indivíduos e grupos de influência se coloquem no lugar de intermediários políticos. - -10. Sobre doações: Se recebem dinheiro, o fazem apenas como doação, ou seja: qualquer apoiador deve saber que seus recursos não serão empregados senão para os fins estritos de criação de espaços comunicativos livres, sendo vedadas as práticas de mercantismo cultural, social ou político. Tais doações são aceitas apenas se anônimas (isto é, não publicizadas). Dinheiro governamental ou empresarial não é aceito. - -11. Sobre auto-sustentabilidade: As mídias e grupos livres estimulam a geraçãoo de mecanismos de autosustentabilidade (ou "autodependência") local e comunitária. Exemplos: venda de camisetas, comidas, rifas, organização de festas, mostra de videos, etc. Tratam-se de atividades criadas e organizadas para estimular a vivência em coletivo e a escapar das práticas capitalistas. É recomendável que, dentro dos grupos e entre eles, exista uma socialização dos recursos e que os individuos também adotem essa prática, compartilhando recursos pessoais com o coletivo, para criar ambientes de solidariedade comunitária, onde ninguém seja excluído por falta de recursos. - -12. Sobre a gestão financeira: Para garantir essas condições de financiamento, toda a gestão financeira das mídias e grupos livres é publica: tanto as informações contábeis quanto a participação nas decisões são acessíveis às pessoas concernidas nas ações desta organização. - -13. Sobre a privacidade: As mídias e os grupos livres defendem a inviolabilidade da intimidade e a privacidade do indivíduo, especialmente contra sua exploração capitalista, por meio de dispositivos de identificação de padrões comportamentais. No caso da implementação de sistemas emergentes de identificação de padrões de uso nas plataformas das mídias e grupos livres, todos os concernidos têm pleno acesso ao seu funcionamento e os podem alterar sempre que desejarem (através de processos de formação argumentativa de consensos, vide acima). - -14. Sobre a espetacularização: As mídias e os grupos livres não se utilizam da espetacularização ou maravilhização. Quer dizer, realmente estamos precisados de conceituar e expressar verbalmente o que estamos tomando sob "espetacularização" e "maravilhização": quase a totalidade dos grupos de hoje trabalham demais com a espetacularização: as ações que escolhem são as mais espetacularizadas possíveis (tanto é que não vemos os grupos trabalharem com a mesma intensidade em coisas de base ou em estrutura), eles tem uma preocupação imensa em mostrar o que estão fazendo, em trabalhar com mídia, etc. Isso deve ser uma herança da dita mídia tática e de mais um monte de coisa e acho que deveriam ser analisados, tem que ter uma crítica. Porque às vezes os logotipos parecem surgir antes mesmo das ações. - -15. Sobre uma sociedade livre: As mídias e os grupos livres comprometem-se com o projeto de construção de uma sociedade livre, igualitária e com respeito ao meio ambiente. - -16. Sobre a garantia de expressão: As mídias e os grupos livres trabalham no sentido de garantir um espaço para que qualquer pessoa, grupo (de afinidade política, de ação direta, de artivismo) e movimento social - que estejam em sintonia com esses objetivos - possam publicar sua própria versão dos fatos. - -17. Sobre a distinção entre produtor/a e consumidor/a: As mídias e os grupos livres trabalham no sentido de romper o papel de espectador(a) passivo/a e transformando a prática midiática ao romper com a mediação do/a jornalista profissional e com a interferência de editores/as no conteúdo das matérias. - -18. Sobre a transformação da sociedade: As mídias e os grupos livres favorecem conteúdos informacionais sobre transformação social ou que retratem as realidades dos/as oprimidos/as ou as lutas dos novos movimentos. -Sobre a união: As mídias e os grupos livres trabalham no sentido de unir esforços para uma real democratização da sociedade, primando sempre por privilegiar a perspectiva dos/as oprimidos/as. Em função disso, esperamos uma atitude construtiva e tolerante entre os/as participantes do sítio; afinal, queremos juntar forças, não lutar entre nós. - -19. Sobre a intolerância: As mídias e os grupos livres lutam contra o racismo, o sexismo e outros tipos de intolerância. - -20. Sobre a remuneração pelo trabalho: As mídias e os grupos livres funcionam exclusivamente a partir de trabalho voluntário. - -21. Sobre a capitalização sobre trabalho: As mídias e os grupos livres não devem permitir que seus voluntários/as capitalizem em cima do seu trabalho voluntário, seja adicionando tal trabalho em seu currículo ou seja por obter benesses através do uso do nome do grupo ou da mídia livre. diff --git a/etica/pessoal.md b/etica/pessoal.md new file mode 100644 index 0000000..2e3971c --- /dev/null +++ b/etica/pessoal.md @@ -0,0 +1,110 @@ +[[!meta title="Ética Pessoal"]] + +Motivação +--------- + +Código é lei? Código pode também ser ética. Se existem [protocolos](https://protocolos.fluxo.info) e [códigos de conduta](https://www.debian.org/vote/2014/vote_002) atuando no nível de grupos, é importante também haver procedimentos de auxílio para relações em nível individual. + +Pressupostos +------------ + +* Como cantou Daminhão Experiência, "O mundo foi bem feito / todo mundo tem defeito". +* Saber quando pisar dentro e fora do quadrado. +* Noções básicas de postura social. + +Cuidados +-------- + +Não é a intenção deste breve guia: + +* Se transformar numa rocha inalterável e inflexível de como as relações humanas devem ser. +* Criar um protocolo que dificulte relações e deixe as pessoas apartadas. + +Este guia é mais uma referências de aspectos a serem pensados em relações com pessoas. + +Objetivos +--------- + +Grosso modo: + +* Calma. +* Alegria. +* Agilidade. +* Sangue-bonismo. +* Companheirismo. +* Solidariedade, fraternidade, alteridade, autruísmo. + +Pisando no quadrado +------------------- + +Este é um checklist de procedimentos e código de conduta. Você tem uma ideia de como se portar em cada um desses items? + +* Comunicação implícita e explícita: + * O que pode ser assumido de antemão. + * O que não pode ser assumido de antemão. +* Separação entre aspectos da vida: + * Profissional, político e pessoal. + * Amizades e afinidades. + * Público e privado. +* Lidando com conhecimento: + * Criando um canal e um encorajamento explícito para contatos, sugestões e críticas. + * Fomentando a formação e a inclusão de mais pessoas no ativismo técnico e na difusão do conhecimento. + * Tendo uma melhor comunicação com grupos e pessoas próximas. + * Definir melhor e de forma pública o funcionamento e a participação. +* Relacionamento: + * [Alteridade](http://www.revolucoes.org.br/v1/conferencia/alteridade). + * Generosidade. + * Alimentação. + * Liberdade de associação e de não-associação, tanto para propósitos gerais quanto específicos. + * Responsabilidade e zelo. + * Buscar facilitar as relações e situações, ao invés de dificultar a fluidez dos relacionamentos. + * Comportamentos evitados: trolling, bullying, spamming, etc. + * Gentileza gera gentileza. + * Proceder: humildade, respeito, responsa. + * Assiduidade, pontualidade e atrasos. + * Política de assinatura de chaves. + * Participação em debates e discussões. + * Favores e reciprocidade. + * Fidelidade (compromisso) e lealdade (espontâneo). + * Sobre a confiança (contextual e total) e a alteridade. + * Pronomes de tratamento e linguagem inclusiva. + * Discussão, facilitação, opiniões (e mudança de opiniões), respeito a rodadas e falas: + * Discussão de temas em geral. + * Discussão periódica da relação. + * Comunicação mediada (virtual): + * [Netiqueta](https://tools.ietf.org/html/rfc1855). + * Lei de [Postel](https://en.wikipedia.org/wiki/Jon_Postel): "Be liberal in what you accept, and conservative in what you send". + * Como lidar com ausência de resposta. + * Como a ausência de resposta é interpretada. + * Assuntos públicos, semi-públicos e privados: como lidar com mensagens privadas evitando concentração de informação e canais laterais que possam prejudicar organizações horizontais. + * Emoticons, cordialidade e polidez. + * Quando assinar comunicação, quando não assinar, modo anônimo. + * Comunicação ao vivo: + * Pronomes. + * Cumprimentos (aperto de mão, beijo, saudação). +* Sistematizando formas de lidar com situações diversas: + * [Defence mechanisms](https://en.wikipedia.org/wiki/Defence_mechanisms). + * Círculo Restaurativo. + * Comunicação não-violenta. + * Linguagem inclusiva. + * Situações críticas: como não reproduzir instituições burguesas (tribunal, prisão, manicômio) ou arcaicas (ostracismo, linchamento, etc)? + * Facilitação e resolução de conflitos. + * [Conflito e Consenso](https://docs.indymedia.org/Local/CmiBrasilConflitoConsenso). + * [Conflict resolution](https://simple.wikipedia.org/wiki/Conflict_resolution). + * Referências + * [General Resolution: code of conduct](https://www.debian.org/vote/2014/vote_002). + * [Código de conduta da SquatConf](https://github.com/squatconf/organisation/blob/master/code_of_conduct.md#squatconf-code-of-conduct). + * [Código de Conduta do Mediawiki](https://www.mediawiki.org/wiki/Code_of_Conduct). + * [Contributor Covenant: A Code of Conduct for Open Source Projects](http://contributor-covenant.org/). + * [Universal Declaration of Human Rights | United Nations](http://www.un.org/en/universal-declaration-human-rights/index.html). + +Exemplo +------- + +Subconjunto de baixa complexidade necessária: + +0. Saúde é o que interessa! + +1. Não importa o que aconteça, duas coisas precisam ser constantes na vida: estudar e se exercitar (circuito do aprendizado e da experiência). + +2. De resto, não leve nada a sério mas sempre se engaje! Que venha a farra, a alegria e a solidariedade/generosidade! diff --git a/etica/pessoal.mdwn b/etica/pessoal.mdwn deleted file mode 100644 index 2e3971c..0000000 --- a/etica/pessoal.mdwn +++ /dev/null @@ -1,110 +0,0 @@ -[[!meta title="Ética Pessoal"]] - -Motivação ---------- - -Código é lei? Código pode também ser ética. Se existem [protocolos](https://protocolos.fluxo.info) e [códigos de conduta](https://www.debian.org/vote/2014/vote_002) atuando no nível de grupos, é importante também haver procedimentos de auxílio para relações em nível individual. - -Pressupostos ------------- - -* Como cantou Daminhão Experiência, "O mundo foi bem feito / todo mundo tem defeito". -* Saber quando pisar dentro e fora do quadrado. -* Noções básicas de postura social. - -Cuidados --------- - -Não é a intenção deste breve guia: - -* Se transformar numa rocha inalterável e inflexível de como as relações humanas devem ser. -* Criar um protocolo que dificulte relações e deixe as pessoas apartadas. - -Este guia é mais uma referências de aspectos a serem pensados em relações com pessoas. - -Objetivos ---------- - -Grosso modo: - -* Calma. -* Alegria. -* Agilidade. -* Sangue-bonismo. -* Companheirismo. -* Solidariedade, fraternidade, alteridade, autruísmo. - -Pisando no quadrado -------------------- - -Este é um checklist de procedimentos e código de conduta. Você tem uma ideia de como se portar em cada um desses items? - -* Comunicação implícita e explícita: - * O que pode ser assumido de antemão. - * O que não pode ser assumido de antemão. -* Separação entre aspectos da vida: - * Profissional, político e pessoal. - * Amizades e afinidades. - * Público e privado. -* Lidando com conhecimento: - * Criando um canal e um encorajamento explícito para contatos, sugestões e críticas. - * Fomentando a formação e a inclusão de mais pessoas no ativismo técnico e na difusão do conhecimento. - * Tendo uma melhor comunicação com grupos e pessoas próximas. - * Definir melhor e de forma pública o funcionamento e a participação. -* Relacionamento: - * [Alteridade](http://www.revolucoes.org.br/v1/conferencia/alteridade). - * Generosidade. - * Alimentação. - * Liberdade de associação e de não-associação, tanto para propósitos gerais quanto específicos. - * Responsabilidade e zelo. - * Buscar facilitar as relações e situações, ao invés de dificultar a fluidez dos relacionamentos. - * Comportamentos evitados: trolling, bullying, spamming, etc. - * Gentileza gera gentileza. - * Proceder: humildade, respeito, responsa. - * Assiduidade, pontualidade e atrasos. - * Política de assinatura de chaves. - * Participação em debates e discussões. - * Favores e reciprocidade. - * Fidelidade (compromisso) e lealdade (espontâneo). - * Sobre a confiança (contextual e total) e a alteridade. - * Pronomes de tratamento e linguagem inclusiva. - * Discussão, facilitação, opiniões (e mudança de opiniões), respeito a rodadas e falas: - * Discussão de temas em geral. - * Discussão periódica da relação. - * Comunicação mediada (virtual): - * [Netiqueta](https://tools.ietf.org/html/rfc1855). - * Lei de [Postel](https://en.wikipedia.org/wiki/Jon_Postel): "Be liberal in what you accept, and conservative in what you send". - * Como lidar com ausência de resposta. - * Como a ausência de resposta é interpretada. - * Assuntos públicos, semi-públicos e privados: como lidar com mensagens privadas evitando concentração de informação e canais laterais que possam prejudicar organizações horizontais. - * Emoticons, cordialidade e polidez. - * Quando assinar comunicação, quando não assinar, modo anônimo. - * Comunicação ao vivo: - * Pronomes. - * Cumprimentos (aperto de mão, beijo, saudação). -* Sistematizando formas de lidar com situações diversas: - * [Defence mechanisms](https://en.wikipedia.org/wiki/Defence_mechanisms). - * Círculo Restaurativo. - * Comunicação não-violenta. - * Linguagem inclusiva. - * Situações críticas: como não reproduzir instituições burguesas (tribunal, prisão, manicômio) ou arcaicas (ostracismo, linchamento, etc)? - * Facilitação e resolução de conflitos. - * [Conflito e Consenso](https://docs.indymedia.org/Local/CmiBrasilConflitoConsenso). - * [Conflict resolution](https://simple.wikipedia.org/wiki/Conflict_resolution). - * Referências - * [General Resolution: code of conduct](https://www.debian.org/vote/2014/vote_002). - * [Código de conduta da SquatConf](https://github.com/squatconf/organisation/blob/master/code_of_conduct.md#squatconf-code-of-conduct). - * [Código de Conduta do Mediawiki](https://www.mediawiki.org/wiki/Code_of_Conduct). - * [Contributor Covenant: A Code of Conduct for Open Source Projects](http://contributor-covenant.org/). - * [Universal Declaration of Human Rights | United Nations](http://www.un.org/en/universal-declaration-human-rights/index.html). - -Exemplo -------- - -Subconjunto de baixa complexidade necessária: - -0. Saúde é o que interessa! - -1. Não importa o que aconteça, duas coisas precisam ser constantes na vida: estudar e se exercitar (circuito do aprendizado e da experiência). - -2. De resto, não leve nada a sério mas sempre se engaje! Que venha a farra, a alegria e a solidariedade/generosidade! diff --git a/ikiwiki/index.md b/ikiwiki/index.md new file mode 100644 index 0000000..2da2aef --- /dev/null +++ b/ikiwiki/index.md @@ -0,0 +1,3 @@ +[[!meta title="Hello World!"]] + +[[!inline pages="page(*) and !ikiwiki/* and !index and !sandbox and !templates* and !smileys and !shortcuts and !ikiwiki and !RecentChanges and !*/Discussion" archive="yes"]] diff --git a/ikiwiki/index.mdwn b/ikiwiki/index.mdwn deleted file mode 100644 index 2da2aef..0000000 --- a/ikiwiki/index.mdwn +++ /dev/null @@ -1,3 +0,0 @@ -[[!meta title="Hello World!"]] - -[[!inline pages="page(*) and !ikiwiki/* and !index and !sandbox and !templates* and !smileys and !shortcuts and !ikiwiki and !RecentChanges and !*/Discussion" archive="yes"]] diff --git a/ikiwiki/sitemap.md b/ikiwiki/sitemap.md new file mode 100644 index 0000000..6586976 --- /dev/null +++ b/ikiwiki/sitemap.md @@ -0,0 +1,3 @@ +[[!meta title="Sitemap"]] + +[[!map pages="page(*) and !ikiwiki/* and !index and !sandbox and !templates* and !smileys and !shortcuts and !ikiwiki and !RecentChanges and !*/Discussion" show="title"]] diff --git a/ikiwiki/sitemap.mdwn b/ikiwiki/sitemap.mdwn deleted file mode 100644 index 6586976..0000000 --- a/ikiwiki/sitemap.mdwn +++ /dev/null @@ -1,3 +0,0 @@ -[[!meta title="Sitemap"]] - -[[!map pages="page(*) and !ikiwiki/* and !index and !sandbox and !templates* and !smileys and !shortcuts and !ikiwiki and !RecentChanges and !*/Discussion" show="title"]] diff --git a/ikiwiki/timeline.md b/ikiwiki/timeline.md new file mode 100644 index 0000000..4a683f7 --- /dev/null +++ b/ikiwiki/timeline.md @@ -0,0 +1,3 @@ +[[!meta title="Timeline"]] + +[[!inline pages="page(*) and !ikiwiki/* and !index and !sandbox and !templates* and !smileys and !shortcuts and !ikiwiki and !RecentChanges and !*/Discussion" archive="yes"]] diff --git a/ikiwiki/timeline.mdwn b/ikiwiki/timeline.mdwn deleted file mode 100644 index 4a683f7..0000000 --- a/ikiwiki/timeline.mdwn +++ /dev/null @@ -1,3 +0,0 @@ -[[!meta title="Timeline"]] - -[[!inline pages="page(*) and !ikiwiki/* and !index and !sandbox and !templates* and !smileys and !shortcuts and !ikiwiki and !RecentChanges and !*/Discussion" archive="yes"]] diff --git a/index.md b/index.md new file mode 100644 index 0000000..778951b --- /dev/null +++ b/index.md @@ -0,0 +1,15 @@ +[[!meta title="Organização: Templates e Protocolos Sociotécnicos"]] + +_**Blueprints, boilerplates, modelos, templates! Prontos para usar e se organizar!**_ + +Este é um repositório de protocolos e templates de gestão pessoal e coletiva contendo 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: [Memes](http://pt.wikipedia.org/wiki/Meme), máquinas e para aumentar a fluidez e a organização de grupos sociais. + +[Saiba como usar](usando)! + +[[!map pages="page(*) and !ikiwiki/* and !index and !sandbox and !templates* and !smileys and !shortcuts and !ikiwiki and !RecentChanges and !*/Discussion" show="title"]] + +Sobre +----- + +* [Repositório](https://git.fluxo.info/templates). +* [Licença](LICENSE). diff --git a/index.mdwn b/index.mdwn deleted file mode 100644 index 778951b..0000000 --- a/index.mdwn +++ /dev/null @@ -1,15 +0,0 @@ -[[!meta title="Organização: Templates e Protocolos Sociotécnicos"]] - -_**Blueprints, boilerplates, modelos, templates! Prontos para usar e se organizar!**_ - -Este é um repositório de protocolos e templates de gestão pessoal e coletiva contendo 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: [Memes](http://pt.wikipedia.org/wiki/Meme), máquinas e para aumentar a fluidez e a organização de grupos sociais. - -[Saiba como usar](usando)! - -[[!map pages="page(*) and !ikiwiki/* and !index and !sandbox and !templates* and !smileys and !shortcuts and !ikiwiki and !RecentChanges and !*/Discussion" show="title"]] - -Sobre ------ - -* [Repositório](https://git.fluxo.info/templates). -* [Licença](LICENSE). diff --git a/mensagens.md b/mensagens.md new file mode 100644 index 0000000..39452f8 --- /dev/null +++ b/mensagens.md @@ -0,0 +1,5 @@ +[[!meta title="Mensagens"]] + +Templates para mensagens. + +[[!map pages="page(mensagens*)" show="title"]] diff --git a/mensagens.mdwn b/mensagens.mdwn deleted file mode 100644 index 39452f8..0000000 --- a/mensagens.mdwn +++ /dev/null @@ -1,5 +0,0 @@ -[[!meta title="Mensagens"]] - -Templates para mensagens. - -[[!map pages="page(mensagens*)" show="title"]] diff --git a/mensagens/certs.md b/mensagens/certs.md new file mode 100644 index 0000000..064b1a4 --- /dev/null +++ b/mensagens/certs.md @@ -0,0 +1,27 @@ +[[!meta title="Informe: mudança de certificado"]] + +De acordo com a política[1] de gestão de certificados X.509 usados nas comunicações +TLS/HTTPS do Saravá e dada a proximidade do vencimento do certificado atual, +o Saravá gerou um novo certificado SSL validado pelo https://gandi.net. + +A assinatura SHA1 do novo certificado é + + SHA1 Fingerprint=$fingerprint + +Detalhes sobre o certificado estão em https://www.sarava.org/certs + +Tal informação pode ser verificada nas informações de segurança do seu +navegador ao acessar um sítio com conexão segura. Detalhes a respeito podem ser +encontrados no Manual de Criptografia[2]. + +O certificado é válido para o domínio sarava.org e todos os seus +subdomínios. Assim, está sendo utilizada conexão segura por padrão na maioria +dos subdomínios de sarava.org (por exemplo www.sarava.org). + +No entanto, alguns sítios ainda podem estar sem conexão criptografada ou +oferecerem links internos utilizando http. + +Em caso de dúvidas, basta entrar em contato :) + +[1] https://protocolos.fluxo.info/./organizacao/comunicacao/cert/ +[2] https://manual.fluxo.info/criptografia/internet diff --git a/mensagens/certs.mdwn b/mensagens/certs.mdwn deleted file mode 100644 index 064b1a4..0000000 --- a/mensagens/certs.mdwn +++ /dev/null @@ -1,27 +0,0 @@ -[[!meta title="Informe: mudança de certificado"]] - -De acordo com a política[1] de gestão de certificados X.509 usados nas comunicações -TLS/HTTPS do Saravá e dada a proximidade do vencimento do certificado atual, -o Saravá gerou um novo certificado SSL validado pelo https://gandi.net. - -A assinatura SHA1 do novo certificado é - - SHA1 Fingerprint=$fingerprint - -Detalhes sobre o certificado estão em https://www.sarava.org/certs - -Tal informação pode ser verificada nas informações de segurança do seu -navegador ao acessar um sítio com conexão segura. Detalhes a respeito podem ser -encontrados no Manual de Criptografia[2]. - -O certificado é válido para o domínio sarava.org e todos os seus -subdomínios. Assim, está sendo utilizada conexão segura por padrão na maioria -dos subdomínios de sarava.org (por exemplo www.sarava.org). - -No entanto, alguns sítios ainda podem estar sem conexão criptografada ou -oferecerem links internos utilizando http. - -Em caso de dúvidas, basta entrar em contato :) - -[1] https://protocolos.fluxo.info/./organizacao/comunicacao/cert/ -[2] https://manual.fluxo.info/criptografia/internet diff --git a/mensagens/downtime.md b/mensagens/downtime.md new file mode 100644 index 0000000..109b870 --- /dev/null +++ b/mensagens/downtime.md @@ -0,0 +1,37 @@ +[[!meta title="Modelo de informe de downtime"]] + +Português +--------- + +Estamos com uma queda inesperada de um de nossos servidores. + +Assim, alguns serviços ficarão inacessíveis nas próximas horas. + + Servidor : servidor.example.org + Problema : não identificado + Tempo estimado : 72 horas + Serviços afetados : + - Todas as listas de discussão. + - Contas de email. + - Todos os vservers hospedados para terceiros/as. + - Todos os sites hospedados nesse servidor. + +Outros serviços e servidores não estão afetados. + +English +------- + +We're having an unexpected downtime in one of our servers. + +Then, some services will be unreachable in the next hours. + + Server : servidor.example.org + Problem : N/A + Expected downtime : 72 hours + Services affected : + - All mailing lists. + - Email accounts. + - All third-party hosted vservers. + - All websites hosted in the server. + +Other servers and services are unaffected. diff --git a/mensagens/downtime.mdwn b/mensagens/downtime.mdwn deleted file mode 100644 index 109b870..0000000 --- a/mensagens/downtime.mdwn +++ /dev/null @@ -1,37 +0,0 @@ -[[!meta title="Modelo de informe de downtime"]] - -Português ---------- - -Estamos com uma queda inesperada de um de nossos servidores. - -Assim, alguns serviços ficarão inacessíveis nas próximas horas. - - Servidor : servidor.example.org - Problema : não identificado - Tempo estimado : 72 horas - Serviços afetados : - - Todas as listas de discussão. - - Contas de email. - - Todos os vservers hospedados para terceiros/as. - - Todos os sites hospedados nesse servidor. - -Outros serviços e servidores não estão afetados. - -English -------- - -We're having an unexpected downtime in one of our servers. - -Then, some services will be unreachable in the next hours. - - Server : servidor.example.org - Problem : N/A - Expected downtime : 72 hours - Services affected : - - All mailing lists. - - Email accounts. - - All third-party hosted vservers. - - All websites hosted in the server. - -Other servers and services are unaffected. diff --git a/muamba.md b/muamba.md new file mode 100644 index 0000000..27a825c --- /dev/null +++ b/muamba.md @@ -0,0 +1,45 @@ +[[!meta title="Clube da Muamba"]] + +[[!map pages="page(muamba*)" show="title"]] + +Sabe aquela festa de rua que não acontece porque falta o gerador de energia, aquele filme que não é feito porque não há câmera ou aquela rádio que não transmite por falta de transmissor? E aquele panfleto que não é impresso porque ninguém tem acesso a uma máquina de Xerox ou aquele passeio que não é feito por falta de bicicletas? + +É muito frustante não conseguir fazer algo por falta de recursos. Mais frustrante ainda é saber que em geral muito desses recursos são possuídos por alguém conhecido ou, alternativamente, poderiam sê-lo caso se soubesse da necessidade do seu uso. Mesmo que alguém compre uma mesa de som para dar uma festa, essa pessoa não a usará necessariamente todos os dias, e isso vale para muitos dos nossos objetos pessoais: máquinas fotográficas, microfones, rádios, etc, nem tudo isso é usado por nós o tempo todo, mas no entanto há um forte apelo do mercado para que cada um de nós tenha um exemplar de cada um dos milhares de produtos da indústria de massa. + +O Clube da Muamba é uma iniciativa cultural de pensar novas formas de economia que não se baseiam no valor de troca, mas no valor de uso não-rival de objetos físicos. Para montar um clube da muamba, basta juntar seus/as amigas/os e colocar na roda o que cada pessoa quer compartilhar. + +Como funciona? +-------------- + +Existem mil maneiras de fazer um Clube da Muamba, cabendo a cada grupo inventar e/ou adaptar a sua e portanto aqui deixamos apenas sugestões de como fazer o seu. O Clube da Muamba não é um grupo fixo ou organização institucional, mas uma idéia para que existam muitos Clubes da Muamba e para que a prática de empréstimos de equipamentos e recursos inativos se torne parte da cultura comum das pessoas ao ponto de ser desempenhado com naturalidade. + +Basta reunir um grupo de pessoas, amigos/as ou voluntários/as que esteja disposto a compartilhar recursos (materiais ou não), sejam livros, eletroeletrônicos, máquinário pesado, veículos de transporte, etc. Cada pessoa ou subgrupo de pessoas do clube pode então tanto compartilhar objetos que já possuem como juntar recursos para adquirir (conjuntamente ou não) outros bens para serem disponibilizados coletivamente. + +Logística +--------- + +Nossa idéia é que não haja gerência cuidando dos empréstimos ou do contato entre as pessoas, mas sim que a logística se realize através de autogestão distribuída: cada pessoa ou grupo de pessoas que for dono de um dado recurso adiciona essa informação numa tabela, juntamente com informações adicionais sobre o recurso e disponibilidade de empréstimo. Assim, a pessoa ou grupo de pessoas que necessitar de um dado recurso disponível precisa apenas entrar em contato com os/as donos do recurso. + +Vaquinha contínua +----------------- + +A vaquinha perpétua é uma forma de aquisição constante, permanente ou variável de equipamentos: um grupo de pessoas mantém um fundo coletivo que é gasto em bens diversos conforme a necessidade de incluí-los no Clube. + +Projetos similares +------------------ + +* [Vizinhocas](https://github.com/coolmeia/vizinhocas). +* [NeighborGoods](http://neighborgoods.net). + +Conservação de equipamentos +--------------------------- + +De preferência: + +* Mantenha ferramentas e equipamentos sempre prontos para o uso! +* Para não perder equipamentos ou ter dificuldades em encontrá-los, mantenha-os sempre num mesmo local. + +Centro de Estocagem de Bugigangas +--------------------------------- + +O que fazer com o monte de coisas acumuladas? Um Centro de Estocagem coletivo numa vizinhança pode dar conta de aproveitar melhor as coisas que não temos um uso imediato. diff --git a/muamba.mdwn b/muamba.mdwn deleted file mode 100644 index 27a825c..0000000 --- a/muamba.mdwn +++ /dev/null @@ -1,45 +0,0 @@ -[[!meta title="Clube da Muamba"]] - -[[!map pages="page(muamba*)" show="title"]] - -Sabe aquela festa de rua que não acontece porque falta o gerador de energia, aquele filme que não é feito porque não há câmera ou aquela rádio que não transmite por falta de transmissor? E aquele panfleto que não é impresso porque ninguém tem acesso a uma máquina de Xerox ou aquele passeio que não é feito por falta de bicicletas? - -É muito frustante não conseguir fazer algo por falta de recursos. Mais frustrante ainda é saber que em geral muito desses recursos são possuídos por alguém conhecido ou, alternativamente, poderiam sê-lo caso se soubesse da necessidade do seu uso. Mesmo que alguém compre uma mesa de som para dar uma festa, essa pessoa não a usará necessariamente todos os dias, e isso vale para muitos dos nossos objetos pessoais: máquinas fotográficas, microfones, rádios, etc, nem tudo isso é usado por nós o tempo todo, mas no entanto há um forte apelo do mercado para que cada um de nós tenha um exemplar de cada um dos milhares de produtos da indústria de massa. - -O Clube da Muamba é uma iniciativa cultural de pensar novas formas de economia que não se baseiam no valor de troca, mas no valor de uso não-rival de objetos físicos. Para montar um clube da muamba, basta juntar seus/as amigas/os e colocar na roda o que cada pessoa quer compartilhar. - -Como funciona? --------------- - -Existem mil maneiras de fazer um Clube da Muamba, cabendo a cada grupo inventar e/ou adaptar a sua e portanto aqui deixamos apenas sugestões de como fazer o seu. O Clube da Muamba não é um grupo fixo ou organização institucional, mas uma idéia para que existam muitos Clubes da Muamba e para que a prática de empréstimos de equipamentos e recursos inativos se torne parte da cultura comum das pessoas ao ponto de ser desempenhado com naturalidade. - -Basta reunir um grupo de pessoas, amigos/as ou voluntários/as que esteja disposto a compartilhar recursos (materiais ou não), sejam livros, eletroeletrônicos, máquinário pesado, veículos de transporte, etc. Cada pessoa ou subgrupo de pessoas do clube pode então tanto compartilhar objetos que já possuem como juntar recursos para adquirir (conjuntamente ou não) outros bens para serem disponibilizados coletivamente. - -Logística ---------- - -Nossa idéia é que não haja gerência cuidando dos empréstimos ou do contato entre as pessoas, mas sim que a logística se realize através de autogestão distribuída: cada pessoa ou grupo de pessoas que for dono de um dado recurso adiciona essa informação numa tabela, juntamente com informações adicionais sobre o recurso e disponibilidade de empréstimo. Assim, a pessoa ou grupo de pessoas que necessitar de um dado recurso disponível precisa apenas entrar em contato com os/as donos do recurso. - -Vaquinha contínua ------------------ - -A vaquinha perpétua é uma forma de aquisição constante, permanente ou variável de equipamentos: um grupo de pessoas mantém um fundo coletivo que é gasto em bens diversos conforme a necessidade de incluí-los no Clube. - -Projetos similares ------------------- - -* [Vizinhocas](https://github.com/coolmeia/vizinhocas). -* [NeighborGoods](http://neighborgoods.net). - -Conservação de equipamentos ---------------------------- - -De preferência: - -* Mantenha ferramentas e equipamentos sempre prontos para o uso! -* Para não perder equipamentos ou ter dificuldades em encontrá-los, mantenha-os sempre num mesmo local. - -Centro de Estocagem de Bugigangas ---------------------------------- - -O que fazer com o monte de coisas acumuladas? Um Centro de Estocagem coletivo numa vizinhança pode dar conta de aproveitar melhor as coisas que não temos um uso imediato. diff --git a/muamba/clube.md b/muamba/clube.md new file mode 100644 index 0000000..7b9e110 --- /dev/null +++ b/muamba/clube.md @@ -0,0 +1,59 @@ +[[!meta title="Clube da Muamba $nome"]] + +O Clube da Muamba $nome pode ser composto por pessoas que fazem parte de uma mesma vizinhança. Para saber a respeito da disponibilidade e viabilidade do empréstimo de um dos recursos listados, entre em contato com o/a dono/a ou zelador/a e eventualmente também com quem está atualmente com ele. + +Por uma questão de logística, as muambas podem estar separadas por região, o que não impede de uma pessoa de outra região pedir algo emprestado que esteja em outra, desde que consiga resolver o problema do transporte :) + +Lista de Muambas +---------------- + + || Equipamento || Detalhes || Disponibilidade || Dono/a ou Zelador/a || Com quem está atualmente || + || Exemplo de equipamento || troca || Total || email@de.contato || email@de.contato || + +Viajantes +--------- + +Esta seção existe para permitir que pessoas que viajarão de um local para outro possam trazer muambas para outras pessoas e grupos (serviço voluntário de mula :P). Recomenda-se dar preferência para trazer muambas a grupos ou objetos que constarão no clube da muamba e deixar muambas para uso exclusivamente pessoal com menor prioridade (mas que nem por isso sejam desencorajados os traslados de muambas pessoais. + + || Viajante || Local de origem || Local de destino || Data de partida || Data de chegada (ou retorno) || Observações || + || - || - || - || - || - || - || + +Lista de Reparos +---------------- + +Nesta tabela as pessoas e/ou grupos podem colocar os bens que, por motivos de força maior, poderiam mas não estão no Clube se estivessem em condições de uso. Também aqueles que são inviáveis para o dono consertar mas de conserto vantajoso para terceiros! :) + + || Recurso || Detalhes || O que precisa(ou gostaria) || Possibilidade de vaquinha || + || || || || || + +Lista de Livros +--------------- + +Aqui ficam listados os livros, revistas, etc que estão na roda, formando assim nossa biblioteca distribuída e autogestionada :) + + || Livro || Autor || Disponibilidade || Dono/a ou Zelador/a || Com quem está atualmente || + || || || || || || + +Lista de Filmes +--------------- + +Esta é uma lista experimental onde ficam listados os filmes que estão na roda, formando assim nossa videoteca distribuída e autogestionada. Adicione apenas filmes em '''cópias físicas removíveis''' (DVDs, VHS, VCD), já que estamos fomentando o empréstimo de bens físicos. Ou seja: se você tiver uma lista imensa de filmes no seu disco, opte por utilizar um sistema de compartilhamento P2P para aliviar o volume desta lista. + + || Filme || Áudio/Legenda || Mídia || Disponibilidade || Dono/a ou Zelador/a || Com quem está atualmente || + || || || || || || || + +Lista de Vontades +----------------- + +Nesta tabela as pessoas e/ou grupos podem colocar os bens que gostariam que estivessem no Clube. + + || Recurso || Detalhes || Quem gostaria ou precisa || Possibilidade de vaquinha || + || || || || || + +Lista de Reparos +---------------- + +Nesta tabela as pessoas e/ou grupos podem colocar os bens que, por motivos de força maior, poderiam mas não estão no Clube se estivessem em condições de uso. Também aqueles que são inviáveis para o dono consertar mas de conserto vantajoso para terceiros! :) + + || Recurso || Detalhes || O que precisa(ou gostaria) || Possibilidade de vaquinha || + || - || - || - || - || diff --git a/muamba/clube.mdwn b/muamba/clube.mdwn deleted file mode 100644 index 7b9e110..0000000 --- a/muamba/clube.mdwn +++ /dev/null @@ -1,59 +0,0 @@ -[[!meta title="Clube da Muamba $nome"]] - -O Clube da Muamba $nome pode ser composto por pessoas que fazem parte de uma mesma vizinhança. Para saber a respeito da disponibilidade e viabilidade do empréstimo de um dos recursos listados, entre em contato com o/a dono/a ou zelador/a e eventualmente também com quem está atualmente com ele. - -Por uma questão de logística, as muambas podem estar separadas por região, o que não impede de uma pessoa de outra região pedir algo emprestado que esteja em outra, desde que consiga resolver o problema do transporte :) - -Lista de Muambas ----------------- - - || Equipamento || Detalhes || Disponibilidade || Dono/a ou Zelador/a || Com quem está atualmente || - || Exemplo de equipamento || troca || Total || email@de.contato || email@de.contato || - -Viajantes ---------- - -Esta seção existe para permitir que pessoas que viajarão de um local para outro possam trazer muambas para outras pessoas e grupos (serviço voluntário de mula :P). Recomenda-se dar preferência para trazer muambas a grupos ou objetos que constarão no clube da muamba e deixar muambas para uso exclusivamente pessoal com menor prioridade (mas que nem por isso sejam desencorajados os traslados de muambas pessoais. - - || Viajante || Local de origem || Local de destino || Data de partida || Data de chegada (ou retorno) || Observações || - || - || - || - || - || - || - || - -Lista de Reparos ----------------- - -Nesta tabela as pessoas e/ou grupos podem colocar os bens que, por motivos de força maior, poderiam mas não estão no Clube se estivessem em condições de uso. Também aqueles que são inviáveis para o dono consertar mas de conserto vantajoso para terceiros! :) - - || Recurso || Detalhes || O que precisa(ou gostaria) || Possibilidade de vaquinha || - || || || || || - -Lista de Livros ---------------- - -Aqui ficam listados os livros, revistas, etc que estão na roda, formando assim nossa biblioteca distribuída e autogestionada :) - - || Livro || Autor || Disponibilidade || Dono/a ou Zelador/a || Com quem está atualmente || - || || || || || || - -Lista de Filmes ---------------- - -Esta é uma lista experimental onde ficam listados os filmes que estão na roda, formando assim nossa videoteca distribuída e autogestionada. Adicione apenas filmes em '''cópias físicas removíveis''' (DVDs, VHS, VCD), já que estamos fomentando o empréstimo de bens físicos. Ou seja: se você tiver uma lista imensa de filmes no seu disco, opte por utilizar um sistema de compartilhamento P2P para aliviar o volume desta lista. - - || Filme || Áudio/Legenda || Mídia || Disponibilidade || Dono/a ou Zelador/a || Com quem está atualmente || - || || || || || || || - -Lista de Vontades ------------------ - -Nesta tabela as pessoas e/ou grupos podem colocar os bens que gostariam que estivessem no Clube. - - || Recurso || Detalhes || Quem gostaria ou precisa || Possibilidade de vaquinha || - || || || || || - -Lista de Reparos ----------------- - -Nesta tabela as pessoas e/ou grupos podem colocar os bens que, por motivos de força maior, poderiam mas não estão no Clube se estivessem em condições de uso. Também aqueles que são inviáveis para o dono consertar mas de conserto vantajoso para terceiros! :) - - || Recurso || Detalhes || O que precisa(ou gostaria) || Possibilidade de vaquinha || - || - || - || - || - || diff --git a/muamba/emprestimos.md b/muamba/emprestimos.md new file mode 100644 index 0000000..9b6967a --- /dev/null +++ b/muamba/emprestimos.md @@ -0,0 +1,19 @@ +[[!meta title="Termo de empréstimo"]] + +Plano Básico +------------ + +Adoro emprestar minhas coisas! Empresto a muamba que você me pediu desde que: + + - Você devolva conforme nosso combinado :) + - Caso haja alguma quebra ou perda da muamba, você se compromete a ressarcir o prejú. + - Se eu precisar dela antes do nosso combinado, você topa devolvê-la. + +Planos específicos +------------------ + +* Coisas frágeis (discos de vinil): como cuidar. +* Como proceder em casos de quebras: +* Peças substituíveis. +* Peças insubstituíveis. +* Entrega e devolução. diff --git a/muamba/emprestimos.mdwn b/muamba/emprestimos.mdwn deleted file mode 100644 index 9b6967a..0000000 --- a/muamba/emprestimos.mdwn +++ /dev/null @@ -1,19 +0,0 @@ -[[!meta title="Termo de empréstimo"]] - -Plano Básico ------------- - -Adoro emprestar minhas coisas! Empresto a muamba que você me pediu desde que: - - - Você devolva conforme nosso combinado :) - - Caso haja alguma quebra ou perda da muamba, você se compromete a ressarcir o prejú. - - Se eu precisar dela antes do nosso combinado, você topa devolvê-la. - -Planos específicos ------------------- - -* Coisas frágeis (discos de vinil): como cuidar. -* Como proceder em casos de quebras: -* Peças substituíveis. -* Peças insubstituíveis. -* Entrega e devolução. diff --git a/orfanato.md b/orfanato.md new file mode 100644 index 0000000..a0b7cb4 --- /dev/null +++ b/orfanato.md @@ -0,0 +1,24 @@ +[[!meta title="Orfanato de Projetos"]] + +* Trata-se de um esquema em que alguém possui um portfolio de projetos e + procura pessoas e times que queiram adotá-los. + +* Uma rotina periódica faz com que o orfanato entre em contato com as pessoas + para checar se os projetos que elas adotaram não foram abandonados. + +## Requisitos + +Para um projeto possa ser adotado, a pessoa ou grupo responsável terá de estar de acordo com algumas coisas: + +* O desenvolvimento precisa ser em software livre. +* O software precisa ser instanciável, ou seja, grupos e pessoas podem criar instalações deles onde quiserem. +* Gestão da instância principal coletiva e com abertura. +* Respeito à privacidade, preocupação com segurança e que estejam na linha dos [Princípios Éticos](https://templates.fluxo.info/etica/coletiva/). +* [Responsabilização](/coletivo/responsabilizacao/). + +Além disso, o orfanato tenta, na medida do possível: + +* Prestar consultoria sobre os projetos. +* Realizar checagens periódicas (pings semestrais, por exemplos) para saber se + as pessoas ainda estão mantendo os projetos ou se é necessário procurar + outras pessoas para adotá-los. diff --git a/orfanato.mdwn b/orfanato.mdwn deleted file mode 100644 index a0b7cb4..0000000 --- a/orfanato.mdwn +++ /dev/null @@ -1,24 +0,0 @@ -[[!meta title="Orfanato de Projetos"]] - -* Trata-se de um esquema em que alguém possui um portfolio de projetos e - procura pessoas e times que queiram adotá-los. - -* Uma rotina periódica faz com que o orfanato entre em contato com as pessoas - para checar se os projetos que elas adotaram não foram abandonados. - -## Requisitos - -Para um projeto possa ser adotado, a pessoa ou grupo responsável terá de estar de acordo com algumas coisas: - -* O desenvolvimento precisa ser em software livre. -* O software precisa ser instanciável, ou seja, grupos e pessoas podem criar instalações deles onde quiserem. -* Gestão da instância principal coletiva e com abertura. -* Respeito à privacidade, preocupação com segurança e que estejam na linha dos [Princípios Éticos](https://templates.fluxo.info/etica/coletiva/). -* [Responsabilização](/coletivo/responsabilizacao/). - -Além disso, o orfanato tenta, na medida do possível: - -* Prestar consultoria sobre os projetos. -* Realizar checagens periódicas (pings semestrais, por exemplos) para saber se - as pessoas ainda estão mantendo os projetos ou se é necessário procurar - outras pessoas para adotá-los. diff --git a/organizacao.md b/organizacao.md new file mode 100644 index 0000000..b2137ca --- /dev/null +++ b/organizacao.md @@ -0,0 +1,106 @@ +[[!meta title="Organização"]] + +Índice +------ + +[[!map pages="page(organizacao*)" show="title"]] + +Se a [modelagem de ameaças](https://threat.fluxo.info) é a mãe da segurança, organização é a mãe de tudo! + +Grupos +====== + +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. + +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.mdwn b/organizacao.mdwn deleted file mode 100644 index b2137ca..0000000 --- a/organizacao.mdwn +++ /dev/null @@ -1,106 +0,0 @@ -[[!meta title="Organização"]] - -Índice ------- - -[[!map pages="page(organizacao*)" show="title"]] - -Se a [modelagem de ameaças](https://threat.fluxo.info) é a mãe da segurança, organização é a mãe de tudo! - -Grupos -====== - -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. - -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/pessoal.md b/pessoal.md new file mode 100644 index 0000000..ee989f6 --- /dev/null +++ b/pessoal.md @@ -0,0 +1,145 @@ +[[!meta title="Pessoal"]] + +[[!map pages="page(pessoal*)" show="title"]] + +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. +* Logística: é um projeto que gerencia o estoque. + +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. + +Pragmática +---------- + +Trabalho reprodutivo, atividades básicas, baseline, constância: + +* Homeostase. +* Logística. +* Inventário. +* Auditoria. +* Rotina. +* Regulação. +* Regularidade. +* Prática. +* Pragmatismo. +* Prosa. + +Técnica, simplexidade: garante que o baseline tenha carga mínima; linha de base operacional. + +A espiral de anéis +------------------ + +### Os dois momentos: homeostase e pesquisa + + (técnica) (arte) + (automático) (manual) + (produção) (desenvolvimento) + homeostase ->- pesquisa + \ / \ + `------<----´ `-----> arquivamento + (incorporação) ` + `--> descarte + +A produção pode consistir tanto de automatismo pessoais (corporificados) +quanto na automação de sistemas para realização de tarefas constantes. + +### Método + + + (tática) (estratégia) (logística) + |-- brainstorm --|--------- planejamento ----------------|-- realização --| + + + atividades imediatas: + ----------------------------->--------------------------------------------- + + atividades mediadas: + + .-->- descarte --------<------------- + / .´ `. + .--->- arquivamento -->--. .----<-------. + / `. / \ + coletores ZTD -->-- agenda contextual (loop principal) ->- execução + \ \ . / + \ `->- TODOs contextuais ->--´ / + \ / + ------------------<-------------------------------´ + + +### Mecânica da agenda + +* Coletores, agendas e listas de tarefas são buffers de armazenamento de desejos ou intenções + de realização. São escalonadores de atividades. +* Arquivos são listas de atividades que nunca ou já ocorreram mas que não compõe a lista atual + de intenções de realização. +* ChangeLogs são locais de descrição de tarefas que ocorreram. + +A vida de um evento: + +* Eventos singulares: ocorrem uma vez e são automaticamente são arquivados. +* Eventos recorrente ou multi-etapas: após a iteração atual devem ter sua próxima ocorrência agendada. + +Exemplos: + +* Eventos singulares: encontrar alguém numa data e local específicos. +* Eventos recorrentes: checagem de inventário, auditoria em sistemas. +* Eventos multi-etapas: tirar um documento. + +## Distribuição de eventos + +* Quebrar tarefas grandes em tarefas menores. +* Empirismo para determinar quantidade de tarefas para cada dia. +* Recomendações ZTD, GTD, Pomodoro, etc. +* A rotina não pode ser tornar uma camisa de força para a pessoa; a ideia é justamente o contrário: + que ela otimize o tempo o bem viver. + +### Documentação + +Cada processo pode ser composto por documentação pública ou privada: + + documentação --->---- separação de especificidades -->--- documentação pública + privada e dados sensíveis diff --git a/pessoal.mdwn b/pessoal.mdwn deleted file mode 100644 index ee989f6..0000000 --- a/pessoal.mdwn +++ /dev/null @@ -1,145 +0,0 @@ -[[!meta title="Pessoal"]] - -[[!map pages="page(pessoal*)" show="title"]] - -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. -* Logística: é um projeto que gerencia o estoque. - -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. - -Pragmática ----------- - -Trabalho reprodutivo, atividades básicas, baseline, constância: - -* Homeostase. -* Logística. -* Inventário. -* Auditoria. -* Rotina. -* Regulação. -* Regularidade. -* Prática. -* Pragmatismo. -* Prosa. - -Técnica, simplexidade: garante que o baseline tenha carga mínima; linha de base operacional. - -A espiral de anéis ------------------- - -### Os dois momentos: homeostase e pesquisa - - (técnica) (arte) - (automático) (manual) - (produção) (desenvolvimento) - homeostase ->- pesquisa - \ / \ - `------<----´ `-----> arquivamento - (incorporação) ` - `--> descarte - -A produção pode consistir tanto de automatismo pessoais (corporificados) -quanto na automação de sistemas para realização de tarefas constantes. - -### Método - - - (tática) (estratégia) (logística) - |-- brainstorm --|--------- planejamento ----------------|-- realização --| - - - atividades imediatas: - ----------------------------->--------------------------------------------- - - atividades mediadas: - - .-->- descarte --------<------------- - / .´ `. - .--->- arquivamento -->--. .----<-------. - / `. / \ - coletores ZTD -->-- agenda contextual (loop principal) ->- execução - \ \ . / - \ `->- TODOs contextuais ->--´ / - \ / - ------------------<-------------------------------´ - - -### Mecânica da agenda - -* Coletores, agendas e listas de tarefas são buffers de armazenamento de desejos ou intenções - de realização. São escalonadores de atividades. -* Arquivos são listas de atividades que nunca ou já ocorreram mas que não compõe a lista atual - de intenções de realização. -* ChangeLogs são locais de descrição de tarefas que ocorreram. - -A vida de um evento: - -* Eventos singulares: ocorrem uma vez e são automaticamente são arquivados. -* Eventos recorrente ou multi-etapas: após a iteração atual devem ter sua próxima ocorrência agendada. - -Exemplos: - -* Eventos singulares: encontrar alguém numa data e local específicos. -* Eventos recorrentes: checagem de inventário, auditoria em sistemas. -* Eventos multi-etapas: tirar um documento. - -## Distribuição de eventos - -* Quebrar tarefas grandes em tarefas menores. -* Empirismo para determinar quantidade de tarefas para cada dia. -* Recomendações ZTD, GTD, Pomodoro, etc. -* A rotina não pode ser tornar uma camisa de força para a pessoa; a ideia é justamente o contrário: - que ela otimize o tempo o bem viver. - -### Documentação - -Cada processo pode ser composto por documentação pública ou privada: - - documentação --->---- separação de especificidades -->--- documentação pública - privada e dados sensíveis diff --git a/pessoal/basico.md b/pessoal/basico.md new file mode 100644 index 0000000..e9b0c5a --- /dev/null +++ b/pessoal/basico.md @@ -0,0 +1,89 @@ +[[!meta title="Necessidades básicas"]] + +* Baseline vital. +* A vida não é quadrada e isto é um modelo. +* O dia é curto demais para que a lista seja completada. +* Este é um roteiro para estar bem e fazer o bem todos os dias. +* Evitando cansaço, ansiedade e mal uso de recursos. +* Para ser [ético](/etica/pessoal). + +Metodologia +----------- + +* Em ordem de realização e escala de tempo padrões. +* Resolver prioridades em ordem de importância! +* É mais importante atacar um pouco de cada prioridade do que focar demasiadamente em apenas algumas delas. +* É preciso estar bem para poder fazer o bem. +* Apesar da ordem acima, as pessoas sempre vem antes. Se algum prezado/a estiver precisando, a ordem das prioridades muda temporariamente. +* Prioridades de mais importância devem ser realizadas em escala de tempo menor (segundos, minutos, horas), + enquanto que prioridades mais baixas devem ser realizas em escala de tempo maior (dias, semanas, meses, anos). + +Exemplo de rotina diária ideal +------------------------------ + +Especificidades na lista de tarefas/calendário. + +* Descanso (8:00). +* Higiene (0:30). +* Alimentação (1:00). +* Exercícios (1:00). +* Organização (0:30). +* Subsistência (8:30). +* Existência (5:00). + +Checklist de necessidades +------------------------- + +0. Ambientais (0:00): + * Ar (CNTP). + * Chão. + * Iluminação (conforme ocasião). +1. Circadianas (8:00): + * Sono. + * Descanso. +2. Fisiológicas (1:00): + * Água. + * Alimentação, mastigando bastante. + * Purgas! + * Estética e higiene: + * Banho. + * Bucal. + * Roupa limpa. + * Limpeza do rosto. + * Pelos aparados. + * Unhas lixadas. + * Bronze. +3. Comportamentais (1:00): + * Meditação. + * Exercícios físicos: + * Postura. + * Alongamento. + * Exercícios oculares. + * Ciclismo. + * Musculação. +4. Estratégicas (0:30): + * Organização! + * Informações táticas (tempo, trânsito, emergências). +5. Subsistência: + * Trabalho (6:00). + * Estudo (2:00). + * Casa (0:30). +6. Existência: + * Social. + * Família. + * Cultura. + * Atividades apaixonantes. + * Auto-análise. + +Referências +----------- + +* Balance: trouble to change context or change it too often. +* Dose de estoicismo, ascetismo e frugalidade. +* [Erich Fromm's eight basic needs](https://en.wikipedia.org/wiki/Erich_Fromm#Psychological_theory). +* [Maslow's hierarchy of needs - Wikipedia, the free encyclopedia](https://en.wikipedia.org/wiki/Maslow%27s_hierarchy_of_needs). +* [Seis chaves para ser feliz, segundo a Universidade de Harvard](http://brasil.elpais.com/brasil/2015/06/16/ciencia/1434480172_001091.html) +* [A lição de Epicteto: aceitar os fatos é um passo essencial para a serenidade](http://www.diariodocentrodomundo.com.br/aceitar-os-fatos-e-um-passo-essencial-para-a-felicidade/). +* [Zen to Done](http://lucasteixeira.com/ztd/). +* [Comunidade Portuguesa de Ginástica Ocular](http://ginasticaocular.net/). +* [Como Exercitar seus Olhos: 9 Passos (com Imagens)](http://pt.wikihow.com/Exercitar-seus-Olhos). diff --git a/pessoal/basico.mdwn b/pessoal/basico.mdwn deleted file mode 100644 index e9b0c5a..0000000 --- a/pessoal/basico.mdwn +++ /dev/null @@ -1,89 +0,0 @@ -[[!meta title="Necessidades básicas"]] - -* Baseline vital. -* A vida não é quadrada e isto é um modelo. -* O dia é curto demais para que a lista seja completada. -* Este é um roteiro para estar bem e fazer o bem todos os dias. -* Evitando cansaço, ansiedade e mal uso de recursos. -* Para ser [ético](/etica/pessoal). - -Metodologia ------------ - -* Em ordem de realização e escala de tempo padrões. -* Resolver prioridades em ordem de importância! -* É mais importante atacar um pouco de cada prioridade do que focar demasiadamente em apenas algumas delas. -* É preciso estar bem para poder fazer o bem. -* Apesar da ordem acima, as pessoas sempre vem antes. Se algum prezado/a estiver precisando, a ordem das prioridades muda temporariamente. -* Prioridades de mais importância devem ser realizadas em escala de tempo menor (segundos, minutos, horas), - enquanto que prioridades mais baixas devem ser realizas em escala de tempo maior (dias, semanas, meses, anos). - -Exemplo de rotina diária ideal ------------------------------- - -Especificidades na lista de tarefas/calendário. - -* Descanso (8:00). -* Higiene (0:30). -* Alimentação (1:00). -* Exercícios (1:00). -* Organização (0:30). -* Subsistência (8:30). -* Existência (5:00). - -Checklist de necessidades -------------------------- - -0. Ambientais (0:00): - * Ar (CNTP). - * Chão. - * Iluminação (conforme ocasião). -1. Circadianas (8:00): - * Sono. - * Descanso. -2. Fisiológicas (1:00): - * Água. - * Alimentação, mastigando bastante. - * Purgas! - * Estética e higiene: - * Banho. - * Bucal. - * Roupa limpa. - * Limpeza do rosto. - * Pelos aparados. - * Unhas lixadas. - * Bronze. -3. Comportamentais (1:00): - * Meditação. - * Exercícios físicos: - * Postura. - * Alongamento. - * Exercícios oculares. - * Ciclismo. - * Musculação. -4. Estratégicas (0:30): - * Organização! - * Informações táticas (tempo, trânsito, emergências). -5. Subsistência: - * Trabalho (6:00). - * Estudo (2:00). - * Casa (0:30). -6. Existência: - * Social. - * Família. - * Cultura. - * Atividades apaixonantes. - * Auto-análise. - -Referências ------------ - -* Balance: trouble to change context or change it too often. -* Dose de estoicismo, ascetismo e frugalidade. -* [Erich Fromm's eight basic needs](https://en.wikipedia.org/wiki/Erich_Fromm#Psychological_theory). -* [Maslow's hierarchy of needs - Wikipedia, the free encyclopedia](https://en.wikipedia.org/wiki/Maslow%27s_hierarchy_of_needs). -* [Seis chaves para ser feliz, segundo a Universidade de Harvard](http://brasil.elpais.com/brasil/2015/06/16/ciencia/1434480172_001091.html) -* [A lição de Epicteto: aceitar os fatos é um passo essencial para a serenidade](http://www.diariodocentrodomundo.com.br/aceitar-os-fatos-e-um-passo-essencial-para-a-felicidade/). -* [Zen to Done](http://lucasteixeira.com/ztd/). -* [Comunidade Portuguesa de Ginástica Ocular](http://ginasticaocular.net/). -* [Como Exercitar seus Olhos: 9 Passos (com Imagens)](http://pt.wikihow.com/Exercitar-seus-Olhos). diff --git a/pessoal/contabilidade.md b/pessoal/contabilidade.md new file mode 100644 index 0000000..b4e5a0d --- /dev/null +++ b/pessoal/contabilidade.md @@ -0,0 +1,4 @@ +[[!meta title="Contabilidade Pessoal"]] + +* [Comprovantes de pagamento: quando se desfazer deles?](http://economia.estadao.com.br/blogs/claudio-considera/comprovantes-de-pagamento-quando-se-desfazer-deles/). +* [Lei 12007/2009 - Dispõe sobre a emissão de declaração de quitação anual de débitos pelas pessoas jurídicas prestadoras de serviços públicos ou privados.](http://www.planalto.gov.br/ccivil_03/_Ato2007-2010/2009/Lei/L12007.htm). diff --git a/pessoal/contabilidade.mdwn b/pessoal/contabilidade.mdwn deleted file mode 100644 index b4e5a0d..0000000 --- a/pessoal/contabilidade.mdwn +++ /dev/null @@ -1,4 +0,0 @@ -[[!meta title="Contabilidade Pessoal"]] - -* [Comprovantes de pagamento: quando se desfazer deles?](http://economia.estadao.com.br/blogs/claudio-considera/comprovantes-de-pagamento-quando-se-desfazer-deles/). -* [Lei 12007/2009 - Dispõe sobre a emissão de declaração de quitação anual de débitos pelas pessoas jurídicas prestadoras de serviços públicos ou privados.](http://www.planalto.gov.br/ccivil_03/_Ato2007-2010/2009/Lei/L12007.htm). diff --git a/pessoal/saude.md b/pessoal/saude.md new file mode 100644 index 0000000..535c1e8 --- /dev/null +++ b/pessoal/saude.md @@ -0,0 +1,7 @@ +[[!meta title="Ficha médica / Medical record"]] + + Nome / Name : José Bedeu + Tipo sanguíneo / Blood type: A+ + Endereço / address : Rua dos Parnasianos, 35 + São Longuinho - RJ - 30353-129 - Brasil + Telefone / phone : +55 12 0000 0000 diff --git a/pessoal/saude.mdwn b/pessoal/saude.mdwn deleted file mode 100644 index 535c1e8..0000000 --- a/pessoal/saude.mdwn +++ /dev/null @@ -1,7 +0,0 @@ -[[!meta title="Ficha médica / Medical record"]] - - Nome / Name : José Bedeu - Tipo sanguíneo / Blood type: A+ - Endereço / address : Rua dos Parnasianos, 35 - São Longuinho - RJ - 30353-129 - Brasil - Telefone / phone : +55 12 0000 0000 diff --git a/project.md b/project.md new file mode 100644 index 0000000..db092d8 --- /dev/null +++ b/project.md @@ -0,0 +1,21 @@ +[[!meta title="Projetos"]] + +## Sistemas de tarefas simples + +Sistema de tickets, como por exemplo: + +* No README. +* Arquivo TODO em formatos plaintext, Markdown, YAML ou híbridos. +* Um arquivo por tarefa em pastas `open` e `closed`. +* Ditz, bugs-everywhere, taskwarrior ou similar. +* Aplicação própria (Trac, etc) +* TODOs and FIXMEs ao longo do código em última instância. + +## Projetos de Software + +* Vagrantfile e manifests do puppet. +* Git ou VCS usado upstream. +* Branches de desenvolvimento e upstream. +* Workflow padrão (git-flow, git-hooks, etc). +* Suíte de testes. +* Adotar [Semantic Versioning](http://semver.org). diff --git a/project.mdwn b/project.mdwn deleted file mode 100644 index db092d8..0000000 --- a/project.mdwn +++ /dev/null @@ -1,21 +0,0 @@ -[[!meta title="Projetos"]] - -## Sistemas de tarefas simples - -Sistema de tickets, como por exemplo: - -* No README. -* Arquivo TODO em formatos plaintext, Markdown, YAML ou híbridos. -* Um arquivo por tarefa em pastas `open` e `closed`. -* Ditz, bugs-everywhere, taskwarrior ou similar. -* Aplicação própria (Trac, etc) -* TODOs and FIXMEs ao longo do código em última instância. - -## Projetos de Software - -* Vagrantfile e manifests do puppet. -* Git ou VCS usado upstream. -* Branches de desenvolvimento e upstream. -* Workflow padrão (git-flow, git-hooks, etc). -* Suíte de testes. -* Adotar [Semantic Versioning](http://semver.org). diff --git a/provedor.md b/provedor.md new file mode 100644 index 0000000..8e1667a --- /dev/null +++ b/provedor.md @@ -0,0 +1,3 @@ +[[!meta title="Provedor de Serviços de Internet - ISP"]] + +[[!map pages="page(provedor*)" show="title"]] diff --git a/provedor.mdwn b/provedor.mdwn deleted file mode 100644 index 8e1667a..0000000 --- a/provedor.mdwn +++ /dev/null @@ -1,3 +0,0 @@ -[[!meta title="Provedor de Serviços de Internet - ISP"]] - -[[!map pages="page(provedor*)" show="title"]] diff --git a/provedor/backups.md b/provedor/backups.md new file mode 100644 index 0000000..88e4173 --- /dev/null +++ b/provedor/backups.md @@ -0,0 +1,36 @@ +[[!meta title="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/provedor/backups.mdwn b/provedor/backups.mdwn deleted file mode 100644 index 88e4173..0000000 --- a/provedor/backups.mdwn +++ /dev/null @@ -1,36 +0,0 @@ -[[!meta title="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/provedor/backups/entrega.md b/provedor/backups/entrega.md new file mode 100644 index 0000000..860532c --- /dev/null +++ b/provedor/backups/entrega.md @@ -0,0 +1,80 @@ +[[!meta title="Entrega de backups solicitados"]] + +Processo que consiste na entrega de backups solicitados por grupos e pessoas hospedadas na infra-estrutura do Coletivo. As tarefas envolvidas consistem em: + + 1. Obter as solicitações a backups e organizá-las numa tabela, mantendo assim o Coletivo informado sobre o andamento deste processo. Por possivelmente existirem backups de qualidades distintas, é preciso perguntar à parte solicitante, caso necessário, de qual backup os dados precisam ser entegues. + 2. Obter, caso existente, o backup solicitado, realizando uma auditoria caso necessário. + 3. Disponibilizar os backups apenas às pessoas responsáveis pelos ou donas dos dados ou informá-las caso o backup não exista. Informá-las também se o eventual backup foi ou não auditado e: + a. Caso tenha sido auditado, disponibilizar, em linhas gerais, o procedimento utilizado. + b. Caso não tenha sido auditado, informal qual risco isso representa. + +Auditoria do backup +------------------- + +Quando necessária, a auditoria básica consiste em: + + 1. Retirar qualquer código executável que possa ser substituído. + 2. Marcar todo o código executável insubstituível como vulnerável, cuja auditoria é deve ser repassada para o grupo dono do código. + 3. Destruição ou modificação de qualquer senha encontrada, mesmo que a mesma se encontre armazenada de modo cifrado. + 4. Auditagem básica de conteúdo: verificação de datas de acesso e escrita a arquivos, passar anti-virus, etc. + 5. Auditagem avançada de conteúdo, se possível. + +Procedimentos mais refinados ficam à cargo da situação e do grupo de trabalho de entrega de backups solicitados (composto pelas pessoas responsabilizadas pelas tarefas acima mencionadas). + +Prazos +------ + +O prazo de entrega de backups é proporcional ao tamanho do mesmo e à necessidade de auditoria: + + * Backups de até 100MB: entrega em até 30 dias. + * Backups de até 1GB: entrega em até 60 dias. + * Backups maiores que 1GB: entrega em até 90 dias. + +No caso de necessidade de auditoria, o prazo de entrega é duplicado. + +Template +-------- + + Conforme solicitado, o último backup disponível de $descricao, datado de $data + e obtido $origem, já está disponível. + + Seguem os dados: + + - URL: https://backups.$dominio/$sitio + - Conta: $sitio + - Senha: $senha + + O https://backups.$dominio atualmente usa um certificado SSL + auto-assinado, cuja impressão digital é + + $fingerprint + + Hashes dos arquivos disponibilizados: + + md5sum: $hashes + sha1sum: $hashes + + Auditoria realizada: + + - Busca e eventual remoção de código executável. + - Mudança de senhas em banco de dados (senhas truncadas). + - Busca por vírus. + + Tarefas não-realizadas porém recomendadas: + + - Checagem do conteúdo do banco de dados (para evitar calúnia ou + desinformação) + - Checagem do conteúdo dos arquivos. + - IMPORTANTE: checagem de usuários para evitar inscrições de + elementos estranhos. + - Checagem da configurações da instância, caso ela seja reinstalada + noutro local. + - Limpeza do spam e desativação de todas as contas desconhecidas + (principalmente relacionadas a spam). + + Observações: + + - Em princípio, não há prazo para a permanência de tal backup + no local disponibilizado. No entanto, pode ser que ele precise + ser apagado para liberar espaço ou nalgum procedimento de + limpeza. Por isso, recomenda-se que sejam baixados o quanto antes. diff --git a/provedor/backups/entrega.mdwn b/provedor/backups/entrega.mdwn deleted file mode 100644 index 860532c..0000000 --- a/provedor/backups/entrega.mdwn +++ /dev/null @@ -1,80 +0,0 @@ -[[!meta title="Entrega de backups solicitados"]] - -Processo que consiste na entrega de backups solicitados por grupos e pessoas hospedadas na infra-estrutura do Coletivo. As tarefas envolvidas consistem em: - - 1. Obter as solicitações a backups e organizá-las numa tabela, mantendo assim o Coletivo informado sobre o andamento deste processo. Por possivelmente existirem backups de qualidades distintas, é preciso perguntar à parte solicitante, caso necessário, de qual backup os dados precisam ser entegues. - 2. Obter, caso existente, o backup solicitado, realizando uma auditoria caso necessário. - 3. Disponibilizar os backups apenas às pessoas responsáveis pelos ou donas dos dados ou informá-las caso o backup não exista. Informá-las também se o eventual backup foi ou não auditado e: - a. Caso tenha sido auditado, disponibilizar, em linhas gerais, o procedimento utilizado. - b. Caso não tenha sido auditado, informal qual risco isso representa. - -Auditoria do backup -------------------- - -Quando necessária, a auditoria básica consiste em: - - 1. Retirar qualquer código executável que possa ser substituído. - 2. Marcar todo o código executável insubstituível como vulnerável, cuja auditoria é deve ser repassada para o grupo dono do código. - 3. Destruição ou modificação de qualquer senha encontrada, mesmo que a mesma se encontre armazenada de modo cifrado. - 4. Auditagem básica de conteúdo: verificação de datas de acesso e escrita a arquivos, passar anti-virus, etc. - 5. Auditagem avançada de conteúdo, se possível. - -Procedimentos mais refinados ficam à cargo da situação e do grupo de trabalho de entrega de backups solicitados (composto pelas pessoas responsabilizadas pelas tarefas acima mencionadas). - -Prazos ------- - -O prazo de entrega de backups é proporcional ao tamanho do mesmo e à necessidade de auditoria: - - * Backups de até 100MB: entrega em até 30 dias. - * Backups de até 1GB: entrega em até 60 dias. - * Backups maiores que 1GB: entrega em até 90 dias. - -No caso de necessidade de auditoria, o prazo de entrega é duplicado. - -Template --------- - - Conforme solicitado, o último backup disponível de $descricao, datado de $data - e obtido $origem, já está disponível. - - Seguem os dados: - - - URL: https://backups.$dominio/$sitio - - Conta: $sitio - - Senha: $senha - - O https://backups.$dominio atualmente usa um certificado SSL - auto-assinado, cuja impressão digital é - - $fingerprint - - Hashes dos arquivos disponibilizados: - - md5sum: $hashes - sha1sum: $hashes - - Auditoria realizada: - - - Busca e eventual remoção de código executável. - - Mudança de senhas em banco de dados (senhas truncadas). - - Busca por vírus. - - Tarefas não-realizadas porém recomendadas: - - - Checagem do conteúdo do banco de dados (para evitar calúnia ou - desinformação) - - Checagem do conteúdo dos arquivos. - - IMPORTANTE: checagem de usuários para evitar inscrições de - elementos estranhos. - - Checagem da configurações da instância, caso ela seja reinstalada - noutro local. - - Limpeza do spam e desativação de todas as contas desconhecidas - (principalmente relacionadas a spam). - - Observações: - - - Em princípio, não há prazo para a permanência de tal backup - no local disponibilizado. No entanto, pode ser que ele precise - ser apagado para liberar espaço ou nalgum procedimento de - limpeza. Por isso, recomenda-se que sejam baixados o quanto antes. diff --git a/provedor/cert.md b/provedor/cert.md new file mode 100644 index 0000000..d66061f --- /dev/null +++ b/provedor/cert.md @@ -0,0 +1,123 @@ +[[!meta title="Gestão de chave e certificado SSL"]] + +O presente processo trata da gestão de chave e certificado SSL para conexões ditas seguras entre servidores do Coletivo. + +Considerações +------------- + +O Coletivo reconhece que + + 1. O protocolo HTTPS possui sérios problemas de design, impedindo por exemplo que diferentes certificados possam ser utilizados num mesmo IP. + + 2. A indústria da certificação digital representa um sério risco de segurança e uma [imposição tecnocrata](http://lair.fifthhorseman.net/~dkg/tls-centralization/) à utilização prática do HTTPS. Ela recria um domínio cartorial no cyberespaço e pode a qualquer momento [ser utilizada por governos ou corporações para forjar certificados autenticados](http://web.monkeysphere.info/news/internet_secret_backdoor/) e com isso [grampear](https://secure.wikimedia.org/wikipedia/en/wiki/Man-in-the-middle_attack) a conexão entre usuários/as e computadores. + + 3. Idealmente, a atitude a ser tomada por um coletivo técnico radical deveria de não utilizar a indústria da certificação como meio de assegurar a identificação de seus serviços e máquinas. Deveria, ao invés disso, utilizar apenas esquemas abertos como + a. Certificadores Comunitários como o [CACert](http://cacert.org). + b. [Monkeysphere](http://web.monkeysphere.info). + c. A simples verificação da impressão digital dos certificados mediante algum vínculo direto (por exemplo, troca de fingerprints ou validação via OpenPGP) com os/as administradores das máquinas. + + 4. No entanto + a. Nem todos os navegadores acompanham, por padrão, certificados de entidades comunitárias. É o [caso do CACert](https://secure.wikimedia.org/wikipedia/en/wiki/Cacert#Inclusion_status). + b. A adoção de ferramentas livres para HTTPS ainda está muito longe de se tornar comum. No presente, haveria pouca possibilidade de que uma metodologia livre seja eficiente. Ao invés disso, haveria um involuntário incentivo aos/às usuários para que aceitem certificados considerados como inválidos pelos navegadores, o que pode facilitar ainda mais o grampo: se os usuário aceitam qualquer certificado, então não haveria diferença entre eles aceitarem o certificado verdadeiro do falso. + +Conclusões +---------- + +Portanto, o Coletivo conclui que + + 1. No momento, ainda importante ter um certificado assinado pela indústria da certificação, isto é, por uma entidade autorizada pelo cartel do SSL. + 3. A autoridade certificadora a ser utilizada deve obedecer alguns critérios básicos: + a. Não é diretamente conectada a uma agência governamental. + b. Não possui problemas políticos óbvios. + c. Cujo certificado raíz não está encadeado com certificados que não satisfazem os critérios acima. + 2. Dada a sua insuficiência, tal certificação corporativa não deve ser o único meio para a validação dos certificados SSL e assim esquemas alternativos como o [Monkeysphere](http://web.monkeysphere.info) devem ser utilizados e encorajados, de modo que haja um aumento da massa crítica necessária para tornar tais métodos mais populares. O mesmo se aplica para a verificação da impressão digital dos certificados. + +Utilização de HTTPS +------------------- + +Conforme o documento [Best Practices for Online Service Providers](https://www.eff.org/wp/osp), o Coletivo concorda que conexões HTTPS devem ser utilizadas o máximo possível. + + 1. O Coletivo utilizará HTTPS apenas em servidores confiáveis que onde seja possível armazenar as chaves SSL de forma criptografada. + 2. Utilizar, quando possível, cabeçalhos [HSTS](http://www.debian-administration.org/article/Enabling_HTTP_Strict_Transport_Security_on_debian_servers). + 2. Considerando que o certificado vale apenas para um único domínio e seus subdomínios (isto é, o domínio principal do Coletivo), o Coletivo utilizará HTTPS por padrão apenas: + a. Para serviços, sistemas e sítios que utilizem o domínio principal do Coletivo, quando não houver impedimento técnico para tal. + b. Para outros domínios desde que solicitado pela parte hospedada. + 3. Considerar a utilização de [entradas CAA no DNS](https://links.fluxo.info/tags/caa). + +Implementação +------------- + +A implementação de HTTPS também deve obedecer a uma suite bem estabelecida. + +Tal escolha deve desabilitar uma série de cifras ruins e habilitar aquelas que provém [Perfect Forward Secrecy (PFS)](https://secure.wikimedia.org/wikipedia/en/wiki/Perfect_forward_secrecy). + +Outros protocolos +----------------- + +A utilização do SSL também deve se estender a outras plataformas, como por exemplo email (via TLS) desde que possível e que atenda critérios análogos aos anteriores. + +Escolha de autoridade certificadora +----------------------------------- + +Dentre as autoridades certificadoras, o Coletivo escolhe a [Gandi](https://gandi.net) por: + + 1. Atender os critérios acima estabelecidos. + 2. Diferentemente de outras empresas, possui uma preocupação com privacidade e comprometimento com serviços de internet alternativos e independentes. + 2. [Contribuir com projetos de código aberto](https://secure.wikimedia.org/wikipedia/en/wiki/Gandi#Gandi_supports ), vide [lista](http://en.gandi.net/supports/). + +No entanto, é importante notar as limitações envolvidas na escolha do Gandi: + + Q: Por que muitos grupos usam GANDI como registrar? + R: Porque naqueles tempos (2000), ter seu próprio domínio era tranquilamente + de 5 a 10 vezes mais caro do que hoje. GANDI acabou com esses preços + introduzindo ofertas muito baratas no mercado. E como em geral temos + pouco ou nenhum dinheiro para colocar em projetos, simplemente compramos + nossos domínios lá. + + Q: O que GANDI significa? + R: Isso é uma curiosidade, mas GANDI significa "Gestion et Attribution + des Noms de Domaines Internet", "Atribuição e gestão de nomes de + domínio de Internet". Como empresa, o modelo de negócios era simples: + praticamente tudo automatizado, praticamente sem suporte e preços + baixos. + + Q: Por que GANDI é vista como uma organização política? + R: Os fundadores originais do GANDI tinham idéias políticas sobre bens + comuns e como todo o negócio de nomes de domínio da Internet era + baseado em escassez virtual. Um deles até escreveu um livro, + "Confessions d'un voleur" ("Confissões de um ladrão") no qual ele + descreve extensamente sobre como fez um monte de dinheiro exatamente + vendendo algo que não existia e que não havia sentido em vender. + + Q: Por que GANDI é visto como "descolado"? + R: Alguns dos fundadores originais também eram envolvidos na cena + alternativa da Internet na França. Parte do dinheiro obtida pelo + GANDI ajudou outros projetos, um dos quais o operador sem fins + lucrativos Gitoyen. + + Q: Onde estão esses fundadores agora? + R: Em algum outro lugar! Como não foram capazes de concordar em onde + o dinheiro deveria ir, os quatro fundadores resolveram vender o + GANDI. Eles fizeram isso até por um preço justo. Tentaram vender + para pessoas que respeitariam o espírito original, e em certo + sentido o fizeram. Parece que o GANDI ainda contribui para + projetos de software livre e relacionados, tanto em tempo de + trabalho quanto em dinheiro. + + Q: Devo confiar no GANDI? + R: Da mesma forma que você confia em qualquer companhia capitalista. + Eles preferirão preservar seu negócio ao invés de ajudar você. + +Responsabilização +----------------- + +O Grupo de Trabalho formado pelas pessoas responsáveis pelo presente processo deve: + + 1. Caso o Coletivo disponha de recursos financeiros, manter certificado SSL assinado para `*.dominio` via [Gandi](https://gandi.net). O Coletivo arcará com os custos. Caso contrário, adotar a certificação [CACert](http://www.cacert.org/) como padrão. + 2. Manter formas alternativas de certificação via: + a. [Monkeysphere](http://web.monkeysphere.info). + b. A simples verificação da impressão digital dos certificados mediante algum vínculo direto (por exemplo, troca de fingerprints ou validação via OpenPGP) com os/as administradores das máquinas. + c. Manter, na medida do possível, o público informado das mundanças nas 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/provedor/cert.mdwn b/provedor/cert.mdwn deleted file mode 100644 index d66061f..0000000 --- a/provedor/cert.mdwn +++ /dev/null @@ -1,123 +0,0 @@ -[[!meta title="Gestão de chave e certificado SSL"]] - -O presente processo trata da gestão de chave e certificado SSL para conexões ditas seguras entre servidores do Coletivo. - -Considerações -------------- - -O Coletivo reconhece que - - 1. O protocolo HTTPS possui sérios problemas de design, impedindo por exemplo que diferentes certificados possam ser utilizados num mesmo IP. - - 2. A indústria da certificação digital representa um sério risco de segurança e uma [imposição tecnocrata](http://lair.fifthhorseman.net/~dkg/tls-centralization/) à utilização prática do HTTPS. Ela recria um domínio cartorial no cyberespaço e pode a qualquer momento [ser utilizada por governos ou corporações para forjar certificados autenticados](http://web.monkeysphere.info/news/internet_secret_backdoor/) e com isso [grampear](https://secure.wikimedia.org/wikipedia/en/wiki/Man-in-the-middle_attack) a conexão entre usuários/as e computadores. - - 3. Idealmente, a atitude a ser tomada por um coletivo técnico radical deveria de não utilizar a indústria da certificação como meio de assegurar a identificação de seus serviços e máquinas. Deveria, ao invés disso, utilizar apenas esquemas abertos como - a. Certificadores Comunitários como o [CACert](http://cacert.org). - b. [Monkeysphere](http://web.monkeysphere.info). - c. A simples verificação da impressão digital dos certificados mediante algum vínculo direto (por exemplo, troca de fingerprints ou validação via OpenPGP) com os/as administradores das máquinas. - - 4. No entanto - a. Nem todos os navegadores acompanham, por padrão, certificados de entidades comunitárias. É o [caso do CACert](https://secure.wikimedia.org/wikipedia/en/wiki/Cacert#Inclusion_status). - b. A adoção de ferramentas livres para HTTPS ainda está muito longe de se tornar comum. No presente, haveria pouca possibilidade de que uma metodologia livre seja eficiente. Ao invés disso, haveria um involuntário incentivo aos/às usuários para que aceitem certificados considerados como inválidos pelos navegadores, o que pode facilitar ainda mais o grampo: se os usuário aceitam qualquer certificado, então não haveria diferença entre eles aceitarem o certificado verdadeiro do falso. - -Conclusões ----------- - -Portanto, o Coletivo conclui que - - 1. No momento, ainda importante ter um certificado assinado pela indústria da certificação, isto é, por uma entidade autorizada pelo cartel do SSL. - 3. A autoridade certificadora a ser utilizada deve obedecer alguns critérios básicos: - a. Não é diretamente conectada a uma agência governamental. - b. Não possui problemas políticos óbvios. - c. Cujo certificado raíz não está encadeado com certificados que não satisfazem os critérios acima. - 2. Dada a sua insuficiência, tal certificação corporativa não deve ser o único meio para a validação dos certificados SSL e assim esquemas alternativos como o [Monkeysphere](http://web.monkeysphere.info) devem ser utilizados e encorajados, de modo que haja um aumento da massa crítica necessária para tornar tais métodos mais populares. O mesmo se aplica para a verificação da impressão digital dos certificados. - -Utilização de HTTPS -------------------- - -Conforme o documento [Best Practices for Online Service Providers](https://www.eff.org/wp/osp), o Coletivo concorda que conexões HTTPS devem ser utilizadas o máximo possível. - - 1. O Coletivo utilizará HTTPS apenas em servidores confiáveis que onde seja possível armazenar as chaves SSL de forma criptografada. - 2. Utilizar, quando possível, cabeçalhos [HSTS](http://www.debian-administration.org/article/Enabling_HTTP_Strict_Transport_Security_on_debian_servers). - 2. Considerando que o certificado vale apenas para um único domínio e seus subdomínios (isto é, o domínio principal do Coletivo), o Coletivo utilizará HTTPS por padrão apenas: - a. Para serviços, sistemas e sítios que utilizem o domínio principal do Coletivo, quando não houver impedimento técnico para tal. - b. Para outros domínios desde que solicitado pela parte hospedada. - 3. Considerar a utilização de [entradas CAA no DNS](https://links.fluxo.info/tags/caa). - -Implementação -------------- - -A implementação de HTTPS também deve obedecer a uma suite bem estabelecida. - -Tal escolha deve desabilitar uma série de cifras ruins e habilitar aquelas que provém [Perfect Forward Secrecy (PFS)](https://secure.wikimedia.org/wikipedia/en/wiki/Perfect_forward_secrecy). - -Outros protocolos ------------------ - -A utilização do SSL também deve se estender a outras plataformas, como por exemplo email (via TLS) desde que possível e que atenda critérios análogos aos anteriores. - -Escolha de autoridade certificadora ------------------------------------ - -Dentre as autoridades certificadoras, o Coletivo escolhe a [Gandi](https://gandi.net) por: - - 1. Atender os critérios acima estabelecidos. - 2. Diferentemente de outras empresas, possui uma preocupação com privacidade e comprometimento com serviços de internet alternativos e independentes. - 2. [Contribuir com projetos de código aberto](https://secure.wikimedia.org/wikipedia/en/wiki/Gandi#Gandi_supports ), vide [lista](http://en.gandi.net/supports/). - -No entanto, é importante notar as limitações envolvidas na escolha do Gandi: - - Q: Por que muitos grupos usam GANDI como registrar? - R: Porque naqueles tempos (2000), ter seu próprio domínio era tranquilamente - de 5 a 10 vezes mais caro do que hoje. GANDI acabou com esses preços - introduzindo ofertas muito baratas no mercado. E como em geral temos - pouco ou nenhum dinheiro para colocar em projetos, simplemente compramos - nossos domínios lá. - - Q: O que GANDI significa? - R: Isso é uma curiosidade, mas GANDI significa "Gestion et Attribution - des Noms de Domaines Internet", "Atribuição e gestão de nomes de - domínio de Internet". Como empresa, o modelo de negócios era simples: - praticamente tudo automatizado, praticamente sem suporte e preços - baixos. - - Q: Por que GANDI é vista como uma organização política? - R: Os fundadores originais do GANDI tinham idéias políticas sobre bens - comuns e como todo o negócio de nomes de domínio da Internet era - baseado em escassez virtual. Um deles até escreveu um livro, - "Confessions d'un voleur" ("Confissões de um ladrão") no qual ele - descreve extensamente sobre como fez um monte de dinheiro exatamente - vendendo algo que não existia e que não havia sentido em vender. - - Q: Por que GANDI é visto como "descolado"? - R: Alguns dos fundadores originais também eram envolvidos na cena - alternativa da Internet na França. Parte do dinheiro obtida pelo - GANDI ajudou outros projetos, um dos quais o operador sem fins - lucrativos Gitoyen. - - Q: Onde estão esses fundadores agora? - R: Em algum outro lugar! Como não foram capazes de concordar em onde - o dinheiro deveria ir, os quatro fundadores resolveram vender o - GANDI. Eles fizeram isso até por um preço justo. Tentaram vender - para pessoas que respeitariam o espírito original, e em certo - sentido o fizeram. Parece que o GANDI ainda contribui para - projetos de software livre e relacionados, tanto em tempo de - trabalho quanto em dinheiro. - - Q: Devo confiar no GANDI? - R: Da mesma forma que você confia em qualquer companhia capitalista. - Eles preferirão preservar seu negócio ao invés de ajudar você. - -Responsabilização ------------------ - -O Grupo de Trabalho formado pelas pessoas responsáveis pelo presente processo deve: - - 1. Caso o Coletivo disponha de recursos financeiros, manter certificado SSL assinado para `*.dominio` via [Gandi](https://gandi.net). O Coletivo arcará com os custos. Caso contrário, adotar a certificação [CACert](http://www.cacert.org/) como padrão. - 2. Manter formas alternativas de certificação via: - a. [Monkeysphere](http://web.monkeysphere.info). - b. A simples verificação da impressão digital dos certificados mediante algum vínculo direto (por exemplo, troca de fingerprints ou validação via OpenPGP) com os/as administradores das máquinas. - c. Manter, na medida do possível, o público informado das mundanças nas 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/provedor/hospedagem.md b/provedor/hospedagem.md new file mode 100644 index 0000000..6f1ecc4 --- /dev/null +++ b/provedor/hospedagem.md @@ -0,0 +1,39 @@ +[[!meta title="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/provedor/hospedagem.mdwn b/provedor/hospedagem.mdwn deleted file mode 100644 index 6f1ecc4..0000000 --- a/provedor/hospedagem.mdwn +++ /dev/null @@ -1,39 +0,0 @@ -[[!meta title="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/provedor/hospedagem/carta.md b/provedor/hospedagem/carta.md new file mode 100644 index 0000000..e959ff0 --- /dev/null +++ b/provedor/hospedagem/carta.md @@ -0,0 +1,71 @@ +[[!meta title="Carta de Hospedagem"]] + +A Carta de Hospedagem não apenas estabelece as intenções e princípios que o Coletivo adota para a hospedagem quanto pode ser utilizada como apresentação aos grupos e indivíduos canditatos a hospedagem. + + Carta de Hospedagem do $coletivo + -------------------------------- + + O $coletivo é parte de uma intersecção de vários grupos que discutem política e + tecnologia de diferentes formas. Partindo disso, trabalhamos com servidores de + internet, voltados para distintas finalidades de cooperação. Sendo assim, nossa + idéia é colaborar com grupos/projetos que participem de experiências de apoio + mútuo e múltiplo. + + O $coletivo é um projeto autônomo, mantido por um coletivo de voluntários e + voluntárias. Um dos nossos principais objetivos é a construção coletiva de + espaços públicos, comuns entre diversos projetos e grupos que tenham a intenção + de fortalecer e estreitar sua convivência. + + Nossa intenção não é oferecer um "serviço de hospedagem", por isso não estamos + dispostos/as a nos aproximar de grupos que busquem este tipo de serviço. + Queremos que os grupos por nós hospedados colaborem com a construção de uma + vizinhança, um rizoma. De tal maneira que a técnica e a tecnologia não sejam + impedimento para isso, muito pelo contrário. Sendo a tecnologia também uma + construção social, seus propósitos, sua configuração e os processos nos quais + ela interfere não podem prescindir dos desígnios dos grupos sociais onde ela é + manipulada. + + A internet é um ambiente de cooperação, mas também de apropriação e exploração + de bens públicos. Nós entendemos que ela só se torna essencialmente um espaço + público na medida em que as pessoas possam controlar seus meios de produção e + de acesso, o que não ocorre em espaços corporativos ou governamentais. Por isso + buscamos a criação de espaços públicos, não corporativos e não estatais, e + esperamos que os grupos por nós hospedados colaborem com a construção desses + espaços. + + Durante a construção de tais espaços, realizamos discussões nas quais tentamos + desvendar temas como cultura, sociedade, tecnologia, ativismo, mudanças sociais + entre outros. Tais estudos, quando possível, são disponibilizados publicamente. + + Estudamos as implicações políticas da técnica, desenvolvemos sistemas e + instrumentos a partir de outros valores políticos, além de dialogarmos + politicamente dentro da lógica cíclica da teoria/prática. + + Por isso, uma de nossas propostas é o estabelecimento coletivo de uma rede de + apoio mútuo entre os grupos e indivíduos interessados em partilhar de uma mesma + estrutura para compartilhar seus conhecimentos, atividades desenvolvidas e + estudos realizados, de forma a integrar ativamente esta rede. + + Buscamos, portanto, quebrar com a relação prestador de serviço/cliente, pois + não somos prestadores/as de serviço e nem os grupos/indivíduos por nós + hospedados são nossos clientes, ambos fazemos parte de uma mesma rede de + colaboração onde interesses diversos convergem para o fortalecimento dessa + rede, e quem sabe para que esta forma de organização extrapole a própria rede e + contamine assim as demais esferas que compõe a sociedade. + + Pensando na distribuição do conhecimento, e como incentivo a novos grupos + interessados em manter sua própria plataforma de servidores, buscamos divulgar + o máximo da sistematização de organização. + + E lembre-se: para nós, @ $coletivo não é apenas um sistema de hospedagem ou um + mero provedor de serviços. + + Links de interesse: + + - Estudos disponibilizados: http://wiki.$dominio + - Configurações e procedimentos operacionais: http://padrao.$dominio + + Atenciosamente, + Coletivo $coletivo + +[Versão inglesa](/english/hosting/letter). diff --git a/provedor/hospedagem/carta.mdwn b/provedor/hospedagem/carta.mdwn deleted file mode 100644 index e959ff0..0000000 --- a/provedor/hospedagem/carta.mdwn +++ /dev/null @@ -1,71 +0,0 @@ -[[!meta title="Carta de Hospedagem"]] - -A Carta de Hospedagem não apenas estabelece as intenções e princípios que o Coletivo adota para a hospedagem quanto pode ser utilizada como apresentação aos grupos e indivíduos canditatos a hospedagem. - - Carta de Hospedagem do $coletivo - -------------------------------- - - O $coletivo é parte de uma intersecção de vários grupos que discutem política e - tecnologia de diferentes formas. Partindo disso, trabalhamos com servidores de - internet, voltados para distintas finalidades de cooperação. Sendo assim, nossa - idéia é colaborar com grupos/projetos que participem de experiências de apoio - mútuo e múltiplo. - - O $coletivo é um projeto autônomo, mantido por um coletivo de voluntários e - voluntárias. Um dos nossos principais objetivos é a construção coletiva de - espaços públicos, comuns entre diversos projetos e grupos que tenham a intenção - de fortalecer e estreitar sua convivência. - - Nossa intenção não é oferecer um "serviço de hospedagem", por isso não estamos - dispostos/as a nos aproximar de grupos que busquem este tipo de serviço. - Queremos que os grupos por nós hospedados colaborem com a construção de uma - vizinhança, um rizoma. De tal maneira que a técnica e a tecnologia não sejam - impedimento para isso, muito pelo contrário. Sendo a tecnologia também uma - construção social, seus propósitos, sua configuração e os processos nos quais - ela interfere não podem prescindir dos desígnios dos grupos sociais onde ela é - manipulada. - - A internet é um ambiente de cooperação, mas também de apropriação e exploração - de bens públicos. Nós entendemos que ela só se torna essencialmente um espaço - público na medida em que as pessoas possam controlar seus meios de produção e - de acesso, o que não ocorre em espaços corporativos ou governamentais. Por isso - buscamos a criação de espaços públicos, não corporativos e não estatais, e - esperamos que os grupos por nós hospedados colaborem com a construção desses - espaços. - - Durante a construção de tais espaços, realizamos discussões nas quais tentamos - desvendar temas como cultura, sociedade, tecnologia, ativismo, mudanças sociais - entre outros. Tais estudos, quando possível, são disponibilizados publicamente. - - Estudamos as implicações políticas da técnica, desenvolvemos sistemas e - instrumentos a partir de outros valores políticos, além de dialogarmos - politicamente dentro da lógica cíclica da teoria/prática. - - Por isso, uma de nossas propostas é o estabelecimento coletivo de uma rede de - apoio mútuo entre os grupos e indivíduos interessados em partilhar de uma mesma - estrutura para compartilhar seus conhecimentos, atividades desenvolvidas e - estudos realizados, de forma a integrar ativamente esta rede. - - Buscamos, portanto, quebrar com a relação prestador de serviço/cliente, pois - não somos prestadores/as de serviço e nem os grupos/indivíduos por nós - hospedados são nossos clientes, ambos fazemos parte de uma mesma rede de - colaboração onde interesses diversos convergem para o fortalecimento dessa - rede, e quem sabe para que esta forma de organização extrapole a própria rede e - contamine assim as demais esferas que compõe a sociedade. - - Pensando na distribuição do conhecimento, e como incentivo a novos grupos - interessados em manter sua própria plataforma de servidores, buscamos divulgar - o máximo da sistematização de organização. - - E lembre-se: para nós, @ $coletivo não é apenas um sistema de hospedagem ou um - mero provedor de serviços. - - Links de interesse: - - - Estudos disponibilizados: http://wiki.$dominio - - Configurações e procedimentos operacionais: http://padrao.$dominio - - Atenciosamente, - Coletivo $coletivo - -[Versão inglesa](/english/hosting/letter). diff --git a/provedor/hospedagem/plataforma.md b/provedor/hospedagem/plataforma.md new file mode 100644 index 0000000..993ee1b --- /dev/null +++ b/provedor/hospedagem/plataforma.md @@ -0,0 +1,27 @@ +[[!meta title="Grupo de Trabalho de Hospedagem em $plataforma"]] + +O presente processo estabelece o funcionamento do Grupo de Trabalho de Hospedagem em `$plataforma` (doravante mencionado apenas como '''plataforma'''), consistindo em: + + 1. Manter instalações atualizadas e em funcionamento da plataforma. + 2. Acompanhar avisos de segurança e atualizações dos aplicativos necessários para o funcionamento da plataforma. + 3. Caso não seja realizado automaticamente, efetuar atualizações de segurança em no máximo '''uma semana''' (incluindo finais de semana e feriados) após as mesmas serem disponibilizadas. + 4. Observar e aplicar os critérios de segurança e privacidade existentes para os/as usuários da plataforma. + 5. Caso possível, atender a pedidos do Coletivo pela instalação adicional da plataforma em locais distintos em virtude de aspectos legais e políticos. + 6. Disponibilizar ao Coletivo informações relacionadas aos procedimentos utilizados pelo grupo de trabalho, manutenções e atualizações que foram ou serão efetuadas. + +# Responsabilização + +É de responsabilização do grupo de trabalho a realização das tarefas anteriormente mencionadas. Não é de responsabilidade do presente grupo de trabalho: + + 1. Manter ou entrar em contato com grupos hospedados. + 2. Prestar suporte aos grupos hospedados. + +Não é de responsabilidade do presente grupo de trabalho: + + 1. Pelo funcionamento de cada instância da plataforma. + +Em outras palavras, o presente grupo de trabalho não se responsabiliza pelo uso de cada instância da plataforma, mas sim pelo funcionamento, atualização e auditoria das instalações globais da plataforma, isto é, o grupo de trabalho não lida com instâncias específicas da plataforma mas sim com a infra-estrutura da mesma. + +# Sobre este texto + +O texto deste processo foi redigido utilizando o [Template para Grupo de Trabalho de Hospedagem](/organizacao/misc/plataforma). No caso de alterações que não dizem respeito apenas ao Grupo e que possam enriquecer tal template, favor submetê-las também upstream, isto é, ao texto do template. diff --git a/provedor/hospedagem/plataforma.mdwn b/provedor/hospedagem/plataforma.mdwn deleted file mode 100644 index 993ee1b..0000000 --- a/provedor/hospedagem/plataforma.mdwn +++ /dev/null @@ -1,27 +0,0 @@ -[[!meta title="Grupo de Trabalho de Hospedagem em $plataforma"]] - -O presente processo estabelece o funcionamento do Grupo de Trabalho de Hospedagem em `$plataforma` (doravante mencionado apenas como '''plataforma'''), consistindo em: - - 1. Manter instalações atualizadas e em funcionamento da plataforma. - 2. Acompanhar avisos de segurança e atualizações dos aplicativos necessários para o funcionamento da plataforma. - 3. Caso não seja realizado automaticamente, efetuar atualizações de segurança em no máximo '''uma semana''' (incluindo finais de semana e feriados) após as mesmas serem disponibilizadas. - 4. Observar e aplicar os critérios de segurança e privacidade existentes para os/as usuários da plataforma. - 5. Caso possível, atender a pedidos do Coletivo pela instalação adicional da plataforma em locais distintos em virtude de aspectos legais e políticos. - 6. Disponibilizar ao Coletivo informações relacionadas aos procedimentos utilizados pelo grupo de trabalho, manutenções e atualizações que foram ou serão efetuadas. - -# Responsabilização - -É de responsabilização do grupo de trabalho a realização das tarefas anteriormente mencionadas. Não é de responsabilidade do presente grupo de trabalho: - - 1. Manter ou entrar em contato com grupos hospedados. - 2. Prestar suporte aos grupos hospedados. - -Não é de responsabilidade do presente grupo de trabalho: - - 1. Pelo funcionamento de cada instância da plataforma. - -Em outras palavras, o presente grupo de trabalho não se responsabiliza pelo uso de cada instância da plataforma, mas sim pelo funcionamento, atualização e auditoria das instalações globais da plataforma, isto é, o grupo de trabalho não lida com instâncias específicas da plataforma mas sim com a infra-estrutura da mesma. - -# Sobre este texto - -O texto deste processo foi redigido utilizando o [Template para Grupo de Trabalho de Hospedagem](/organizacao/misc/plataforma). No caso de alterações que não dizem respeito apenas ao Grupo e que possam enriquecer tal template, favor submetê-las também upstream, isto é, ao texto do template. diff --git a/provedor/hospedagem/politica.md b/provedor/hospedagem/politica.md new file mode 100644 index 0000000..f41d224 --- /dev/null +++ b/provedor/hospedagem/politica.md @@ -0,0 +1,47 @@ +[[!meta title="Política de Hospedagem do Coletivo"]] + + Política de Hospedagem do Grupo + ------------------------------- + + 1. O Coletivo reserva para si o poder de hospedar ou deixar de hospedar + qualquer grupo ou indivíduo a partir dos principios e critérios éticos, + politicos e práticos do Coletivo. + + 2. No caso de deixar de hospedar um grupo ou indivíduo, o Coletivo se + compromete a avisar a parte hospedada com antecedência e disponibilizar os + arquivos envolvidos na hospedagem. + + 3. Grupos e indivíduos só são hospedados pelo Coletivo se mostrarem-se + dispostos a uma relação recíproca de troca de conhecimento e atividades. + + 4. Criada a parceria o Coletivo deve ser informado das ações e rumos que cada + projeto toma caso afetem o Coletivo, assim como o Coletivo se compromete a + informar a parte hospedada de qualquer venha a atingi-la. + + 5. Os termos da parceria devem estar claros no sentido de um comprometimento de + ambos os grupos no suporte, manutenção, e desenvolvimento dos sitios e afins + que venham a ser criados por conta da hospedagem. + + 6. A parte hospedada se responsabiliza pelo conteúdo do sitio, não cabendo ao + Coletivo sofrer as consequências jurídicas de conteúdo impróprio ou ilegal. No + entanto, o Coletivo fará o máximo possível para proteger a identidade e a + privacidade da parte hospedada. + + 7. As relações devem se dar de maneira mais transparente possível, não + existindo informação encoberta ou deturpada por ambas as partes. + + 8. As relações tem como finalidade a solidariedade no conhecimento, a + complementariedade nas ações e nas trocas entre os grupos, devendo ser + imprescíndivel maneiras de ensino-aprendizagem mútuos e de políticas que unam + os grupos em prol de uma mudança sócio-política. + + 9. Coletivo se compromete a informar a parte hospedada ao menos em linhas + gerais sobre os critérios e políticas de privacidade e segurança das + plataformas de hospedagem utilizadas pela parte hospedada. + + 10. Hospedagens de movimentos sociais com atividades sensíveis no país são + encaminhadas, quando possível, a plataformas hospedadas no estrangeiro. + + 11. A hospedagem consiste em cooperação e não prestação de serviços. + +[Versão inglesa](/english/hosting/policy). diff --git a/provedor/hospedagem/politica.mdwn b/provedor/hospedagem/politica.mdwn deleted file mode 100644 index f41d224..0000000 --- a/provedor/hospedagem/politica.mdwn +++ /dev/null @@ -1,47 +0,0 @@ -[[!meta title="Política de Hospedagem do Coletivo"]] - - Política de Hospedagem do Grupo - ------------------------------- - - 1. O Coletivo reserva para si o poder de hospedar ou deixar de hospedar - qualquer grupo ou indivíduo a partir dos principios e critérios éticos, - politicos e práticos do Coletivo. - - 2. No caso de deixar de hospedar um grupo ou indivíduo, o Coletivo se - compromete a avisar a parte hospedada com antecedência e disponibilizar os - arquivos envolvidos na hospedagem. - - 3. Grupos e indivíduos só são hospedados pelo Coletivo se mostrarem-se - dispostos a uma relação recíproca de troca de conhecimento e atividades. - - 4. Criada a parceria o Coletivo deve ser informado das ações e rumos que cada - projeto toma caso afetem o Coletivo, assim como o Coletivo se compromete a - informar a parte hospedada de qualquer venha a atingi-la. - - 5. Os termos da parceria devem estar claros no sentido de um comprometimento de - ambos os grupos no suporte, manutenção, e desenvolvimento dos sitios e afins - que venham a ser criados por conta da hospedagem. - - 6. A parte hospedada se responsabiliza pelo conteúdo do sitio, não cabendo ao - Coletivo sofrer as consequências jurídicas de conteúdo impróprio ou ilegal. No - entanto, o Coletivo fará o máximo possível para proteger a identidade e a - privacidade da parte hospedada. - - 7. As relações devem se dar de maneira mais transparente possível, não - existindo informação encoberta ou deturpada por ambas as partes. - - 8. As relações tem como finalidade a solidariedade no conhecimento, a - complementariedade nas ações e nas trocas entre os grupos, devendo ser - imprescíndivel maneiras de ensino-aprendizagem mútuos e de políticas que unam - os grupos em prol de uma mudança sócio-política. - - 9. Coletivo se compromete a informar a parte hospedada ao menos em linhas - gerais sobre os critérios e políticas de privacidade e segurança das - plataformas de hospedagem utilizadas pela parte hospedada. - - 10. Hospedagens de movimentos sociais com atividades sensíveis no país são - encaminhadas, quando possível, a plataformas hospedadas no estrangeiro. - - 11. A hospedagem consiste em cooperação e não prestação de serviços. - -[Versão inglesa](/english/hosting/policy). diff --git a/provedor/hospedagem/recusa.md b/provedor/hospedagem/recusa.md new file mode 100644 index 0000000..cf3eb07 --- /dev/null +++ b/provedor/hospedagem/recusa.md @@ -0,0 +1,26 @@ +[[!meta title="Modelo de carta de recusa de hospedagem"]] + +Este é um modelo de carta para recusa de hospedagem, no caso de projetos que não concordamos. Para evitar mal entendidos, é importante termos um carta ponderada e bem esclarecedora. + + Olá $requisitante, + + Infelizmente não poderemos hospedar o projeto que você requisitou porque: + + - Consideramos que ele não se enquadra nos princípios éticos que adotamos[1]. + + - E/ou então consideramos que ele se enquadra nos tipos de projetos com os + quais mantemos uma postura crítica[2]. + + Acreditamos que não exista uma única forma de luta e muito menos que a nossos + princípios éticos e as nossas críticas representem o ponto de vista "correto". + Nosso ponto de vista apenas representa as conclusões que chegamos após muita + discussão. Tentamos apenas nos manter coerentes com o que acreditamos e é por + isso que não podemos efetuar a sua requisição. + + Não queremos de modo algum que isso signifique que estamos desmerecendo a + atuação do seu projeto ou as coisas que você acredita. + + [1] Vide http://encontro.sarava.org/Principal/ConjuntoDePrincipiosEticos + [2] Vide http://wiki.$dominio + +[Versão inglesa](/english/hosting/refusal). diff --git a/provedor/hospedagem/recusa.mdwn b/provedor/hospedagem/recusa.mdwn deleted file mode 100644 index cf3eb07..0000000 --- a/provedor/hospedagem/recusa.mdwn +++ /dev/null @@ -1,26 +0,0 @@ -[[!meta title="Modelo de carta de recusa de hospedagem"]] - -Este é um modelo de carta para recusa de hospedagem, no caso de projetos que não concordamos. Para evitar mal entendidos, é importante termos um carta ponderada e bem esclarecedora. - - Olá $requisitante, - - Infelizmente não poderemos hospedar o projeto que você requisitou porque: - - - Consideramos que ele não se enquadra nos princípios éticos que adotamos[1]. - - - E/ou então consideramos que ele se enquadra nos tipos de projetos com os - quais mantemos uma postura crítica[2]. - - Acreditamos que não exista uma única forma de luta e muito menos que a nossos - princípios éticos e as nossas críticas representem o ponto de vista "correto". - Nosso ponto de vista apenas representa as conclusões que chegamos após muita - discussão. Tentamos apenas nos manter coerentes com o que acreditamos e é por - isso que não podemos efetuar a sua requisição. - - Não queremos de modo algum que isso signifique que estamos desmerecendo a - atuação do seu projeto ou as coisas que você acredita. - - [1] Vide http://encontro.sarava.org/Principal/ConjuntoDePrincipiosEticos - [2] Vide http://wiki.$dominio - -[Versão inglesa](/english/hosting/refusal). diff --git a/provedor/hospedagem/termo.md b/provedor/hospedagem/termo.md new file mode 100644 index 0000000..62ecd7e --- /dev/null +++ b/provedor/hospedagem/termo.md @@ -0,0 +1,105 @@ +[[!meta title="Termo de Comprometimento de Hospedagem"]] + + Olá :) + + Termo de Comprometimento de Hospedagem + -------------------------------------- + + Discutimos e estamos de acordo em oferecer hospedagem conforme sua requisição. + Agora, para que possamos efetivamente manter a hospedagem, é preciso: + + 1. Apresentarmos qual é o nosso comprometimento com relação a essa hospedagem. + 2. Que você e/ou seu grupo concordem com o presente termo de compromisso e com + a nossa Política de Hospedagem. + + Estes são os termos de compromisso mútuo, onde explicitamos qual será nosso + comprometimento com a hospedagem em questão pelo qual a parte hospedada precisa + concordar para que seja possível manter tal relação. + + Caso você concorde com os termos desta carta e aceite nossa Política de + Hospedagem, basta responder afirmativamente que sua hospedagem será iniciada + logo que possível. :) + + Nosso comprometimento + --------------------- + + Por essa hospedagem, nos comprometemos a manter a hospedagem em funcionamento. + A manutenção da hospedagem ocorre através de trabalho voluntário e responsável. + + A infra-estrutura utilizada para hospedagem é estável, porém sujeita + a eventuais intempéries da rede ou mesmo a problemas mais graves. + + Por isso, a hospedagem pode ficar fora do ar de vez em quando. Estamos sempre + atentos e prezamos pela segurança e integridade dos dados hospedados. Porém, + por diversos motivos, não podemos garantir a total disponibilidade ou mesmo a + eternidade destes dados. + + Nos comprometemos, na medida do possível, a manter cópias de segurança dos + dados contidos em nossa infra-estrutura. No entanto, pedimos a você que + mantenha, também na medida do possível, cópias de seus arquivos. + + Nosso grupo é formado por pessoas que desempenham uma série de tarefas. As + atividades mais importantes e cruciais, como a hospedagem, dependem de várias + tarefas e cada uma delas está associada a um grupo de trabalho de pessoas + responsáveis pela sua realização. + + Mesmo assim, pessoas podem deixar de trabalhar num dado grupo de trabalho e + eventualmente alguma tarefa não possa mais ser realizada por falta de um mínimo + de pessoas responsáveis por ela. + + É nesse sentido que garantimos o funcionamento e a realização da hospedagem: de + acordo com a força de trabalho disponível no nosso grupo. Por isso, é possível + que, no futuro, aconteça de termos que encerrar a hospedagem numa dada + plataforma. Mas, se o fizermos, garantimos que não será da noite para o dia e + daremos tempo suficiente para que você e seu projeto possam migrar seus dados + para outro local. + + Nos comprometemos também a informar, mediante solicitação, nossos procedimentos + de acordo com nossa política de transparência. Tais procedimentos variam desde + características de privacidade e segurança das plataformas utilizadas como + também da situação do nosso coletivo. + + Como nossos procedimentos podem variar ao longo do tempo, convém a você nos + solicitar as descrições de procedimentos conforme julgar necessário. + + Temos nossas limitações mas na medida do possível manteremos as coisas + funcionando. :) + + Seu comprometimento + ------------------- + + Esperamos de você e do seu projeto que use o recurso oferecido com sabedoria. + Não peça sítios e ferramentas que você deixará abandonadas e, caso você instale + seu próprio programa, tenha a responsabilidade de deixá-lo atualizado, uma vez + que brechas de segurança no seu espaço podem comprometer outros projetos + hospedados. + + Não se esqueça que a manutenção de um sistema de múltiplos projetos é bastante + trabalhosa e dificil de manter segura e por isso pedimos a colaboração de todo + mundo. Se puder nos comunicar quando for instalar algum software no seu espaço, + ficaríamos muito agradecidos/as :) + + Interfaces de comunicação e compartilhamento + -------------------------------------------- + + Um possível espaço de interação entre os projetos é a Lista da Vizinhança[1] + (inscrição apenas para emails seguros, entre em contato para detalhes). + Cultive-a! Ao hospedarmos grupos e indivíduos, torcemos para que estes também + tornem-se responsáveis por zelar por tais espaços de convivência. + + Nossa vizinhança é também um local de articulação de rede, onde todos os grupos + e indivíduos que compartilham da estrutura por nós mantida se comunicam. + + Se os temas e estudos com os quais nos preocupamos também os/as inspiram, nós + os/as convidamos a participar dessas discussões. Para evitar a centralização + das discussões, propomos que vocês os discutam coletivamente, em seus projetos + e/ou grupos, tornando público os processos e resultados de tais discussões. + Para nós é fundamental tentar construir uma metodologia que possibilite a + disseminação pública de tais discussões. + + [1] $endereco_da_lista_da_vizinhanca + + Em solidariedade, + Coletivo $grupo + +[Versão inglesa](/english/hosting/terms). diff --git a/provedor/hospedagem/termo.mdwn b/provedor/hospedagem/termo.mdwn deleted file mode 100644 index 62ecd7e..0000000 --- a/provedor/hospedagem/termo.mdwn +++ /dev/null @@ -1,105 +0,0 @@ -[[!meta title="Termo de Comprometimento de Hospedagem"]] - - Olá :) - - Termo de Comprometimento de Hospedagem - -------------------------------------- - - Discutimos e estamos de acordo em oferecer hospedagem conforme sua requisição. - Agora, para que possamos efetivamente manter a hospedagem, é preciso: - - 1. Apresentarmos qual é o nosso comprometimento com relação a essa hospedagem. - 2. Que você e/ou seu grupo concordem com o presente termo de compromisso e com - a nossa Política de Hospedagem. - - Estes são os termos de compromisso mútuo, onde explicitamos qual será nosso - comprometimento com a hospedagem em questão pelo qual a parte hospedada precisa - concordar para que seja possível manter tal relação. - - Caso você concorde com os termos desta carta e aceite nossa Política de - Hospedagem, basta responder afirmativamente que sua hospedagem será iniciada - logo que possível. :) - - Nosso comprometimento - --------------------- - - Por essa hospedagem, nos comprometemos a manter a hospedagem em funcionamento. - A manutenção da hospedagem ocorre através de trabalho voluntário e responsável. - - A infra-estrutura utilizada para hospedagem é estável, porém sujeita - a eventuais intempéries da rede ou mesmo a problemas mais graves. - - Por isso, a hospedagem pode ficar fora do ar de vez em quando. Estamos sempre - atentos e prezamos pela segurança e integridade dos dados hospedados. Porém, - por diversos motivos, não podemos garantir a total disponibilidade ou mesmo a - eternidade destes dados. - - Nos comprometemos, na medida do possível, a manter cópias de segurança dos - dados contidos em nossa infra-estrutura. No entanto, pedimos a você que - mantenha, também na medida do possível, cópias de seus arquivos. - - Nosso grupo é formado por pessoas que desempenham uma série de tarefas. As - atividades mais importantes e cruciais, como a hospedagem, dependem de várias - tarefas e cada uma delas está associada a um grupo de trabalho de pessoas - responsáveis pela sua realização. - - Mesmo assim, pessoas podem deixar de trabalhar num dado grupo de trabalho e - eventualmente alguma tarefa não possa mais ser realizada por falta de um mínimo - de pessoas responsáveis por ela. - - É nesse sentido que garantimos o funcionamento e a realização da hospedagem: de - acordo com a força de trabalho disponível no nosso grupo. Por isso, é possível - que, no futuro, aconteça de termos que encerrar a hospedagem numa dada - plataforma. Mas, se o fizermos, garantimos que não será da noite para o dia e - daremos tempo suficiente para que você e seu projeto possam migrar seus dados - para outro local. - - Nos comprometemos também a informar, mediante solicitação, nossos procedimentos - de acordo com nossa política de transparência. Tais procedimentos variam desde - características de privacidade e segurança das plataformas utilizadas como - também da situação do nosso coletivo. - - Como nossos procedimentos podem variar ao longo do tempo, convém a você nos - solicitar as descrições de procedimentos conforme julgar necessário. - - Temos nossas limitações mas na medida do possível manteremos as coisas - funcionando. :) - - Seu comprometimento - ------------------- - - Esperamos de você e do seu projeto que use o recurso oferecido com sabedoria. - Não peça sítios e ferramentas que você deixará abandonadas e, caso você instale - seu próprio programa, tenha a responsabilidade de deixá-lo atualizado, uma vez - que brechas de segurança no seu espaço podem comprometer outros projetos - hospedados. - - Não se esqueça que a manutenção de um sistema de múltiplos projetos é bastante - trabalhosa e dificil de manter segura e por isso pedimos a colaboração de todo - mundo. Se puder nos comunicar quando for instalar algum software no seu espaço, - ficaríamos muito agradecidos/as :) - - Interfaces de comunicação e compartilhamento - -------------------------------------------- - - Um possível espaço de interação entre os projetos é a Lista da Vizinhança[1] - (inscrição apenas para emails seguros, entre em contato para detalhes). - Cultive-a! Ao hospedarmos grupos e indivíduos, torcemos para que estes também - tornem-se responsáveis por zelar por tais espaços de convivência. - - Nossa vizinhança é também um local de articulação de rede, onde todos os grupos - e indivíduos que compartilham da estrutura por nós mantida se comunicam. - - Se os temas e estudos com os quais nos preocupamos também os/as inspiram, nós - os/as convidamos a participar dessas discussões. Para evitar a centralização - das discussões, propomos que vocês os discutam coletivamente, em seus projetos - e/ou grupos, tornando público os processos e resultados de tais discussões. - Para nós é fundamental tentar construir uma metodologia que possibilite a - disseminação pública de tais discussões. - - [1] $endereco_da_lista_da_vizinhanca - - Em solidariedade, - Coletivo $grupo - -[Versão inglesa](/english/hosting/terms). diff --git a/provedor/servidor.md b/provedor/servidor.md new file mode 100644 index 0000000..e8dfa76 --- /dev/null +++ b/provedor/servidor.md @@ -0,0 +1,49 @@ +[[!meta title="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. diff --git a/provedor/servidor.mdwn b/provedor/servidor.mdwn deleted file mode 100644 index e8dfa76..0000000 --- a/provedor/servidor.mdwn +++ /dev/null @@ -1,49 +0,0 @@ -[[!meta title="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. diff --git a/provedor/sistemas.md b/provedor/sistemas.md new file mode 100644 index 0000000..dc1b1a3 --- /dev/null +++ b/provedor/sistemas.md @@ -0,0 +1,41 @@ +[[!meta title="Configuração de sistemas padronizada e centralizada"]] + +[[!map pages="page(organizacao/provedor/sistemas*)" show="title"]] + +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/provedor/sistemas.mdwn b/provedor/sistemas.mdwn deleted file mode 100644 index dc1b1a3..0000000 --- a/provedor/sistemas.mdwn +++ /dev/null @@ -1,41 +0,0 @@ -[[!meta title="Configuração de sistemas padronizada e centralizada"]] - -[[!map pages="page(organizacao/provedor/sistemas*)" show="title"]] - -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/provedor/sistemas/dns.md b/provedor/sistemas/dns.md new file mode 100644 index 0000000..76a76d0 --- /dev/null +++ b/provedor/sistemas/dns.md @@ -0,0 +1,16 @@ +[[!meta title="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/provedor/sistemas/dns.mdwn b/provedor/sistemas/dns.mdwn deleted file mode 100644 index 76a76d0..0000000 --- a/provedor/sistemas/dns.mdwn +++ /dev/null @@ -1,16 +0,0 @@ -[[!meta title="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/provedor/sistemas/dominios.md b/provedor/sistemas/dominios.md new file mode 100644 index 0000000..98d2ca8 --- /dev/null +++ b/provedor/sistemas/dominios.md @@ -0,0 +1,26 @@ +[[!meta title="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/provedor/sistemas/dominios.mdwn b/provedor/sistemas/dominios.mdwn deleted file mode 100644 index 98d2ca8..0000000 --- a/provedor/sistemas/dominios.mdwn +++ /dev/null @@ -1,26 +0,0 @@ -[[!meta title="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/rede.md b/rede.md new file mode 100644 index 0000000..a5aafa6 --- /dev/null +++ b/rede.md @@ -0,0 +1,82 @@ +[[!meta title="Princípios e processo da rede $rede"]] + +Originalmente [Princípios e processo da rede `$rede`](https://rectech.sarava.org/publico/processo). + +Sobre +----- + +A rede `$rede` é um fórum de coletivos técnicos anticapitalistas, antifascistas, +antisexistas, antihomofóbicos e antiracistas e que rejeitam qualquer forma +de dominação e discriminação social. + +O objetivo do fórum é possibilitar o intercâmbio, a ajuda mútua e a cooperação +entre os coletivos participantes e também uma interface pública de debates. + +Assim, `$rede` não é um coletivo mas sim uma rede. + +Como funciona +------------- + +A rede por padrão permanece em estado de dormência até ser ativada, quando por +exemplo algum(s) coletivo(s) sugere(m) uma atividade, encontro ou cooperação. + +Processo de participação +------------------------ + +A participação na rede `$rede` é restrita a coletivos que atendam os critérios de +afinidade, confiabilidade e comprometimento com a rede. Novos coletivos podem +entrar na rede após processo de decisão favorável e caso eles concordem +com a presente carta. + +Uma vez dentro da rede, os coletivos podem indicar quais dos seus membros devem +ser inscritos ou retirados das plataformas de comunicação da rede `$rede`. + +Cada indivíduo deve, ao ingressar nas plataformas de comunicação da rede `$rede`, +se apresentar e afirmar que atuará de forma construtiva, caso contrário estará +passível de remoção. + +Processo de decisão +------------------- + +Nenhuma pessoa ou grupo pode tomar decisões que afetem a autonomia da rede sem +consultá-la anteriormente e obter um consenso positivo. + +As decisões na rede são baseadas em propostas que devem ser enviadas para a +lista de discussão fechada da rede. + +O prazo mínimo de decisão é de duas semanas passível de adiamento e as decisões +são atingidas por consenso. Caso um coletivo não se manifeste sobre uma proposta +ele será considerado como em concordância com a proposta enviada. + +Privacidade +----------- + +A rede `$rede` é semipública, isto é, parte de sua comunicação e organização é +restrita aos coletivos participantes, enquanto que outra parte é pública e aberta +a qualquer grupo ou pessoa. + +Informações que circulem em instâncias de comunicação privadas precisam de +autorização para serem disponibilizadas em meios públicos (desclassificação). + +É uma escolha de cada participante se manter como membro privado. + +Interfaces de comunicação +------------------------- + +A rede `$rede` possui as seguintes interfaces de comunicação: + + - Lista de discussão fechada com arquivo restrito a participantes. + - Lista de anúncios moderada com inscrição e arquivos abertos. + - Plataforma web colaborativa. + +Tais interfaces são hospedadas por coletivos participantes ou afins e seu +acesso e continuidade são cruciais para a manutenção da memória da rede. +Assim, é imprescindível que a rede disponha de backups dessas plataformas +sempre que necessário. + +Sobre este texto +---------------- + +Este processo foi baseado no "Template para Carta de princípios e processo de +redes v1.0". Licença deste documento: GNU Free Documentation License: +http://www.gnu.org/copyleft/fdl.html diff --git a/rede.mdwn b/rede.mdwn deleted file mode 100644 index a5aafa6..0000000 --- a/rede.mdwn +++ /dev/null @@ -1,82 +0,0 @@ -[[!meta title="Princípios e processo da rede $rede"]] - -Originalmente [Princípios e processo da rede `$rede`](https://rectech.sarava.org/publico/processo). - -Sobre ------ - -A rede `$rede` é um fórum de coletivos técnicos anticapitalistas, antifascistas, -antisexistas, antihomofóbicos e antiracistas e que rejeitam qualquer forma -de dominação e discriminação social. - -O objetivo do fórum é possibilitar o intercâmbio, a ajuda mútua e a cooperação -entre os coletivos participantes e também uma interface pública de debates. - -Assim, `$rede` não é um coletivo mas sim uma rede. - -Como funciona -------------- - -A rede por padrão permanece em estado de dormência até ser ativada, quando por -exemplo algum(s) coletivo(s) sugere(m) uma atividade, encontro ou cooperação. - -Processo de participação ------------------------- - -A participação na rede `$rede` é restrita a coletivos que atendam os critérios de -afinidade, confiabilidade e comprometimento com a rede. Novos coletivos podem -entrar na rede após processo de decisão favorável e caso eles concordem -com a presente carta. - -Uma vez dentro da rede, os coletivos podem indicar quais dos seus membros devem -ser inscritos ou retirados das plataformas de comunicação da rede `$rede`. - -Cada indivíduo deve, ao ingressar nas plataformas de comunicação da rede `$rede`, -se apresentar e afirmar que atuará de forma construtiva, caso contrário estará -passível de remoção. - -Processo de decisão -------------------- - -Nenhuma pessoa ou grupo pode tomar decisões que afetem a autonomia da rede sem -consultá-la anteriormente e obter um consenso positivo. - -As decisões na rede são baseadas em propostas que devem ser enviadas para a -lista de discussão fechada da rede. - -O prazo mínimo de decisão é de duas semanas passível de adiamento e as decisões -são atingidas por consenso. Caso um coletivo não se manifeste sobre uma proposta -ele será considerado como em concordância com a proposta enviada. - -Privacidade ------------ - -A rede `$rede` é semipública, isto é, parte de sua comunicação e organização é -restrita aos coletivos participantes, enquanto que outra parte é pública e aberta -a qualquer grupo ou pessoa. - -Informações que circulem em instâncias de comunicação privadas precisam de -autorização para serem disponibilizadas em meios públicos (desclassificação). - -É uma escolha de cada participante se manter como membro privado. - -Interfaces de comunicação -------------------------- - -A rede `$rede` possui as seguintes interfaces de comunicação: - - - Lista de discussão fechada com arquivo restrito a participantes. - - Lista de anúncios moderada com inscrição e arquivos abertos. - - Plataforma web colaborativa. - -Tais interfaces são hospedadas por coletivos participantes ou afins e seu -acesso e continuidade são cruciais para a manutenção da memória da rede. -Assim, é imprescindível que a rede disponha de backups dessas plataformas -sempre que necessário. - -Sobre este texto ----------------- - -Este processo foi baseado no "Template para Carta de princípios e processo de -redes v1.0". Licença deste documento: GNU Free Documentation License: -http://www.gnu.org/copyleft/fdl.html diff --git a/todo.md b/todo.md new file mode 100644 index 0000000..ded1d3b --- /dev/null +++ b/todo.md @@ -0,0 +1,3 @@ +[[!meta title="Tarefas"]] + +Lista de tarefas deste projeto. diff --git a/todo.mdwn b/todo.mdwn deleted file mode 100644 index ded1d3b..0000000 --- a/todo.mdwn +++ /dev/null @@ -1,3 +0,0 @@ -[[!meta title="Tarefas"]] - -Lista de tarefas deste projeto. diff --git a/travel.md b/travel.md new file mode 100644 index 0000000..d86e9a8 --- /dev/null +++ b/travel.md @@ -0,0 +1,16 @@ +[[!meta title="Viagens"]] + +Templates para viagens. Veja também [The Travel Lite Strategy](https://blog.fluxo.info/travel/lite). + +[[!map pages="page(travel*)" show="title"]] + +## Dicas + +* Para não perder coisas durante as viagens, mantê-las sempre agrupadas num mesmo local. +* Mantenha sempre sua mala arrumada, pronta para saídas inesperadas. +* Proteja seus pertences, não vacile! +* Roupas: + * Para lavar a pouca roupa, [use Vodca](http://www.tiosolid.com/vodka-as-10-outras-utilidades-alm-de-beber). + * Para minimizar a lavagem de roupas, deixe-as tomando ar após o uso. + * Camisetas podem ser penduradas de cabeça pra baixo para que o ar circule na região das axilas, evitando a formação de colônias de bactérias. + * Pendurar camisas e camisetas do avesso em cabides. diff --git a/travel.mdwn b/travel.mdwn deleted file mode 100644 index d86e9a8..0000000 --- a/travel.mdwn +++ /dev/null @@ -1,16 +0,0 @@ -[[!meta title="Viagens"]] - -Templates para viagens. Veja também [The Travel Lite Strategy](https://blog.fluxo.info/travel/lite). - -[[!map pages="page(travel*)" show="title"]] - -## Dicas - -* Para não perder coisas durante as viagens, mantê-las sempre agrupadas num mesmo local. -* Mantenha sempre sua mala arrumada, pronta para saídas inesperadas. -* Proteja seus pertences, não vacile! -* Roupas: - * Para lavar a pouca roupa, [use Vodca](http://www.tiosolid.com/vodka-as-10-outras-utilidades-alm-de-beber). - * Para minimizar a lavagem de roupas, deixe-as tomando ar após o uso. - * Camisetas podem ser penduradas de cabeça pra baixo para que o ar circule na região das axilas, evitando a formação de colônias de bactérias. - * Pendurar camisas e camisetas do avesso em cabides. diff --git a/travel/checklist.md b/travel/checklist.md new file mode 100644 index 0000000..82e4c55 --- /dev/null +++ b/travel/checklist.md @@ -0,0 +1,5 @@ +[[!meta title="Checklist"]] + +Checklists de viagem. + +[[!map pages="page(travel/checklist*)" show="title"]] diff --git a/travel/checklist.mdwn b/travel/checklist.mdwn deleted file mode 100644 index 82e4c55..0000000 --- a/travel/checklist.mdwn +++ /dev/null @@ -1,5 +0,0 @@ -[[!meta title="Checklist"]] - -Checklists de viagem. - -[[!map pages="page(travel/checklist*)" show="title"]] diff --git a/travel/checklist/basico.md b/travel/checklist/basico.md new file mode 100644 index 0000000..4c1aacd --- /dev/null +++ b/travel/checklist/basico.md @@ -0,0 +1,16 @@ +[[!meta title="Checklist básico"]] + +Micro kit de ferramentas +------------------------ + +* Clipes de papel. +* Lâmina de barbear. +* Elásticos. +* Isqueiro? + +Kit básico +---------- + +* EPI. +* Escova de dentes. +* Fio dental. diff --git a/travel/checklist/basico.mdwn b/travel/checklist/basico.mdwn deleted file mode 100644 index 4c1aacd..0000000 --- a/travel/checklist/basico.mdwn +++ /dev/null @@ -1,16 +0,0 @@ -[[!meta title="Checklist básico"]] - -Micro kit de ferramentas ------------------------- - -* Clipes de papel. -* Lâmina de barbear. -* Elásticos. -* Isqueiro? - -Kit básico ----------- - -* EPI. -* Escova de dentes. -* Fio dental. diff --git a/travel/checklist/carteira.md b/travel/checklist/carteira.md new file mode 100644 index 0000000..91ff6fa --- /dev/null +++ b/travel/checklist/carteira.md @@ -0,0 +1,13 @@ +[[!meta title="Carteira cypherpunk"]] + +* Band-aid. +* Kit reparos de bike. +* Limpador interdental plástico. +* Telefones de emergência. +* Memórias e adaptador, incluindo [Bootless](https://bootless.fluxo.info) e [Tails](https://tails.boum.org). +* Fingerprints digitais. +* Saco zip para coletas. +* Régua de papel (mini fita métrica). +* Palheta. +* [Ficha de saúde](/pessoal/saude). +* Modelo de Habeas corpus. diff --git a/travel/checklist/carteira.mdwn b/travel/checklist/carteira.mdwn deleted file mode 100644 index 91ff6fa..0000000 --- a/travel/checklist/carteira.mdwn +++ /dev/null @@ -1,13 +0,0 @@ -[[!meta title="Carteira cypherpunk"]] - -* Band-aid. -* Kit reparos de bike. -* Limpador interdental plástico. -* Telefones de emergência. -* Memórias e adaptador, incluindo [Bootless](https://bootless.fluxo.info) e [Tails](https://tails.boum.org). -* Fingerprints digitais. -* Saco zip para coletas. -* Régua de papel (mini fita métrica). -* Palheta. -* [Ficha de saúde](/pessoal/saude). -* Modelo de Habeas corpus. diff --git a/travel/checklist/completa.md b/travel/checklist/completa.md new file mode 100644 index 0000000..d7afe6e --- /dev/null +++ b/travel/checklist/completa.md @@ -0,0 +1,21 @@ +[[!meta title="Checklist Completa para Viagens"]] + +* Itens básicos da Checklist Mínima. +* Máquina fotográfica, capa, cabo, bateria sobressalente, carregador, memória sobressalente e adaptador de memória +* Mala de higiene: + * Protetor solar +* Canivete +* Saco de dormir +* Roupas (1 semana) + * Camisetas + * Calças + * Blusas + * Camisa social + * Roupas íntimas + * Meias + * Pisantes + * Cintos + * Verão: + * Bermudas + * Havaianas + * Calção de banho diff --git a/travel/checklist/completa.mdwn b/travel/checklist/completa.mdwn deleted file mode 100644 index d7afe6e..0000000 --- a/travel/checklist/completa.mdwn +++ /dev/null @@ -1,21 +0,0 @@ -[[!meta title="Checklist Completa para Viagens"]] - -* Itens básicos da Checklist Mínima. -* Máquina fotográfica, capa, cabo, bateria sobressalente, carregador, memória sobressalente e adaptador de memória -* Mala de higiene: - * Protetor solar -* Canivete -* Saco de dormir -* Roupas (1 semana) - * Camisetas - * Calças - * Blusas - * Camisa social - * Roupas íntimas - * Meias - * Pisantes - * Cintos - * Verão: - * Bermudas - * Havaianas - * Calção de banho diff --git a/travel/checklist/expedicao.md b/travel/checklist/expedicao.md new file mode 100644 index 0000000..db46f79 --- /dev/null +++ b/travel/checklist/expedicao.md @@ -0,0 +1,23 @@ +[[!meta title="Checklist para Expedições"]] + +Equipamentos pequenos e úteis para expedições científicas: + +* Itens da checklist de fuga. +* Placa solar carregadora ou manivela. +* Kit médico. +* Ração sem cozimento. +* Saco zip para amostras. +* Sacos para coleta de rejeitos. +* Saco impermeável. +* Serra de dedo/mão circular de sobrevivência em aço. +* Pederneira, apito, bússola, isqueiro. +* Purificador de água. +* Tela mosquiteira e repelente de insetos. +* Saco de dormir tipo múmia/sarcófago e capa impermeável. +* Isolante térmico. +* Rede leve. +* Botas. +* Rádio. +* Relógio. +* Espelho. +* Tesoura. diff --git a/travel/checklist/expedicao.mdwn b/travel/checklist/expedicao.mdwn deleted file mode 100644 index db46f79..0000000 --- a/travel/checklist/expedicao.mdwn +++ /dev/null @@ -1,23 +0,0 @@ -[[!meta title="Checklist para Expedições"]] - -Equipamentos pequenos e úteis para expedições científicas: - -* Itens da checklist de fuga. -* Placa solar carregadora ou manivela. -* Kit médico. -* Ração sem cozimento. -* Saco zip para amostras. -* Sacos para coleta de rejeitos. -* Saco impermeável. -* Serra de dedo/mão circular de sobrevivência em aço. -* Pederneira, apito, bússola, isqueiro. -* Purificador de água. -* Tela mosquiteira e repelente de insetos. -* Saco de dormir tipo múmia/sarcófago e capa impermeável. -* Isolante térmico. -* Rede leve. -* Botas. -* Rádio. -* Relógio. -* Espelho. -* Tesoura. diff --git a/travel/checklist/fuga.md b/travel/checklist/fuga.md new file mode 100644 index 0000000..880ef28 --- /dev/null +++ b/travel/checklist/fuga.md @@ -0,0 +1,8 @@ +[[!meta title="Mala de fuga"]] + +Incluindo: + +* Água. +* Troca de roupa. +* Papel higiênico. +* Álcool potável (para chapar, esquentar, relaxar e lavar a roupa)? diff --git a/travel/checklist/fuga.mdwn b/travel/checklist/fuga.mdwn deleted file mode 100644 index 880ef28..0000000 --- a/travel/checklist/fuga.mdwn +++ /dev/null @@ -1,8 +0,0 @@ -[[!meta title="Mala de fuga"]] - -Incluindo: - -* Água. -* Troca de roupa. -* Papel higiênico. -* Álcool potável (para chapar, esquentar, relaxar e lavar a roupa)? diff --git a/travel/checklist/minima.md b/travel/checklist/minima.md new file mode 100644 index 0000000..cd5eca2 --- /dev/null +++ b/travel/checklist/minima.md @@ -0,0 +1,46 @@ +[[!meta title="Checklist Mínima para Viagens"]] + +* Documentos + * Micro-pasta para panfletos, papéis e documentos + * Passaporte(s) (com capa) + * Passagens + * Saldo/extrato bancário + * Seguro saúde + * Cartas de convite e/ou reservas de hospedagem + * Carteira de alberguista + * Carteira de motorista nacional e internacional + * Registro de equipamentos na Receita Federal + * Lista de Contatos. + * Esta checklist. +* Finanças + * Dinheiro e comprovantes de câmbio + * Cartão de crédito + * Travel money +* Equipos + * Óculos (de sol e de leitura) + * Caderno de notas, grafite, lapiseira + * Cartões de visita + * Smartphone, carregador USB, cabo USB e fones de ouvido + * Laptop + * Tablet + * Playlist / músicas! +* Micro-mala de higiene: + * Remédios. + * Mini-shampoo, mini-condicionador e mini-sabonete + * Pasta de dentes, escova e fio dental + * Mini-[pedra de allumbre](https://es.wikipedia.org/wiki/Alumbre). +* Roupas (1 semana) + * Toalha atlética + * Capa de chuva + * 3 roupas íntimas + * 2 pares de meias + * Verão: + * 2 camisetas dry fit + * Inverno: + * Palmilhas isolantes + * 2 conjuntos de segunda pele + * Jaco + * [Polar](http://en.wikipedia.org/wiki/Polar_fleece Fleece). + * Par de luvas + * Cachecol + * Gorro diff --git a/travel/checklist/minima.mdwn b/travel/checklist/minima.mdwn deleted file mode 100644 index cd5eca2..0000000 --- a/travel/checklist/minima.mdwn +++ /dev/null @@ -1,46 +0,0 @@ -[[!meta title="Checklist Mínima para Viagens"]] - -* Documentos - * Micro-pasta para panfletos, papéis e documentos - * Passaporte(s) (com capa) - * Passagens - * Saldo/extrato bancário - * Seguro saúde - * Cartas de convite e/ou reservas de hospedagem - * Carteira de alberguista - * Carteira de motorista nacional e internacional - * Registro de equipamentos na Receita Federal - * Lista de Contatos. - * Esta checklist. -* Finanças - * Dinheiro e comprovantes de câmbio - * Cartão de crédito - * Travel money -* Equipos - * Óculos (de sol e de leitura) - * Caderno de notas, grafite, lapiseira - * Cartões de visita - * Smartphone, carregador USB, cabo USB e fones de ouvido - * Laptop - * Tablet - * Playlist / músicas! -* Micro-mala de higiene: - * Remédios. - * Mini-shampoo, mini-condicionador e mini-sabonete - * Pasta de dentes, escova e fio dental - * Mini-[pedra de allumbre](https://es.wikipedia.org/wiki/Alumbre). -* Roupas (1 semana) - * Toalha atlética - * Capa de chuva - * 3 roupas íntimas - * 2 pares de meias - * Verão: - * 2 camisetas dry fit - * Inverno: - * Palmilhas isolantes - * 2 conjuntos de segunda pele - * Jaco - * [Polar](http://en.wikipedia.org/wiki/Polar_fleece Fleece). - * Par de luvas - * Cachecol - * Gorro diff --git a/travel/checklist/urbano.md b/travel/checklist/urbano.md new file mode 100644 index 0000000..1576d84 --- /dev/null +++ b/travel/checklist/urbano.md @@ -0,0 +1,24 @@ +[[!meta title="Urbenauta"]] + +Kit verão +--------- + +* Camiseta dry fit ou sem camisa. +* Calção de banho. +* Sacola zip grande. +* Cycling overshoes. + +Kit inverno +----------- + +* Kit verão. +* Corta vento. +* Manteiga de cacau. + +Mochila +------- + +* Kit básico. +* Capa de chuva para mochila. +* Kit chuva verão ou inverno. +* Sacola dobrável para compras. diff --git a/travel/checklist/urbano.mdwn b/travel/checklist/urbano.mdwn deleted file mode 100644 index 1576d84..0000000 --- a/travel/checklist/urbano.mdwn +++ /dev/null @@ -1,24 +0,0 @@ -[[!meta title="Urbenauta"]] - -Kit verão ---------- - -* Camiseta dry fit ou sem camisa. -* Calção de banho. -* Sacola zip grande. -* Cycling overshoes. - -Kit inverno ------------ - -* Kit verão. -* Corta vento. -* Manteiga de cacau. - -Mochila -------- - -* Kit básico. -* Capa de chuva para mochila. -* Kit chuva verão ou inverno. -* Sacola dobrável para compras. diff --git a/travel/preparacao.md b/travel/preparacao.md new file mode 100644 index 0000000..14f5b1b --- /dev/null +++ b/travel/preparacao.md @@ -0,0 +1,34 @@ +[[!meta title="Preparação Doméstica"]] + +* Emitir avisos de viagem a partes interessadas, por exemplo: + * Família. + * Amigos. + * Clientes. + * Contador. + * Grupos e projetos. +* Contabilidade: + * Adiantar pagamentos. + * Situação de cartão de crédito. + * Colocar contas em débito automático. + * Fechar operações comerciais desnecessárias (empresas, contas, etc). +* Combinar cuidadores/as para: + * Animais domésticos e públicos. + * Casas e escritórios (caseiro ou visitas periódicas). + * Tarefas administrativas. + * Procurações e demandas legais, administrativas e contábeis. +* Manutenção preventiva em equipamentos, por exemplo: + * Sincronizar arquivos. + * Limpar servidores. + * Checar nobreaks. + * Backups e redundância. + * Limpar balde do desumidificador ou desligá-lo. + * Dosagem de cloro em mini-estação de tratamento de água. + * Suplente para administração de datancenters e outras instalações. +* Pessoal: + * Preparação do TPC. + * Declaração Canária. + * Modo nomail em listas. + * Cortar cabelo. + * Trancar matrículas em cursos. + * Guardar pertences. + * Checar vistos e documentação. diff --git a/travel/preparacao.mdwn b/travel/preparacao.mdwn deleted file mode 100644 index 14f5b1b..0000000 --- a/travel/preparacao.mdwn +++ /dev/null @@ -1,34 +0,0 @@ -[[!meta title="Preparação Doméstica"]] - -* Emitir avisos de viagem a partes interessadas, por exemplo: - * Família. - * Amigos. - * Clientes. - * Contador. - * Grupos e projetos. -* Contabilidade: - * Adiantar pagamentos. - * Situação de cartão de crédito. - * Colocar contas em débito automático. - * Fechar operações comerciais desnecessárias (empresas, contas, etc). -* Combinar cuidadores/as para: - * Animais domésticos e públicos. - * Casas e escritórios (caseiro ou visitas periódicas). - * Tarefas administrativas. - * Procurações e demandas legais, administrativas e contábeis. -* Manutenção preventiva em equipamentos, por exemplo: - * Sincronizar arquivos. - * Limpar servidores. - * Checar nobreaks. - * Backups e redundância. - * Limpar balde do desumidificador ou desligá-lo. - * Dosagem de cloro em mini-estação de tratamento de água. - * Suplente para administração de datancenters e outras instalações. -* Pessoal: - * Preparação do TPC. - * Declaração Canária. - * Modo nomail em listas. - * Cortar cabelo. - * Trancar matrículas em cursos. - * Guardar pertences. - * Checar vistos e documentação. diff --git a/usando.md b/usando.md new file mode 100644 index 0000000..d07e817 --- /dev/null +++ b/usando.md @@ -0,0 +1,29 @@ +[[!meta title="Como usar este projeto"]] + +A modularidade de tais protocolos permite que eles sejam adotados tanto como um +todo quanto em pequenos conjuntos (ou mesmo unitariamente) sem perda de +consistência desde que seja observada a dependência entre protocolos/processos. + +Variáveis +--------- + +Muitos dos protocolos utilizam variáveis, isto é, porções de texto prontas para +a subsituição por um valor correspondente. Como exemplo, ocorrências da porção +de texto `$coletivo` podem ser substituídas pelo nome do seu grupo. + +Protocol Suite +-------------- + +Um desenvolvimento posterior deste projeto poderia inclusive permitir a +especificação de uma dada escolha protocolar através de: + +* Uma string de Protocol Suite. +* Identificadores de cada protocolo ou parte de protocolo. +* Indicação de dependências entre protocolos. + +Um esboço deste tipo foi feito no [RSP](https://rsp.fluxo.info). + +Clonando o código +----------------- + + git clone https://git.fluxo.info/templates diff --git a/usando.mdwn b/usando.mdwn deleted file mode 100644 index d07e817..0000000 --- a/usando.mdwn +++ /dev/null @@ -1,29 +0,0 @@ -[[!meta title="Como usar este projeto"]] - -A modularidade de tais protocolos permite que eles sejam adotados tanto como um -todo quanto em pequenos conjuntos (ou mesmo unitariamente) sem perda de -consistência desde que seja observada a dependência entre protocolos/processos. - -Variáveis ---------- - -Muitos dos protocolos utilizam variáveis, isto é, porções de texto prontas para -a subsituição por um valor correspondente. Como exemplo, ocorrências da porção -de texto `$coletivo` podem ser substituídas pelo nome do seu grupo. - -Protocol Suite --------------- - -Um desenvolvimento posterior deste projeto poderia inclusive permitir a -especificação de uma dada escolha protocolar através de: - -* Uma string de Protocol Suite. -* Identificadores de cada protocolo ou parte de protocolo. -* Indicação de dependências entre protocolos. - -Um esboço deste tipo foi feito no [RSP](https://rsp.fluxo.info). - -Clonando o código ------------------ - - git clone https://git.fluxo.info/templates -- cgit v1.2.3