diff options
Diffstat (limited to 'docs/social/coletivo/organizacao.en.md')
| -rw-r--r-- | docs/social/coletivo/organizacao.en.md | 233 |
1 files changed, 233 insertions, 0 deletions
diff --git a/docs/social/coletivo/organizacao.en.md b/docs/social/coletivo/organizacao.en.md new file mode 100644 index 0000000..0702bd8 --- /dev/null +++ b/docs/social/coletivo/organizacao.en.md @@ -0,0 +1,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.
|