From 629a734be3a5594ee470710f1b4035cd4312f637 Mon Sep 17 00:00:00 2001 From: Silvio Rhatto Date: Fri, 16 Dec 2022 00:27:16 -0300 Subject: Feat: i18n --- docs/social/coletivo/organizacao.en.md | 233 +++++++++++++++++++++++++++++++++ 1 file changed, 233 insertions(+) create mode 100644 docs/social/coletivo/organizacao.en.md (limited to 'docs/social/coletivo') 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. -- cgit v1.2.3