Colonizzare la noosfera/Conflitti e risoluzioni: differenze tra le versioni

Da Wikisource.
CandalBot (discussione | contributi)
m Bot: creazione area dati
m Ha protetto "Colonizzare la noosfera/Conflitti e risoluzioni": Bot: protezione testi riletti ([edit=autoconfirmed] (infinito) [move=autoconfirmed] (infinito))
(Nessuna differenza)

Versione delle 20:36, 1 nov 2011

Conflitti e risoluzioni

../Struttura e proprietà di un progetto ../Meccanismi d'acculturazione e connessioni con il mondo accademico IncludiIntestazione 20 luglio 2008 100% Open Source

Eric Steven Raymond - Colonizzare la noosfera (1998)
Traduzione dall'inglese di Bernardo Parrella (1999)
Conflitti e risoluzioni
Struttura e proprietà di un progetto Meccanismi d'acculturazione e connessioni con il mondo accademico


Abbiamo visto come all’interno dei progetti, la crescente complessità dei ruoli venga espressa tramite la distribuzione dell’autorità per il design e dei parziali diritti di proprietà. Mentre ciò appare un modo efficace per la circolazione degli incentivi, al contempo provoca la diluizione dell’autorità del leader – fatto ancor più importante, tende a stemperare la sua autorità nei frangenti relativi al blocco di potenziali conflitti.

Pur se le questioni tecniche relative al design sembrano costituire i maggiori rischi per conflittualità interne, raramente questi casi portano a seri litigi. In genere vengono facilmente risolti seguendo la regola territoriale per cui l’autorità fa seguito alla responsabilità.

Un altro modo di risoluzione dei conflitti è per anzianità – nel caso di disputa obiettivamente irrisolvibile tra due collaboratori o gruppi di collaboratori, dove nessuno dei due sia proprietario del territorio in cui essa avviene, vince la parte che ha dedicato maggior tempo e lavoro al progetto nel suo insieme (ovvero, la parte che detiene più diritti di proprietà nell’intero progetto).

In genere queste regole risultano sufficienti per risolvere la maggior parte delle dispute relative a un progetto. Quando ciò non sia possibile, normalmente è l’autorità del leader a risolvere la questione. Sono assai rari i conflitti che sopravvivono a entrambi questi filtri.

Normalmente i conflitti non divengono faccenda seria a meno che questi due criteri (“l’autorità fa seguito alla responsabilità” e “vince il più anziano”) tendano verso direzioni opposte, mentre l’autorità del leader risulta debole o assente. Il caso più comune in cui ciò può verificarsi è una disputa per la successione che insorge a seguito della scomparsa del leader del progetto. Mi è capitato di trovarmi coinvolto in un litigio di questo tipo. È stato qualcosa di amaro, penoso, interminabile, risoltosi soltanto quando tutte le parti coinvolte furono talmente esauste da decidere di passare volentieri il controllo a una persona esterna. Spero devotamente di non dovermi mai più trovare in qualcosa di simile.

In conclusione, tutti questi meccanismi per la risoluzione dei conflitti poggiano sulla volontà di applicarli da parte della comunità hacker nel suo insieme. Gli unici meccanismi a disposizione per imporli sono le “flame” e l’allontanamento – condanne pubbliche di quanti hanno infranto le convenzioni, e successivo rifiuto a cooperare ulteriormente con loro.