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