From 9ae0b0e661b9c887749f48e11657d720fe7482d0 Mon Sep 17 00:00:00 2001 From: Silvio Rhatto Date: Sat, 10 Dec 2022 13:27:08 -0300 Subject: Fix: convert to MkDocs --- english/network.md | 80 ------------- english/organization.md | 233 ------------------------------------ english/provider.md | 9 -- english/provider/hosting.md | 9 -- english/provider/hosting/letter.md | 59 --------- english/provider/hosting/policy.md | 45 ------- english/provider/hosting/refusal.md | 22 ---- english/provider/hosting/terms.md | 92 -------------- 8 files changed, 549 deletions(-) delete mode 100644 english/network.md delete mode 100644 english/organization.md delete mode 100644 english/provider.md delete mode 100644 english/provider/hosting.md delete mode 100644 english/provider/hosting/letter.md delete mode 100644 english/provider/hosting/policy.md delete mode 100644 english/provider/hosting/refusal.md delete mode 100644 english/provider/hosting/terms.md (limited to 'english') diff --git a/english/network.md b/english/network.md deleted file mode 100644 index 3793d5a..0000000 --- a/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/english/organization.md b/english/organization.md deleted file mode 100644 index 0702bd8..0000000 --- a/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/english/provider.md b/english/provider.md deleted file mode 100644 index 06493c4..0000000 --- a/english/provider.md +++ /dev/null @@ -1,9 +0,0 @@ -# Internet Services Provider - -```eval_rst -.. toctree:: - :maxdepth: 1 - :glob: - - provider/* -``` diff --git a/english/provider/hosting.md b/english/provider/hosting.md deleted file mode 100644 index d6fffb1..0000000 --- a/english/provider/hosting.md +++ /dev/null @@ -1,9 +0,0 @@ -# Hosting - -```eval_rst -.. toctree:: - :maxdepth: 1 - :glob: - - hosting/* -``` diff --git a/english/provider/hosting/letter.md b/english/provider/hosting/letter.md deleted file mode 100644 index 5bfaff4..0000000 --- a/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/english/provider/hosting/policy.md b/english/provider/hosting/policy.md deleted file mode 100644 index 554627e..0000000 --- a/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/english/provider/hosting/refusal.md b/english/provider/hosting/refusal.md deleted file mode 100644 index 7cd4648..0000000 --- a/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/english/provider/hosting/terms.md b/english/provider/hosting/terms.md deleted file mode 100644 index 91b5f3f..0000000 --- a/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 -- cgit v1.2.3