diff options
Diffstat (limited to 'docs/social/coletivo/organizacao.en.md')
| -rw-r--r-- | docs/social/coletivo/organizacao.en.md | 60 |
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
|