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
|
[[!meta title="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.
|
