diff options
| author | Silvio Rhatto <rhatto@riseup.net> | 2016-05-15 17:55:49 -0300 |
|---|---|---|
| committer | Silvio Rhatto <rhatto@riseup.net> | 2016-05-15 17:55:49 -0300 |
| commit | b1512820107407cf41e12b845201c905ef19370f (patch) | |
| tree | 22a857ddf18883df6170e67f78e44bc1cc6f00a2 /english | |
| parent | 774d8c9f9258b0f68dfad42fac605c76665d76dc (diff) | |
| download | templates-b1512820107407cf41e12b845201c905ef19370f.tar.gz templates-b1512820107407cf41e12b845201c905ef19370f.tar.bz2 | |
Migrating stuff from old trac instance
Diffstat (limited to 'english')
| -rw-r--r-- | english/hosting/letter.mdwn | 63 | ||||
| -rw-r--r-- | english/hosting/policy.mdwn | 49 | ||||
| -rw-r--r-- | english/hosting/refusal.mdwn | 26 | ||||
| -rw-r--r-- | english/hosting/terms.mdwn | 96 | ||||
| -rw-r--r-- | english/organization.mdwn | 122 |
5 files changed, 356 insertions, 0 deletions
diff --git a/english/hosting/letter.mdwn b/english/hosting/letter.mdwn new file mode 100644 index 0000000..b3f35fd --- /dev/null +++ b/english/hosting/letter.mdwn @@ -0,0 +1,63 @@ +[[PageOutline]]
+
+= Hosting Letter =
+
+{{{
+$collective Hosting Letter
+--------------------------
+
+$collective is part of an intersection of various groups that discuss politics and
+technology in different ways. We work with internet servers turned to various
+cooperative goals. Then, our ideia is to colaborate with groups/projects that
+are part of mutual and multiple aid and support.
+
+$collective is an autonomous project kept by a collective of volunteers. One of our
+main goals is the collective creation of public spaces, common areas with projects and
+groups that intend to enforce and straighten coexistence.
+
+Our intention is not just offer a "hosting service" and then we're not available
+for groups that just want such thing. We want that groups we host colaborate with
+the construction of a neighborhood, a rhizome, meaning that technology doesn't have to be
+a barrier, but exactly the opposite. As technology is also a social construction,
+its purposes, its configurations and the processes it interferes with can't
+impose themselves independently of the choices made by the social groups where it's used.
+
+The internet is not only an environment of cooperation, but also of apropriation and
+exploitation of common goods. We understand that it just turns essentially into a
+public space when people can control their production and access means, things that
+don't happen on corporate and governmental spaces. Because of this we try to
+create public spaces, non-corporative and non-governmental and we hope that
+groups we host colaborate to the construction of such spaces.
+
+During the construction of these kind of spaces, we make discussions where we try to
+discover themes such as culture, society, technology, activism, social change
+and many others. Such a research, when possible, is shared pubicly.
+
+We research the political implications of technology and develop systems and
+instruments using different political values. We also keep a political dialogue
+in the logics of theory/practice.
+
+So, one of our proposals is to collectivelly establish a network of mutual
+support among groups and individuals interested in sharing the same physical
+structure to share their knowledges, activities and researches.
+
+We attempt then to break the relation between service provider/clients,
+because we're not service providers and the groups/individuals we host are not
+our clients. We both make part of the same collaboration network where diverse
+interests converge towards mutual empowerment. And who knows if such way of
+organizing things won't spread to other parts of society.
+
+Thinking about knowledge distribution and with an incentive to new groups
+interested in keeping their own server infrastructure, we try to share the most of
+our organization scheme.
+
+And remember: for us, $collective is not just a hosting system or a service provider.
+
+Interesting links:
+
+ - Researches available: http://wiki.$domain
+ - Configurations and operational procedures: http://padrao.$domain
+
+In solidarity,
+$collective Group
+}}}
\ No newline at end of file diff --git a/english/hosting/policy.mdwn b/english/hosting/policy.mdwn new file mode 100644 index 0000000..f51a062 --- /dev/null +++ b/english/hosting/policy.mdwn @@ -0,0 +1,49 @@ +[[PageOutline]]
+
+= Hosting Policy =
+
+{{{
+$collective Group Hosting Policy
+--------------------------------
+
+1. The Collective reserves to istelf the power to host or discontinue the
+ hosting of any group or individual according to the ethical, political and
+ practical principles of the Collective.
+
+2. In the case of hosting discontinuation for a given group, the Collective
+ commits itself to inform the hosted part with sufficient time and to make
+ available the hosted data.
+
+3. Groups and individuals are just hosted by the Collective if they want to
+ have a mutual relation of resources and activity sharing.
+
+4. Once the hosting partnership is created, the Collective must be informed of
+ actions and ways the hosted part is taking if those affects the Collective. By
+ the other hand, the Collective commits to inform the hosted part of anything
+ that can affect it.
+
+5. The terms of partnership must be clear in the sense of the commitment
+ between both sides on support, maintenance and development of the host and
+ sites.
+
+6. The hosted part is responsible for the hosted content and the Collective
+ cannot suffer legal consequences of improper or illegal content. Anyway the
+ Collective will make everything possible to protect the identity and privacy of
+ the hosted part.
+
+7. The relations should be established as transparently as possible, avoiding
+ hidden or manipulated information by both parts.
+
+8. The relations have the purpose of solidarity on knowledge, complementarity
+ on actions and exchange among groups, being vital to achieve ways of mutual
+ teaching-learning and develop policies that unite groups towards social and
+ political changes.
+
+9. The Collective commits itself to inform at least in general ways its
+ security and privacy policies on the hosting platforms.
+
+10. Hosting of social movements with sensitive content are kept, when possible,
+ hosted on platforms abroad.
+
+11. The hosting consists in cooperation and not in service providing.
+}}}
\ No newline at end of file diff --git a/english/hosting/refusal.mdwn b/english/hosting/refusal.mdwn new file mode 100644 index 0000000..b77e24b --- /dev/null +++ b/english/hosting/refusal.mdwn @@ -0,0 +1,26 @@ +[[PageOutline]]
+
+= Refusal hosting letter =
+
+{{{
+Hi $requisitante,
+
+Unfortunatelly we can't host the project you requested because:
+
+ - We think it doesn't match the etical principles we adopt[1].
+
+ - And/or we consider it matches the kind of projects we have a critical
+ position with[2].
+
+We believe that there's not just one way to fight. We also don't believe that
+our etical principles and our criticisms represent the "right" viewpoint.
+Our viewpoint just reflect the conclusions we got after a lot of discussions.
+We try just to be coherent with what we believe and that's the reason why we
+can't accept your request.
+
+We don't want for this statement to mean that we want to give no value for
+the thing your project do or about what do you believe.
+
+[1] See http://encontro.sarava.org/Principal/ConjuntoDePrincipiosEticos
+[2] See http://wiki.$dominio
+}}}
\ No newline at end of file diff --git a/english/hosting/terms.mdwn b/english/hosting/terms.mdwn new file mode 100644 index 0000000..ba2b3a7 --- /dev/null +++ b/english/hosting/terms.mdwn @@ -0,0 +1,96 @@ +[[PageOutline]]
+
+= Hosting Terms =
+
+{{{
+Hi :)
+
+Agreement on Hosting
+--------------------
+
+We discussed and we agree to offer hosting as you requested. Now, in order for we to
+effectivelly maintain this hosting, we need to:
+
+ 1. State what is our commitment in relation to this hosting.
+ 2. That you and/or your group agree with the present term of agreement and
+ with our Hosting Policy.
+
+These are mutual commitment agreements, where we explain what is our commitment
+with the hosting and that the hosted part needs to agree so we can keep such
+relation.
+
+In case you agree with the terms of this letter and accept our Hosting Policy,
+just reply saying so and the hosting will start as soon as possible. :)
+
+Our commitment
+--------------
+
+We commit ourselves to keep the hosting working. The hosting maintenance
+happens through volunteer and responsible work.
+
+The used infra-structure is stable, but subject to eventual power and network
+outages or even more sensitive problems.
+
+Then, sometimes hosting can go offline. We will always be allert and we care
+for security and integrity of the hosted data. But, for a lot of reasons, we
+cannot garantee the total availability or even the eternity of such data.
+
+We commit ourselves as much as possible to keep security copies of the data we
+host. But we ask for you to also arrange, as much as possible, backup copies of
+your data.
+
+Our group is composed by people that do a lot of tasks. The most important and
+sensitive tasks, such as hosting, are dependent to other taks and each one is
+associated to a workgroup of responsible persons.
+
+It may happen that someone leaves a workgroup and eventually some tasks will lack
+commited people to get them accomplished. It's on this sense that we garantee
+hosting: according to the available workforce at our group. It's possible that,
+in the future, something happens and we stop hosting in a given platform.
+But, if we do so, we garantee that it won't happen from night to day and we'll
+give enough time for you and your project to migrate the data somewhere else.
+
+We also have the commitment to inform, when you ask, our procedures according to
+our accounting policy. Such procedures vary from privacy and security policies
+to choices of platforms and our group's situation.
+
+As our procedures can change with time, we recommend you to ask for procedures
+descriptions when you feel necessary.
+
+We have our limitations but we'll keep things working as much as we can. :)
+
+Your commitment
+---------------
+
+We hope that you and/or your project use the offered resource with wisdom.
+Don't ask for websites and tools if you will abandon them. If you install your own
+programs, please have the responsibility to keep it up-to-date as security holes at
+your place can compromise other hosted projects.
+
+Please don't forget that the maintenance of multiple projects needs a lot of work
+and is difficult to keep secure. Then we ask for everyone's collaboration. We would be
+very pleased if you informed us about your plans to install tools in your space. :)
+
+Sharing interfaces
+------------------
+
+A possible space for interactions among projects is the Neighborhood Mailing
+List[1] (subscription just for sufficiently secure mail accounts, get in touch for
+more information). When we host groups and individuals, we hope that they will also
+be responsible in what comes to taking care of such spaces.
+
+Our neighborhood is also a place for articulations, where all groups and
+individuals sharing the same infra-structure can communicate between
+themselves.
+
+If the subjects we research are inspiring for you too, we invite you to
+participate in such discussions. To avoid centralization, we propose you to
+collectivelly discuss with your group and publish the conclusions you
+get. For us it is fundamental to try to build a metodology that makes possible the
+dissemination of such discussions.
+
+[1] $neighborhood_mailing_list_address
+
+In solidarity,
+$grupo Collective
+}}}
\ No newline at end of file diff --git a/english/organization.mdwn b/english/organization.mdwn new file mode 100644 index 0000000..de7b618 --- /dev/null +++ b/english/organization.mdwn @@ -0,0 +1,122 @@ +[[PageOutline]]
+
+= Collective Action Protocol =
+
+The protocol was written to make possible a generic adoption by groups but at the same time it attempt to solve specific problems that aren't necessarily shared by a gvin group. Then, it's not intended to be "The Collective Protocol" but instead a suggestion about how to shape a collective protocol.
+
+Suggestion is to read it as how could a collective protocol look like instead a sugestion of adoption, especially because usually the needs for a process are different as here we're trying to solve a different set of problems.
+
+The Collective Action Protocol seems to be both a stateless (at it's informal part) and stateful (at it's formal part) protocol. It has some inspiration from:
+
+ * Games, altough it's unknow how a parallel with game theory could be traced (could this protocol be considered a game where the objective is a win-win outcome attempting to maximize the collective effort?).
+ * Free and open source software development processes (although this protocol makes the 'benevolent dictator' obsolete as behaviour, purpose and telealogy turns to be mean properties emerging internally from the processes and peoples' wishes and mutual relationship). It can be thought as a social software (culture).
+ * Ways labor division can be organized to better fill collective needs and autonomy while encouraging people to work together.
+
+== Characteristics ==
+
+For sinthetic purposes, most of the discussion was split from the protocol text. Perhaps this compression let a lot of helpful information to be missing, so here comes a list of the main properties this protocol tries to achieve:
+
+ * Resilience, robustness and failover.
+ * Ensure some collective autonomy is guaranteed (through formal process having responsibility attached) while not blocking the self-organizing efforts using to kinds of processes (formal and informal). This means in some way to overcome the [http://en.wikipedia.org/wiki/Tyranny_of_Structurelessness The Tyranny of Structurelessness] while not failing back to over-structuration, bureaucracy, etc and at the same time tries to deal with apathy and missparticipation.
+ * For formal processes, splits decision-making (i.e, the step where the collective evals if a given proposal is pertinent an deserves the collective moral support) from the resposibility assignment (step where people actually volunteer to do the tasks) in a way that just formal processses that are under responsibility can be counted as processes that will very probably happen, so if in the proposal/discussion/decision steps just the content of the proposal is evalued, the responsibility assignment is a filter where just processes that finds people to achieve them are able to pass.
+ * Leting a process be also a registry eases the integration with a ticket system.
+
+== Limitations ==
+
+Some limitations of the protocol are:
+
+ * Not sure whether it's scalable. Maybe it was set for usage inside a small affinity group so it might not fit to big groups where people has not affinity between themselves.
+ * It does not deal with connections/disconnections, i.e, the protocol do not define how someone joins or leaves the group.
+ * As all protocols depends on it's usage, it is not a guarantee by itself that things are going to happen in the collective. The protocol just states how the energy is spent in the collective process but have no influence in the desire to act or not to act.
+ * It does not state what are the communication channels (both for formal and informal communications) and how they should be used. In fact, as this really varies a lot from collective to collective so it was chosen to leave that specific communication structure out of the Collective Action Protocol so it would be easier to share and have another protocol taking care of informational channels.
+
+== Formality and informality ==
+
+In this protocol, what is a formal and what is an informal process really depends in how the collective wants to extend it's autonomy, so it's not a thing defined withing the protocol. Examples of formal and informal processes can be:
+
+ * Informal processes: meetings, dinners, researching, write texts, code, talk with people, wikifarming and everything else that the collective thinks that does not changes the collective autonomy.
+ * Formal processes: the main activities the group is commited to do and what is crucial for them to happen and to keep the collective autonomy.
+
+= Collective Action Protocol =
+
+ * Version: 0.1.
+ * Raw english translation version (related to protocol version): 0.1.
+ * License: Sarava Content Distribution License (no translation for now :/)
+
+== Processes and autonomy ==
+
+Everything that happens in the Collective is a process. Processes has different manifestations but are mainly fluxes and the registry of these fluxes (memory/information).
+
+There are two kinds of processes:
+
+ * Formal processes
+ * Shape/form predefined by collective consensus AND
+ * Needs/use the collective autonomy THUS
+ * Needs to be followed by a minimum responsabilization so the process do not fail
+
+ * Informal processes
+ * Shape/form not needed to be predefined AND
+ * Do not need/use the collective autonomy THUS
+ * Do not need to be under the resposability of someone, i.e, an informal process that do not happen doesn't affect the collective autonomy
+
+Activities without information in the collective cannot be considered by processes (formal or informal) as these activities do not have information equality/isonomy in the collective. To have information about a process is a requisite for participation and then an activity without information inside the collective cannot be considered as process.
+
+The basic autonomy of the Collective, i.e, the minimum autonomy that allows it's existence according to this protocol is the existence of secure and private communication channels that allows the existence of collective processes (formal or informal). Without these channels, the basic collective autonomy is seriously damaged as well as the application of this protocol. All aditional autonomy in the collective (i.e, autonomy that is not contained in the basic autonomy) should be defined with formal processes.
+
+A collective member act inside the collective when use it's resources or the collective name. By the other hand, a collective member act outside of the collective when do not use such resources or the collective name. Collective members do not make actions (inside or outside the collective) that consciouslly can cause damage to the collective autonomy.
+
+== Formal processes ==
+
+Each formal processs is an instance of the following state diagram:
+
+{{{
+ .------------------->-----------------.
+ / .----------<--------------<-------. \
+ | ' \ \
+ | | .------>-----. \ \
+ | | | \ \ \
+ Proposal -----> Discussion ->-. \ \ \
+ | ^ | \ \ \ \
+ | | | \ \ \ \
+ | `----<-----' | \ \ \
+ | | | \ \
+ `------>----- Decision --<--' | \ \
+ | | | \ \
+ | | | | |
+ Responsibility --<---' '------> Archiving --->---' ;
+ Assignment --------->---------' ^ \ /
+ ^ | ___________/ `---<-----'
+ | \ .'
+ | `--> Achievement ->--.
+ | | | \
+ | | | /
+ `----<-----' `-----<---'
+}}}
+
+ * Proposal: step where an idea of a formal process is presented to the collective. The idea ' or description ' can come for the Archive, from a previous Discussion, from an informal process that needs to be formalized or from a person or group from inside or outside the collective. General recomendation is to give a good explanation of the idea containing: deadline sugestion, process life cycle, responsibility assignment criteria and deadline and recomendations for emergencies (when appliable).
+
+ * Discussion:
+ * It's not a mandatory step, but has importance anyway.
+ * Changes to proposals make the formal process go back to the Proposal state. Proposals that do not follow to the Decision step or do not get changes until it's deadline should be archived.
+ * Changed proposals that come from outside the collective or that have external groups or persons participation should be sent back also to the external group/person, despite these persons/groups do not participate in the internal discussion at the collective. If these external people/groups agree with the changed proposal, then the formal process proceeds with the discussion using the changed proposal. If that doesn't happen, i.e, these external people/groups don't agree with the changed proposal, then the formal process is archived (except if the external parties provide another changed proposal or more arguments to the discussion).
+
+ * Decision:
+ * Through consensus and the active participation depends in following the information required by the proposal.
+ * If there's no consensus about the decision of a proposal it's automatically blocked with the possibility to extend it's deadline.
+ * Silence regarding a proposal is considered as an agreement.
+ * Deadline: general recomendation is to set deadlines relative to the average time needed by active people in the collective to take into account, discuss, make changes and ask for eventual postponing. Processes are elegible to postponing or advance it's deadline with an explicitly request from someone from the collective. If there's no such request, the initial deadline is assumed.
+ * Approvals from proposals coming from outside the collective or that have external people/groups involved are communicated about the approval just after the responsibility assignment.
+
+ * Responsibility assignment
+ * Concerns the minimization of points of failure.
+ * Responsibilization is a volunteer action but requires the submission of a commitment/responsibilization term affirming that the person:
+ * Has knowledge about the procedure in question.
+ * Is gonna achieve it under the estimated deadline and is gonna keep the collective informed about the task.
+ * Will inform the collective in a reasonable timeframe if cannot continue to be involved with the process so the collective can keep the process going, assign new responsibilities or finnish it and send to the archive.
+ * Non-accomplishment with a process compromises the ability of someone to be responsible for other tasks.
+ * Formal processes that are approved but, after the responsibility assignment deadline, have unsufficient responsibilization assigned, should be sent to the archive. Proceesses in the archive were previously approved cannot be sent back directly to the responsibilty assigment and should instead go to the proposal step.
+ * In case of proposals coming from outside the collective or that have external people/groups involved, these people/groups should be informed of the approval just after the responsibility assignment, i.e, at the end of this step.
+
+ * Achievement
+ * Just formal processes with sufficient responsibility assignment can go to the achievement step. Processes that were already achived goes to the archive.
+ * Formal processes that were not achieved in the deadline should come back to the Responsibility assignment step. In a similar way, processes whose assigned people cannot doing it should come back to the Responsibility assignment step if the number of assigned people is smaller than the required.
|