From 629a734be3a5594ee470710f1b4035cd4312f637 Mon Sep 17 00:00:00 2001 From: Silvio Rhatto Date: Fri, 16 Dec 2022 00:27:16 -0300 Subject: Feat: i18n --- docs/atividades/provedor/README.en.md | 1 + docs/atividades/provedor/hospedagem.en.md | 1 + docs/atividades/provedor/hospedagem/carta.en.md | 59 ++++++ docs/atividades/provedor/hospedagem/politica.en.md | 45 ++++ docs/atividades/provedor/hospedagem/recusa.en.md | 22 ++ docs/atividades/provedor/hospedagem/termo.en.md | 92 ++++++++ docs/english/README.md | 1 - docs/english/network.md | 80 ------- docs/english/organization.md | 233 --------------------- docs/english/provider/README.md | 1 - docs/english/provider/hosting/README.md | 1 - docs/english/provider/hosting/letter.md | 59 ------ docs/english/provider/hosting/policy.md | 45 ---- docs/english/provider/hosting/refusal.md | 22 -- docs/english/provider/hosting/terms.md | 92 -------- docs/index.en.md | 3 + docs/social/coletivo/organizacao.en.md | 233 +++++++++++++++++++++ docs/social/rede.en.md | 80 +++++++ docs/todo.md | 4 - mkdocs.yml | 22 +- scripts/provision | 2 +- 21 files changed, 557 insertions(+), 541 deletions(-) create mode 100644 docs/atividades/provedor/README.en.md create mode 100644 docs/atividades/provedor/hospedagem.en.md create mode 100644 docs/atividades/provedor/hospedagem/carta.en.md create mode 100644 docs/atividades/provedor/hospedagem/politica.en.md create mode 100644 docs/atividades/provedor/hospedagem/recusa.en.md create mode 100644 docs/atividades/provedor/hospedagem/termo.en.md delete mode 100644 docs/english/README.md delete mode 100644 docs/english/network.md delete mode 100644 docs/english/organization.md delete mode 100644 docs/english/provider/README.md delete mode 100644 docs/english/provider/hosting/README.md delete mode 100644 docs/english/provider/hosting/letter.md delete mode 100644 docs/english/provider/hosting/policy.md delete mode 100644 docs/english/provider/hosting/refusal.md delete mode 100644 docs/english/provider/hosting/terms.md create mode 100644 docs/index.en.md create mode 100644 docs/social/coletivo/organizacao.en.md create mode 100644 docs/social/rede.en.md diff --git a/docs/atividades/provedor/README.en.md b/docs/atividades/provedor/README.en.md new file mode 100644 index 0000000..44fc700 --- /dev/null +++ b/docs/atividades/provedor/README.en.md @@ -0,0 +1 @@ +# Internet Services Provider diff --git a/docs/atividades/provedor/hospedagem.en.md b/docs/atividades/provedor/hospedagem.en.md new file mode 100644 index 0000000..6d34898 --- /dev/null +++ b/docs/atividades/provedor/hospedagem.en.md @@ -0,0 +1 @@ +# Hosting diff --git a/docs/atividades/provedor/hospedagem/carta.en.md b/docs/atividades/provedor/hospedagem/carta.en.md new file mode 100644 index 0000000..5bfaff4 --- /dev/null +++ b/docs/atividades/provedor/hospedagem/carta.en.md @@ -0,0 +1,59 @@ +# Hosting Letter + + $collective Hosting Letter + -------------------------- + + $collective is part of an intersection of various groups that discuss politics and + technology in different ways. We work with internet servers turned to various + cooperative goals. Then, our ideia is to colaborate with groups/projects that + are part of mutual and multiple aid and support. + + $collective is an autonomous project kept by a collective of volunteers. One of our + main goals is the collective creation of public spaces, common areas with projects and + groups that intend to enforce and straighten coexistence. + + Our intention is not just offer a "hosting service" and then we're not available + for groups that just want such thing. We want that groups we host colaborate with + the construction of a neighborhood, a rhizome, meaning that technology doesn't have to be + a barrier, but exactly the opposite. As technology is also a social construction, + its purposes, its configurations and the processes it interferes with can't + impose themselves independently of the choices made by the social groups where it's used. + + The internet is not only an environment of cooperation, but also of apropriation and + exploitation of common goods. We understand that it just turns essentially into a + public space when people can control their production and access means, things that + don't happen on corporate and governmental spaces. Because of this we try to + create public spaces, non-corporative and non-governmental and we hope that + groups we host colaborate to the construction of such spaces. + + During the construction of these kind of spaces, we make discussions where we try to + discover themes such as culture, society, technology, activism, social change + and many others. Such a research, when possible, is shared pubicly. + + We research the political implications of technology and develop systems and + instruments using different political values. We also keep a political dialogue + in the logics of theory/practice. + + So, one of our proposals is to collectivelly establish a network of mutual + support among groups and individuals interested in sharing the same physical + structure to share their knowledges, activities and researches. + + We attempt then to break the relation between service provider/clients, + because we're not service providers and the groups/individuals we host are not + our clients. We both make part of the same collaboration network where diverse + interests converge towards mutual empowerment. And who knows if such way of + organizing things won't spread to other parts of society. + + Thinking about knowledge distribution and with an incentive to new groups + interested in keeping their own server infrastructure, we try to share the most of + our organization scheme. + + And remember: for us, $collective is not just a hosting system or a service provider. + + Interesting links: + + - Researches available: http://wiki.$domain + - Configurations and operational procedures: http://padrao.$domain + + In solidarity, + $collective Group diff --git a/docs/atividades/provedor/hospedagem/politica.en.md b/docs/atividades/provedor/hospedagem/politica.en.md new file mode 100644 index 0000000..554627e --- /dev/null +++ b/docs/atividades/provedor/hospedagem/politica.en.md @@ -0,0 +1,45 @@ +# Hosting Policy + + $collective Group Hosting Policy + -------------------------------- + + 1. The Collective reserves to istelf the power to host or discontinue the + hosting of any group or individual according to the ethical, political and + practical principles of the Collective. + + 2. In the case of hosting discontinuation for a given group, the Collective + commits itself to inform the hosted part with sufficient time and to make + available the hosted data. + + 3. Groups and individuals are just hosted by the Collective if they want to + have a mutual relation of resources and activity sharing. + + 4. Once the hosting partnership is created, the Collective must be informed of + actions and ways the hosted part is taking if those affects the Collective. By + the other hand, the Collective commits to inform the hosted part of anything + that can affect it. + + 5. The terms of partnership must be clear in the sense of the commitment + between both sides on support, maintenance and development of the host and + sites. + + 6. The hosted part is responsible for the hosted content and the Collective + cannot suffer legal consequences of improper or illegal content. Anyway the + Collective will make everything possible to protect the identity and privacy of + the hosted part. + + 7. The relations should be established as transparently as possible, avoiding + hidden or manipulated information by both parts. + + 8. The relations have the purpose of solidarity on knowledge, complementarity + on actions and exchange among groups, being vital to achieve ways of mutual + teaching-learning and develop policies that unite groups towards social and + political changes. + + 9. The Collective commits itself to inform at least in general ways its + security and privacy policies on the hosting platforms. + + 10. Hosting of social movements with sensitive content are kept, when possible, + hosted on platforms abroad. + + 11. The hosting consists in cooperation and not in service providing. diff --git a/docs/atividades/provedor/hospedagem/recusa.en.md b/docs/atividades/provedor/hospedagem/recusa.en.md new file mode 100644 index 0000000..7cd4648 --- /dev/null +++ b/docs/atividades/provedor/hospedagem/recusa.en.md @@ -0,0 +1,22 @@ +# Refusal hosting letter + + Hi $requisitante, + + Unfortunatelly we can't host the project you requested because: + + - We think it doesn't match the etical principles we adopt[1]. + + - And/or we consider it matches the kind of projects we have a critical + position with[2]. + + We believe that there's not just one way to fight. We also don't believe that + our etical principles and our criticisms represent the "right" viewpoint. + Our viewpoint just reflect the conclusions we got after a lot of discussions. + We try just to be coherent with what we believe and that's the reason why we + can't accept your request. + + We don't want for this statement to mean that we want to give no value for + the thing your project do or about what do you believe. + + [1] See http://encontro.fluxo.info/Principal/ConjuntoDePrincipiosEticos + [2] See http://wiki.$dominio diff --git a/docs/atividades/provedor/hospedagem/termo.en.md b/docs/atividades/provedor/hospedagem/termo.en.md new file mode 100644 index 0000000..91b5f3f --- /dev/null +++ b/docs/atividades/provedor/hospedagem/termo.en.md @@ -0,0 +1,92 @@ +# Hosting Terms + + Hi :) + + Agreement on Hosting + -------------------- + + We discussed and we agree to offer hosting as you requested. Now, in order for we to + effectivelly maintain this hosting, we need to: + + 1. State what is our commitment in relation to this hosting. + 2. That you and/or your group agree with the present term of agreement and + with our Hosting Policy. + + These are mutual commitment agreements, where we explain what is our commitment + with the hosting and that the hosted part needs to agree so we can keep such + relation. + + In case you agree with the terms of this letter and accept our Hosting Policy, + just reply saying so and the hosting will start as soon as possible. :) + + Our commitment + -------------- + + We commit ourselves to keep the hosting working. The hosting maintenance + happens through volunteer and responsible work. + + The used infra-structure is stable, but subject to eventual power and network + outages or even more sensitive problems. + + Then, sometimes hosting can go offline. We will always be allert and we care + for security and integrity of the hosted data. But, for a lot of reasons, we + cannot garantee the total availability or even the eternity of such data. + + We commit ourselves as much as possible to keep security copies of the data we + host. But we ask for you to also arrange, as much as possible, backup copies of + your data. + + Our group is composed by people that do a lot of tasks. The most important and + sensitive tasks, such as hosting, are dependent to other taks and each one is + associated to a workgroup of responsible persons. + + It may happen that someone leaves a workgroup and eventually some tasks will lack + commited people to get them accomplished. It's on this sense that we garantee + hosting: according to the available workforce at our group. It's possible that, + in the future, something happens and we stop hosting in a given platform. + But, if we do so, we garantee that it won't happen from night to day and we'll + give enough time for you and your project to migrate the data somewhere else. + + We also have the commitment to inform, when you ask, our procedures according to + our accounting policy. Such procedures vary from privacy and security policies + to choices of platforms and our group's situation. + + As our procedures can change with time, we recommend you to ask for procedures + descriptions when you feel necessary. + + We have our limitations but we'll keep things working as much as we can. :) + + Your commitment + --------------- + + We hope that you and/or your project use the offered resource with wisdom. + Don't ask for websites and tools if you will abandon them. If you install your own + programs, please have the responsibility to keep it up-to-date as security holes at + your place can compromise other hosted projects. + + Please don't forget that the maintenance of multiple projects needs a lot of work + and is difficult to keep secure. Then we ask for everyone's collaboration. We would be + very pleased if you informed us about your plans to install tools in your space. :) + + Sharing interfaces + ------------------ + + A possible space for interactions among projects is the Neighborhood Mailing + List[1] (subscription just for sufficiently secure mail accounts, get in touch for + more information). When we host groups and individuals, we hope that they will also + be responsible in what comes to taking care of such spaces. + + Our neighborhood is also a place for articulations, where all groups and + individuals sharing the same infra-structure can communicate between + themselves. + + If the subjects we research are inspiring for you too, we invite you to + participate in such discussions. To avoid centralization, we propose you to + collectivelly discuss with your group and publish the conclusions you + get. For us it is fundamental to try to build a metodology that makes possible the + dissemination of such discussions. + + [1] $neighborhood_mailing_list_address + + In solidarity, + $grupo Collective diff --git a/docs/english/README.md b/docs/english/README.md deleted file mode 100644 index a4c9eb7..0000000 --- a/docs/english/README.md +++ /dev/null @@ -1 +0,0 @@ -# English version diff --git a/docs/english/network.md b/docs/english/network.md deleted file mode 100644 index 3793d5a..0000000 --- a/docs/english/network.md +++ /dev/null @@ -1,80 +0,0 @@ -# Principles and process for a network of collectives - -Originally [Network intentions and process letter](https://rectech.sarava.org/publico/processo). - -About ------ - -The `$network` network is a forum of anti-capitalist, anti-fascist, anti-sexists, -anti-homophobic and anti-racists tech collectives that rejects any form of -social domination and prejudice. - -The goal of the forum is to allow interchange, mutual aid and cooperation among -collective members and also to be a public interface for debates. - -Then, `$network` is not a collective but a network. - -How it works ------------- - -The network by default is in a dormant state until be activated, when for example -some collective(s) suggest an activity, meeting or cooperation. - -Membership process ------------------- - -Membership in the `$network` network is restrictet to collectives that comply with -afinity, trust and commitment to the network. New collectives can join the network -after positive decision making process and if they agree with this letter. - -Once inside the network, collectives can determine which of its members has to -be subscribed or unsubscribed from the `$network` network communication platforms. - -When joining on the `$network` network communication platforms, each individual has -to present her or himself and state that will act in a constructive way, -otherwise will be subjected to unsubscription. - -Decision making process ------------------------ - -No person or group can take decisions that affect the network autonomy before -consulting the network and getting a positive consensus. - -Decisions in the network are based on proposals that have to be sent to the -network's closed discussion list. - -The minimum deadline for decisions is two weeks up to postponing and the -decisions are taken by consensus. If a collective doesn't manifests about a -proposal it will be considered that the collective agrees with the proposal. - -Privacy -------- - -The `$network` network is semi-public, i.e, part of it's communication and -organization is restricted to the member collectives while other part is public -and open to any group or person. - -Informations that flows in private communication instances needs authorization -to be shared in public media (declassification). - -It's a choice of each member to stay or not as a private member. - -Communication interfaces ------------------------- - -The `$network` network has the following communication instances: - - - Closed list with archives restricted to its members. - - Moderated announcement list with open subscription and open archives. - - Collaborative web platform. - -Such interfaces are hosted by member or trusted collectives and it's access and -existence are crucial to the maintenance of the network memory. Then, it's -imprescindibile to the network to have backups of these platform when needed. - -About this text ---------------- - -This process was based on the "Template for Network Intentions and process letter v1.0". -License for the document: GNU Free Documentation License: -http://www.gnu.org/copyleft/fdl.html diff --git a/docs/english/organization.md b/docs/english/organization.md deleted file mode 100644 index 0702bd8..0000000 --- a/docs/english/organization.md +++ /dev/null @@ -1,233 +0,0 @@ -# Collective Action Protocol - -The protocol was written to make possible a generic adoption by groups but at -the same time it attempt to solve specific problems that aren't necessarily -shared by a gvin group. Then, it's not intended to be "The Collective Protocol" -but instead a suggestion about how to shape a collective protocol. - -Suggestion is to read it as how could a collective protocol look like instead a -sugestion of adoption, especially because usually the needs for a process are -different as here we're trying to solve a different set of problems. - -The Collective Action Protocol seems to be both a stateless (at it's informal -part) and stateful (at it's formal part) protocol. It has some inspiration -from: - -* Games, altough it's unknow how a parallel with game theory could be traced - (could this protocol be considered a game where the objective is a win-win - outcome attempting to maximize the collective effort?). -* Free and open source software development processes (although this protocol - makes the 'benevolent dictator' obsolete as behaviour, purpose and telealogy - turns to be mean properties emerging internally from the processes and - peoples' wishes and mutual relationship). It can be thought as a social - software (culture). -* Ways labor division can be organized to better fill collective needs and - autonomy while encouraging people to work together. - -Characteristics ---------------- - -For sinthetic purposes, most of the discussion was split from the protocol -text. Perhaps this compression let a lot of helpful information to be missing, -so here comes a list of the main properties this protocol tries to achieve: - -* Resilience, robustness and failover. -* Ensure some collective autonomy is guaranteed (through formal process having - responsibility attached) while not blocking the self-organizing efforts using - to kinds of processes (formal and informal). This means in some way to - overcome the [The Tyranny of - Structurelessness](http://en.wikipedia.org/wiki/Tyranny_of_Structurelessness) - while not failing back to over-structuration, bureaucracy, etc and at the - same time tries to deal with apathy and missparticipation. -* For formal processes, splits decision-making (i.e, the step where the - collective evals if a given proposal is pertinent an deserves the collective - moral support) from the resposibility assignment (step where people actually - volunteer to do the tasks) in a way that just formal processses that are - under responsibility can be counted as processes that will very probably - happen, so if in the proposal/discussion/decision steps just the content of - the proposal is evalued, the responsibility assignment is a filter where just - processes that finds people to achieve them are able to pass. -* Leting a process be also a registry eases the integration with a ticket system. - -Limitations ------------ - -Some limitations of the protocol are: - -* Not sure whether it's scalable. Maybe it was set for usage inside a small - affinity group so it might not fit to big groups where people has not - affinity between themselves. -* It does not deal with connections/disconnections, i.e, the protocol do not - define how someone joins or leaves the group. -* As all protocols depends on it's usage, it is not a guarantee by itself that - things are going to happen in the collective. The protocol just states how - the energy is spent in the collective process but have no influence in the - desire to act or not to act. -* It does not state what are the communication channels (both for formal and - informal communications) and how they should be used. In fact, as this really - varies a lot from collective to collective so it was chosen to leave that - specific communication structure out of the Collective Action Protocol so it - would be easier to share and have another protocol taking care of - informational channels. - -Formality and informality -------------------------- - -In this protocol, what is a formal and what is an informal process really -depends in how the collective wants to extend it's autonomy, so it's not a -thing defined withing the protocol. Examples of formal and informal processes -can be: - -* Informal processes: meetings, dinners, researching, write texts, code, talk - with people, wikifarming and everything else that the collective thinks that - does not changes the collective autonomy. -* Formal processes: the main activities the group is commited to do and what is - crucial for them to happen and to keep the collective autonomy. - -Collective Action Protocol --------------------------- - -* Version: 0.1. -* Raw english translation version (related to protocol version): 0.1. -* License: Sarava Content Distribution License (no translation for now :/) - -Processes and autonomy ----------------------- - -Everything that happens in the Collective is a process. Processes has different -manifestations but are mainly fluxes and the registry of these fluxes -(memory/information). - -There are two kinds of processes: - -* Formal processes - * Shape/form predefined by collective consensus AND - * Needs/use the collective autonomy THUS - * Needs to be followed by a minimum responsabilization so the process do - not fail - -* Informal processes - * Shape/form not needed to be predefined AND - * Do not need/use the collective autonomy THUS - * Do not need to be under the resposability of someone, i.e, an informal - process that do not happen doesn't affect the collective autonomy - -Activities without information in the collective cannot be considered by -processes (formal or informal) as these activities do not have information -equality/isonomy in the collective. To have information about a process is a -requisite for participation and then an activity without information inside the -collective cannot be considered as process. - -The basic autonomy of the Collective, i.e, the minimum autonomy that allows -it's existence according to this protocol is the existence of secure and -private communication channels that allows the existence of collective -processes (formal or informal). Without these channels, the basic collective -autonomy is seriously damaged as well as the application of this protocol. All -aditional autonomy in the collective (i.e, autonomy that is not contained in -the basic autonomy) should be defined with formal processes. - -A collective member act inside the collective when use it's resources or the -collective name. By the other hand, a collective member act outside of the -collective when do not use such resources or the collective name. Collective -members do not make actions (inside or outside the collective) that -consciouslly can cause damage to the collective autonomy. - -Formal processes ----------------- - -Each formal processs is an instance of the following state diagram: - - .------------------->-----------------. - / .----------<--------------<-------. \ - | ' \ \ - | | .------>-----. \ \ - | | | \ \ \ - Proposal -----> Discussion ->-. \ \ \ - | ^ | \ \ \ \ - | | | \ \ \ \ - | `----<-----' | \ \ \ - | | | \ \ - `------>----- Decision --<--' | \ \ - | | | \ \ - | | | | | - Responsibility --<---' '------> Archiving --->---' ; - Assignment --------->---------' ^ \ / - ^ | ___________/ `---<-----' - | \ .' - | `--> Achievement ->--. - | | | \ - | | | / - `----<-----' `-----<---' - -* Proposal: step where an idea of a formal process is presented to the - collective. The idea -- or description -- can come for the Archive, from a - previous Discussion, from an informal process that needs to be formalized or - from a person or group from inside or outside the collective. General - recomendation is to give a good explanation of the idea containing: deadline - sugestion, process life cycle, responsibility assignment criteria and - deadline and recomendations for emergencies (when appliable). - -* Discussion: - * It's not a mandatory step, but has importance anyway. - * Changes to proposals make the formal process go back to the Proposal - state. Proposals that do not follow to the Decision step or do not get - changes until it's deadline should be archived. - * Changed proposals that come from outside the collective or that have - external groups or persons participation should be sent back also to the - external group/person, despite these persons/groups do not participate in - the internal discussion at the collective. If these external - people/groups agree with the changed proposal, then the formal process - proceeds with the discussion using the changed proposal. If that doesn't - happen, i.e, these external people/groups don't agree with the changed - proposal, then the formal process is archived (except if the external - parties provide another changed proposal or more arguments to the - discussion). - -* Decision: - * Through consensus and the active participation depends in following the - information required by the proposal. - * If there's no consensus about the decision of a proposal it's - automatically blocked with the possibility to extend it's deadline. - * Silence regarding a proposal is considered as an agreement. - * Deadline: general recomendation is to set deadlines relative to the - average time needed by active people in the collective to take into - account, discuss, make changes and ask for eventual postponing. Processes - are elegible to postponing or advance it's deadline with an explicitly - request from someone from the collective. If there's no such request, the - initial deadline is assumed. - * Approvals from proposals coming from outside the collective or that have - external people/groups involved are communicated about the approval just - after the responsibility assignment. - -* Responsibility assignment - * Concerns the minimization of points of failure. - * Responsibilization is a volunteer action but requires the submission of a - commitment/responsibilization term affirming that the person: - * Has knowledge about the procedure in question. - * Is gonna achieve it under the estimated deadline and is gonna keep - the collective informed about the task. - * Will inform the collective in a reasonable timeframe if cannot - continue to be involved with the process so the collective can keep - the process going, assign new responsibilities or finnish it and send - to the archive. - * Non-accomplishment with a process compromises the ability of someone to - be responsible for other tasks. - * Formal processes that are approved but, after the responsibility - assignment deadline, have unsufficient responsibilization assigned, - should be sent to the archive. Proceesses in the archive were previously - approved cannot be sent back directly to the responsibilty assigment and - should instead go to the proposal step. - * In case of proposals coming from outside the collective or that have - external people/groups involved, these people/groups should be informed - of the approval just after the responsibility assignment, i.e, at the end - of this step. - -* Achievement - * Just formal processes with sufficient responsibility assignment can go to - the achievement step. Processes that were already achived goes to the - archive. - * Formal processes that were not achieved in the deadline should come back - to the Responsibility assignment step. In a similar way, processes whose - assigned people cannot doing it should come back to the Responsibility - assignment step if the number of assigned people is smaller than the - required. diff --git a/docs/english/provider/README.md b/docs/english/provider/README.md deleted file mode 100644 index 44fc700..0000000 --- a/docs/english/provider/README.md +++ /dev/null @@ -1 +0,0 @@ -# Internet Services Provider diff --git a/docs/english/provider/hosting/README.md b/docs/english/provider/hosting/README.md deleted file mode 100644 index 6d34898..0000000 --- a/docs/english/provider/hosting/README.md +++ /dev/null @@ -1 +0,0 @@ -# Hosting diff --git a/docs/english/provider/hosting/letter.md b/docs/english/provider/hosting/letter.md deleted file mode 100644 index 5bfaff4..0000000 --- a/docs/english/provider/hosting/letter.md +++ /dev/null @@ -1,59 +0,0 @@ -# Hosting Letter - - $collective Hosting Letter - -------------------------- - - $collective is part of an intersection of various groups that discuss politics and - technology in different ways. We work with internet servers turned to various - cooperative goals. Then, our ideia is to colaborate with groups/projects that - are part of mutual and multiple aid and support. - - $collective is an autonomous project kept by a collective of volunteers. One of our - main goals is the collective creation of public spaces, common areas with projects and - groups that intend to enforce and straighten coexistence. - - Our intention is not just offer a "hosting service" and then we're not available - for groups that just want such thing. We want that groups we host colaborate with - the construction of a neighborhood, a rhizome, meaning that technology doesn't have to be - a barrier, but exactly the opposite. As technology is also a social construction, - its purposes, its configurations and the processes it interferes with can't - impose themselves independently of the choices made by the social groups where it's used. - - The internet is not only an environment of cooperation, but also of apropriation and - exploitation of common goods. We understand that it just turns essentially into a - public space when people can control their production and access means, things that - don't happen on corporate and governmental spaces. Because of this we try to - create public spaces, non-corporative and non-governmental and we hope that - groups we host colaborate to the construction of such spaces. - - During the construction of these kind of spaces, we make discussions where we try to - discover themes such as culture, society, technology, activism, social change - and many others. Such a research, when possible, is shared pubicly. - - We research the political implications of technology and develop systems and - instruments using different political values. We also keep a political dialogue - in the logics of theory/practice. - - So, one of our proposals is to collectivelly establish a network of mutual - support among groups and individuals interested in sharing the same physical - structure to share their knowledges, activities and researches. - - We attempt then to break the relation between service provider/clients, - because we're not service providers and the groups/individuals we host are not - our clients. We both make part of the same collaboration network where diverse - interests converge towards mutual empowerment. And who knows if such way of - organizing things won't spread to other parts of society. - - Thinking about knowledge distribution and with an incentive to new groups - interested in keeping their own server infrastructure, we try to share the most of - our organization scheme. - - And remember: for us, $collective is not just a hosting system or a service provider. - - Interesting links: - - - Researches available: http://wiki.$domain - - Configurations and operational procedures: http://padrao.$domain - - In solidarity, - $collective Group diff --git a/docs/english/provider/hosting/policy.md b/docs/english/provider/hosting/policy.md deleted file mode 100644 index 554627e..0000000 --- a/docs/english/provider/hosting/policy.md +++ /dev/null @@ -1,45 +0,0 @@ -# Hosting Policy - - $collective Group Hosting Policy - -------------------------------- - - 1. The Collective reserves to istelf the power to host or discontinue the - hosting of any group or individual according to the ethical, political and - practical principles of the Collective. - - 2. In the case of hosting discontinuation for a given group, the Collective - commits itself to inform the hosted part with sufficient time and to make - available the hosted data. - - 3. Groups and individuals are just hosted by the Collective if they want to - have a mutual relation of resources and activity sharing. - - 4. Once the hosting partnership is created, the Collective must be informed of - actions and ways the hosted part is taking if those affects the Collective. By - the other hand, the Collective commits to inform the hosted part of anything - that can affect it. - - 5. The terms of partnership must be clear in the sense of the commitment - between both sides on support, maintenance and development of the host and - sites. - - 6. The hosted part is responsible for the hosted content and the Collective - cannot suffer legal consequences of improper or illegal content. Anyway the - Collective will make everything possible to protect the identity and privacy of - the hosted part. - - 7. The relations should be established as transparently as possible, avoiding - hidden or manipulated information by both parts. - - 8. The relations have the purpose of solidarity on knowledge, complementarity - on actions and exchange among groups, being vital to achieve ways of mutual - teaching-learning and develop policies that unite groups towards social and - political changes. - - 9. The Collective commits itself to inform at least in general ways its - security and privacy policies on the hosting platforms. - - 10. Hosting of social movements with sensitive content are kept, when possible, - hosted on platforms abroad. - - 11. The hosting consists in cooperation and not in service providing. diff --git a/docs/english/provider/hosting/refusal.md b/docs/english/provider/hosting/refusal.md deleted file mode 100644 index 7cd4648..0000000 --- a/docs/english/provider/hosting/refusal.md +++ /dev/null @@ -1,22 +0,0 @@ -# Refusal hosting letter - - Hi $requisitante, - - Unfortunatelly we can't host the project you requested because: - - - We think it doesn't match the etical principles we adopt[1]. - - - And/or we consider it matches the kind of projects we have a critical - position with[2]. - - We believe that there's not just one way to fight. We also don't believe that - our etical principles and our criticisms represent the "right" viewpoint. - Our viewpoint just reflect the conclusions we got after a lot of discussions. - We try just to be coherent with what we believe and that's the reason why we - can't accept your request. - - We don't want for this statement to mean that we want to give no value for - the thing your project do or about what do you believe. - - [1] See http://encontro.fluxo.info/Principal/ConjuntoDePrincipiosEticos - [2] See http://wiki.$dominio diff --git a/docs/english/provider/hosting/terms.md b/docs/english/provider/hosting/terms.md deleted file mode 100644 index 91b5f3f..0000000 --- a/docs/english/provider/hosting/terms.md +++ /dev/null @@ -1,92 +0,0 @@ -# Hosting Terms - - Hi :) - - Agreement on Hosting - -------------------- - - We discussed and we agree to offer hosting as you requested. Now, in order for we to - effectivelly maintain this hosting, we need to: - - 1. State what is our commitment in relation to this hosting. - 2. That you and/or your group agree with the present term of agreement and - with our Hosting Policy. - - These are mutual commitment agreements, where we explain what is our commitment - with the hosting and that the hosted part needs to agree so we can keep such - relation. - - In case you agree with the terms of this letter and accept our Hosting Policy, - just reply saying so and the hosting will start as soon as possible. :) - - Our commitment - -------------- - - We commit ourselves to keep the hosting working. The hosting maintenance - happens through volunteer and responsible work. - - The used infra-structure is stable, but subject to eventual power and network - outages or even more sensitive problems. - - Then, sometimes hosting can go offline. We will always be allert and we care - for security and integrity of the hosted data. But, for a lot of reasons, we - cannot garantee the total availability or even the eternity of such data. - - We commit ourselves as much as possible to keep security copies of the data we - host. But we ask for you to also arrange, as much as possible, backup copies of - your data. - - Our group is composed by people that do a lot of tasks. The most important and - sensitive tasks, such as hosting, are dependent to other taks and each one is - associated to a workgroup of responsible persons. - - It may happen that someone leaves a workgroup and eventually some tasks will lack - commited people to get them accomplished. It's on this sense that we garantee - hosting: according to the available workforce at our group. It's possible that, - in the future, something happens and we stop hosting in a given platform. - But, if we do so, we garantee that it won't happen from night to day and we'll - give enough time for you and your project to migrate the data somewhere else. - - We also have the commitment to inform, when you ask, our procedures according to - our accounting policy. Such procedures vary from privacy and security policies - to choices of platforms and our group's situation. - - As our procedures can change with time, we recommend you to ask for procedures - descriptions when you feel necessary. - - We have our limitations but we'll keep things working as much as we can. :) - - Your commitment - --------------- - - We hope that you and/or your project use the offered resource with wisdom. - Don't ask for websites and tools if you will abandon them. If you install your own - programs, please have the responsibility to keep it up-to-date as security holes at - your place can compromise other hosted projects. - - Please don't forget that the maintenance of multiple projects needs a lot of work - and is difficult to keep secure. Then we ask for everyone's collaboration. We would be - very pleased if you informed us about your plans to install tools in your space. :) - - Sharing interfaces - ------------------ - - A possible space for interactions among projects is the Neighborhood Mailing - List[1] (subscription just for sufficiently secure mail accounts, get in touch for - more information). When we host groups and individuals, we hope that they will also - be responsible in what comes to taking care of such spaces. - - Our neighborhood is also a place for articulations, where all groups and - individuals sharing the same infra-structure can communicate between - themselves. - - If the subjects we research are inspiring for you too, we invite you to - participate in such discussions. To avoid centralization, we propose you to - collectivelly discuss with your group and publish the conclusions you - get. For us it is fundamental to try to build a metodology that makes possible the - dissemination of such discussions. - - [1] $neighborhood_mailing_list_address - - In solidarity, - $grupo Collective diff --git a/docs/index.en.md b/docs/index.en.md new file mode 100644 index 0000000..774fcb6 --- /dev/null +++ b/docs/index.en.md @@ -0,0 +1,3 @@ +# Sociotechnic Protocols + +**Blueprints, boilerplates, models, lists, templates! Ready to use and to organize yourself and your team!** diff --git a/docs/social/coletivo/organizacao.en.md b/docs/social/coletivo/organizacao.en.md new file mode 100644 index 0000000..0702bd8 --- /dev/null +++ b/docs/social/coletivo/organizacao.en.md @@ -0,0 +1,233 @@ +# Collective Action Protocol + +The protocol was written to make possible a generic adoption by groups but at +the same time it attempt to solve specific problems that aren't necessarily +shared by a gvin group. Then, it's not intended to be "The Collective Protocol" +but instead a suggestion about how to shape a collective protocol. + +Suggestion is to read it as how could a collective protocol look like instead a +sugestion of adoption, especially because usually the needs for a process are +different as here we're trying to solve a different set of problems. + +The Collective Action Protocol seems to be both a stateless (at it's informal +part) and stateful (at it's formal part) protocol. It has some inspiration +from: + +* Games, altough it's unknow how a parallel with game theory could be traced + (could this protocol be considered a game where the objective is a win-win + outcome attempting to maximize the collective effort?). +* Free and open source software development processes (although this protocol + makes the 'benevolent dictator' obsolete as behaviour, purpose and telealogy + turns to be mean properties emerging internally from the processes and + peoples' wishes and mutual relationship). It can be thought as a social + software (culture). +* Ways labor division can be organized to better fill collective needs and + autonomy while encouraging people to work together. + +Characteristics +--------------- + +For sinthetic purposes, most of the discussion was split from the protocol +text. Perhaps this compression let a lot of helpful information to be missing, +so here comes a list of the main properties this protocol tries to achieve: + +* Resilience, robustness and failover. +* Ensure some collective autonomy is guaranteed (through formal process having + responsibility attached) while not blocking the self-organizing efforts using + to kinds of processes (formal and informal). This means in some way to + overcome the [The Tyranny of + Structurelessness](http://en.wikipedia.org/wiki/Tyranny_of_Structurelessness) + while not failing back to over-structuration, bureaucracy, etc and at the + same time tries to deal with apathy and missparticipation. +* For formal processes, splits decision-making (i.e, the step where the + collective evals if a given proposal is pertinent an deserves the collective + moral support) from the resposibility assignment (step where people actually + volunteer to do the tasks) in a way that just formal processses that are + under responsibility can be counted as processes that will very probably + happen, so if in the proposal/discussion/decision steps just the content of + the proposal is evalued, the responsibility assignment is a filter where just + processes that finds people to achieve them are able to pass. +* Leting a process be also a registry eases the integration with a ticket system. + +Limitations +----------- + +Some limitations of the protocol are: + +* Not sure whether it's scalable. Maybe it was set for usage inside a small + affinity group so it might not fit to big groups where people has not + affinity between themselves. +* It does not deal with connections/disconnections, i.e, the protocol do not + define how someone joins or leaves the group. +* As all protocols depends on it's usage, it is not a guarantee by itself that + things are going to happen in the collective. The protocol just states how + the energy is spent in the collective process but have no influence in the + desire to act or not to act. +* It does not state what are the communication channels (both for formal and + informal communications) and how they should be used. In fact, as this really + varies a lot from collective to collective so it was chosen to leave that + specific communication structure out of the Collective Action Protocol so it + would be easier to share and have another protocol taking care of + informational channels. + +Formality and informality +------------------------- + +In this protocol, what is a formal and what is an informal process really +depends in how the collective wants to extend it's autonomy, so it's not a +thing defined withing the protocol. Examples of formal and informal processes +can be: + +* Informal processes: meetings, dinners, researching, write texts, code, talk + with people, wikifarming and everything else that the collective thinks that + does not changes the collective autonomy. +* Formal processes: the main activities the group is commited to do and what is + crucial for them to happen and to keep the collective autonomy. + +Collective Action Protocol +-------------------------- + +* Version: 0.1. +* Raw english translation version (related to protocol version): 0.1. +* License: Sarava Content Distribution License (no translation for now :/) + +Processes and autonomy +---------------------- + +Everything that happens in the Collective is a process. Processes has different +manifestations but are mainly fluxes and the registry of these fluxes +(memory/information). + +There are two kinds of processes: + +* Formal processes + * Shape/form predefined by collective consensus AND + * Needs/use the collective autonomy THUS + * Needs to be followed by a minimum responsabilization so the process do + not fail + +* Informal processes + * Shape/form not needed to be predefined AND + * Do not need/use the collective autonomy THUS + * Do not need to be under the resposability of someone, i.e, an informal + process that do not happen doesn't affect the collective autonomy + +Activities without information in the collective cannot be considered by +processes (formal or informal) as these activities do not have information +equality/isonomy in the collective. To have information about a process is a +requisite for participation and then an activity without information inside the +collective cannot be considered as process. + +The basic autonomy of the Collective, i.e, the minimum autonomy that allows +it's existence according to this protocol is the existence of secure and +private communication channels that allows the existence of collective +processes (formal or informal). Without these channels, the basic collective +autonomy is seriously damaged as well as the application of this protocol. All +aditional autonomy in the collective (i.e, autonomy that is not contained in +the basic autonomy) should be defined with formal processes. + +A collective member act inside the collective when use it's resources or the +collective name. By the other hand, a collective member act outside of the +collective when do not use such resources or the collective name. Collective +members do not make actions (inside or outside the collective) that +consciouslly can cause damage to the collective autonomy. + +Formal processes +---------------- + +Each formal processs is an instance of the following state diagram: + + .------------------->-----------------. + / .----------<--------------<-------. \ + | ' \ \ + | | .------>-----. \ \ + | | | \ \ \ + Proposal -----> Discussion ->-. \ \ \ + | ^ | \ \ \ \ + | | | \ \ \ \ + | `----<-----' | \ \ \ + | | | \ \ + `------>----- Decision --<--' | \ \ + | | | \ \ + | | | | | + Responsibility --<---' '------> Archiving --->---' ; + Assignment --------->---------' ^ \ / + ^ | ___________/ `---<-----' + | \ .' + | `--> Achievement ->--. + | | | \ + | | | / + `----<-----' `-----<---' + +* Proposal: step where an idea of a formal process is presented to the + collective. The idea -- or description -- can come for the Archive, from a + previous Discussion, from an informal process that needs to be formalized or + from a person or group from inside or outside the collective. General + recomendation is to give a good explanation of the idea containing: deadline + sugestion, process life cycle, responsibility assignment criteria and + deadline and recomendations for emergencies (when appliable). + +* Discussion: + * It's not a mandatory step, but has importance anyway. + * Changes to proposals make the formal process go back to the Proposal + state. Proposals that do not follow to the Decision step or do not get + changes until it's deadline should be archived. + * Changed proposals that come from outside the collective or that have + external groups or persons participation should be sent back also to the + external group/person, despite these persons/groups do not participate in + the internal discussion at the collective. If these external + people/groups agree with the changed proposal, then the formal process + proceeds with the discussion using the changed proposal. If that doesn't + happen, i.e, these external people/groups don't agree with the changed + proposal, then the formal process is archived (except if the external + parties provide another changed proposal or more arguments to the + discussion). + +* Decision: + * Through consensus and the active participation depends in following the + information required by the proposal. + * If there's no consensus about the decision of a proposal it's + automatically blocked with the possibility to extend it's deadline. + * Silence regarding a proposal is considered as an agreement. + * Deadline: general recomendation is to set deadlines relative to the + average time needed by active people in the collective to take into + account, discuss, make changes and ask for eventual postponing. Processes + are elegible to postponing or advance it's deadline with an explicitly + request from someone from the collective. If there's no such request, the + initial deadline is assumed. + * Approvals from proposals coming from outside the collective or that have + external people/groups involved are communicated about the approval just + after the responsibility assignment. + +* Responsibility assignment + * Concerns the minimization of points of failure. + * Responsibilization is a volunteer action but requires the submission of a + commitment/responsibilization term affirming that the person: + * Has knowledge about the procedure in question. + * Is gonna achieve it under the estimated deadline and is gonna keep + the collective informed about the task. + * Will inform the collective in a reasonable timeframe if cannot + continue to be involved with the process so the collective can keep + the process going, assign new responsibilities or finnish it and send + to the archive. + * Non-accomplishment with a process compromises the ability of someone to + be responsible for other tasks. + * Formal processes that are approved but, after the responsibility + assignment deadline, have unsufficient responsibilization assigned, + should be sent to the archive. Proceesses in the archive were previously + approved cannot be sent back directly to the responsibilty assigment and + should instead go to the proposal step. + * In case of proposals coming from outside the collective or that have + external people/groups involved, these people/groups should be informed + of the approval just after the responsibility assignment, i.e, at the end + of this step. + +* Achievement + * Just formal processes with sufficient responsibility assignment can go to + the achievement step. Processes that were already achived goes to the + archive. + * Formal processes that were not achieved in the deadline should come back + to the Responsibility assignment step. In a similar way, processes whose + assigned people cannot doing it should come back to the Responsibility + assignment step if the number of assigned people is smaller than the + required. diff --git a/docs/social/rede.en.md b/docs/social/rede.en.md new file mode 100644 index 0000000..3793d5a --- /dev/null +++ b/docs/social/rede.en.md @@ -0,0 +1,80 @@ +# Principles and process for a network of collectives + +Originally [Network intentions and process letter](https://rectech.sarava.org/publico/processo). + +About +----- + +The `$network` network is a forum of anti-capitalist, anti-fascist, anti-sexists, +anti-homophobic and anti-racists tech collectives that rejects any form of +social domination and prejudice. + +The goal of the forum is to allow interchange, mutual aid and cooperation among +collective members and also to be a public interface for debates. + +Then, `$network` is not a collective but a network. + +How it works +------------ + +The network by default is in a dormant state until be activated, when for example +some collective(s) suggest an activity, meeting or cooperation. + +Membership process +------------------ + +Membership in the `$network` network is restrictet to collectives that comply with +afinity, trust and commitment to the network. New collectives can join the network +after positive decision making process and if they agree with this letter. + +Once inside the network, collectives can determine which of its members has to +be subscribed or unsubscribed from the `$network` network communication platforms. + +When joining on the `$network` network communication platforms, each individual has +to present her or himself and state that will act in a constructive way, +otherwise will be subjected to unsubscription. + +Decision making process +----------------------- + +No person or group can take decisions that affect the network autonomy before +consulting the network and getting a positive consensus. + +Decisions in the network are based on proposals that have to be sent to the +network's closed discussion list. + +The minimum deadline for decisions is two weeks up to postponing and the +decisions are taken by consensus. If a collective doesn't manifests about a +proposal it will be considered that the collective agrees with the proposal. + +Privacy +------- + +The `$network` network is semi-public, i.e, part of it's communication and +organization is restricted to the member collectives while other part is public +and open to any group or person. + +Informations that flows in private communication instances needs authorization +to be shared in public media (declassification). + +It's a choice of each member to stay or not as a private member. + +Communication interfaces +------------------------ + +The `$network` network has the following communication instances: + + - Closed list with archives restricted to its members. + - Moderated announcement list with open subscription and open archives. + - Collaborative web platform. + +Such interfaces are hosted by member or trusted collectives and it's access and +existence are crucial to the maintenance of the network memory. Then, it's +imprescindibile to the network to have backups of these platform when needed. + +About this text +--------------- + +This process was based on the "Template for Network Intentions and process letter v1.0". +License for the document: GNU Free Documentation License: +http://www.gnu.org/copyleft/fdl.html diff --git a/docs/todo.md b/docs/todo.md index 0ecaaea..cd611d2 100644 --- a/docs/todo.md +++ b/docs/todo.md @@ -2,10 +2,6 @@ Lista de tarefas deste projeto. -## MkDocs - -* Setup [mkdocs-i18n](https://pypi.org/project/mkdocs-i18n/). - ## Protocol Suite Um desenvolvimento posterior deste projeto poderia inclusive permitir a diff --git a/mkdocs.yml b/mkdocs.yml index 148a499..c6873f7 100644 --- a/mkdocs.yml +++ b/mkdocs.yml @@ -2,13 +2,16 @@ # Mkdocs configuration # -site_name: Protocolos +site_name: Protocolos Sociotécnicos docs_dir : docs site_dir : site +repo_url: https://git.fluxo.info/templates +edit_uri: '' + # Site address is bind to 0.0.0.0 so it works find inside a Docker container. # A better config would be desirable. -dev_addr : '0.0.0.0:8040' +#dev_addr: '0.0.0.0:8040' theme: name : material @@ -28,5 +31,20 @@ plugins: # bib_dir : "catalogs/biblio" # csl_file : "apa.csl" + - i18n: + default_language: pt + languages: + en: + name: English + build: true + site_name: Sociotechnic Protocols + pt: + name: Português + build: true + + nav_translations: + en: + Provedor: Provider + markdown_extensions: - footnotes diff --git a/scripts/provision b/scripts/provision index cf7b5d7..1b0a8af 100755 --- a/scripts/provision +++ b/scripts/provision @@ -13,7 +13,7 @@ DEPENDENCIES="mkdocs apache2 python3-pip pandoc pandoc-citeproc" DEPENDENCIES="$DEPENDENCIES tor python3-requests python3-bs4 python3-socks python3-pybtex python3-tqdm" # PyPI dependencies -DEPENDENCIES_PIP="mkdocs-bibtex mkdocs-material" +DEPENDENCIES_PIP="mkdocs-bibtex mkdocs-material mkdocs-static-i18n" # Ensure an up-to-date system sudo apt-get update && sudo apt-get dist-upgrade -y && sudo apt-get autoremove -y && sudo apt-get clean -- cgit v1.2.3