diff options
Diffstat (limited to 'docs/english')
| -rw-r--r-- | docs/english/README.md | 1 | ||||
| -rw-r--r-- | docs/english/network.md | 80 | ||||
| -rw-r--r-- | docs/english/organization.md | 233 | ||||
| -rw-r--r-- | docs/english/provider/README.md | 1 | ||||
| -rw-r--r-- | docs/english/provider/hosting/README.md | 1 | ||||
| -rw-r--r-- | docs/english/provider/hosting/letter.md | 59 | ||||
| -rw-r--r-- | docs/english/provider/hosting/policy.md | 45 | ||||
| -rw-r--r-- | docs/english/provider/hosting/refusal.md | 22 | ||||
| -rw-r--r-- | docs/english/provider/hosting/terms.md | 92 |
9 files changed, 534 insertions, 0 deletions
diff --git a/docs/english/README.md b/docs/english/README.md new file mode 100644 index 0000000..8a8e033 --- /dev/null +++ b/docs/english/README.md @@ -0,0 +1 @@ +# English Templates diff --git a/docs/english/network.md b/docs/english/network.md new file mode 100644 index 0000000..3793d5a --- /dev/null +++ b/docs/english/network.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/english/organization.md b/docs/english/organization.md new file mode 100644 index 0000000..0702bd8 --- /dev/null +++ b/docs/english/organization.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/english/provider/README.md b/docs/english/provider/README.md new file mode 100644 index 0000000..44fc700 --- /dev/null +++ b/docs/english/provider/README.md @@ -0,0 +1 @@ +# Internet Services Provider diff --git a/docs/english/provider/hosting/README.md b/docs/english/provider/hosting/README.md new file mode 100644 index 0000000..6d34898 --- /dev/null +++ b/docs/english/provider/hosting/README.md @@ -0,0 +1 @@ +# Hosting diff --git a/docs/english/provider/hosting/letter.md b/docs/english/provider/hosting/letter.md new file mode 100644 index 0000000..5bfaff4 --- /dev/null +++ b/docs/english/provider/hosting/letter.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/english/provider/hosting/policy.md b/docs/english/provider/hosting/policy.md new file mode 100644 index 0000000..554627e --- /dev/null +++ b/docs/english/provider/hosting/policy.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/english/provider/hosting/refusal.md b/docs/english/provider/hosting/refusal.md new file mode 100644 index 0000000..7cd4648 --- /dev/null +++ b/docs/english/provider/hosting/refusal.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/english/provider/hosting/terms.md b/docs/english/provider/hosting/terms.md new file mode 100644 index 0000000..91b5f3f --- /dev/null +++ b/docs/english/provider/hosting/terms.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
|