Atualizações diversas

1 files changed, 27 insertions, 33 deletions

diff --git a/docs/social/coletivo/organizacao.en.md b/docs/social/coletivo/organizacao.en.md
index 0702bd8..197470b 100644
--- a/docs/social/coletivo/organizacao.en.md
+++ b/docs/social/coletivo/organizacao.en.md
@@ -2,18 +2,18 @@
 

 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"

+shared by a given 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

+suggestion 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

+* Games, although it's unknown 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

@@ -24,10 +24,9 @@ from:
 * Ways labor division can be organized to better fill collective needs and

   autonomy while encouraging people to work together.

 

-Characteristics

----------------

+## Characteristics

 

-For sinthetic purposes, most of the discussion was split from the protocol

+For synthetic 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:

 

@@ -42,15 +41,14 @@ so here comes a list of the main properties this protocol tries to achieve:
 * 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

+  volunteer to do the tasks) in a way that just formal processes 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

+  the proposal is evaluated, 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.

+* Letting a process be also a registry eases the integration with a ticket system.

 

-Limitations

------------

+## Limitations

 

 Some limitations of the protocol are:

 

@@ -70,8 +68,7 @@ Some limitations of the protocol are:
   would be easier to share and have another protocol taking care of

   informational channels.

 

-Formality and informality

--------------------------

+## 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

@@ -81,18 +78,16 @@ 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

+* Formal processes: the main activities the group is committed to do and what is

   crucial for them to happen and to keep the collective autonomy.

 

-Collective Action Protocol

---------------------------

+## 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 

-----------------------

+### 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

@@ -123,19 +118,18 @@ 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

+additional 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.

+consciously can cause damage to the collective autonomy.

 

-Formal processes

-----------------

+### Formal processes

 

-Each formal processs is an instance of the following state diagram:

+Each formal process is an instance of the following state diagram:

 

        .------------------->-----------------.

       /  .----------<--------------<-------.  \

@@ -163,9 +157,9 @@ Each formal processs is an instance of the following state diagram:
   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).

+  recommendation is to give a good explanation of the idea containing: deadline

+  suggestion, process life cycle, responsibility assignment criteria and

+  deadline and recommendations for emergencies (when applicable).

 

 * Discussion:

     * It's not a mandatory step, but has importance anyway.

@@ -189,10 +183,10 @@ Each formal processs is an instance of the following state diagram:
     * 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

+    * Deadline: general reccomendation 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

+      are eligible 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

@@ -208,14 +202,14 @@ Each formal processs is an instance of the following state diagram:
           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

+          the process going, assign new responsibilities or finish 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

+      assignment deadline, have insufficient responsibilization assigned,

+      should be sent to the archive. Processes in the archive were previously

+      approved cannot be sent back directly to the responsibilty assignment 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

@@ -224,7 +218,7 @@ Each formal processs is an instance of the following state diagram:
 

 * Achievement

     * Just formal processes with sufficient responsibility assignment can go to

-      the achievement step. Processes that were already achived goes to the

+      the achievement step. Processes that were already achieved 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