Feat: i18n

9 files changed, 0 insertions, 534 deletions

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