aboutsummaryrefslogtreecommitdiff
path: root/docs/social/coletivo/organizacao.en.md
blob: 0702bd80f88fc95dcca316d16f28fa86f8c3fbf9 (plain)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
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.