Comment des millions de personnes peuvent-elles produire un arbre-texte unique faisant consensus ? : Différence entre versions

De Willforge
Aller à : navigation, rechercher
m (un scenario des étapes ultérieures)
m (Introduction)
(12 révisions intermédiaires par le même utilisateur non affichées)
Ligne 1 : Ligne 1 :
 
== Introduction ==
 
== Introduction ==
Il s'agit de permettre à une communauté de millions d'ordinateurs ou téléphone portables de produire un texte unique faisant consensus.
+
Il s'agit de permettre à une communauté de millions d'ordinateurs ou téléphone portables de produire un texte unique faisant consensus, par exemple sa charte.
  
Le protocole que nous proposons est construit sur le schéma suivant :
+
Le protocole que nous proposons repose sur un idée simple : laissons tous ceux qui le veulent écrire leur version du texte et utilisons internet pour extraire la meilleure.
* chacun peut de produire librement sa version du texte c'est un contributeur qui est aussi examinateur pour les versions des autres.
+
* chacun peut évaluer une version du texte sans la modifier, c'est un examinateur.
+
* les millions de versions seront distribuées par paquets de 10 aux millions d'examinateurs.
+
* chaque contributeur n'aura donc que 10 textes à évaluer.
+
* l’algorithme de distribution doit garantir que chaque version du texte aura été examinée par le même nombre d'examinateur différents.
+
* chaque examinateur note chacune des 10 versions qu'il examine.
+
* pour chaque version on calcule sa note moyenne sur l'ensemble des examinateurs.
+
* on regroupe toutes les versions qui ont eu la plus forte note moyenne.
+
* on recommence sur cet ensemble réduit de textes jusqu'à n'en avoir qu'un seul.
+
  
On peut imaginer des variations de ce schéma. En particulier il est souhaitable de se mettre d'accord sur le contenu du texte commun avant de commencer sa rédaction. Ceci peut être fait dans une étape préliminaire ou simultanément.
+
Supposons d'une part que les millions de membres de la communauté soient enregistrés dans une base de données et que d'autre part, les millions de versions de la charte soient elles aussi enregistrées dans une base de données.
  
== tout passe par internet ==
+
Supposons que chaque membre de la communauté ne puisse examiner confortablement que 10 versions concurrentes de la charte à la fois et attribuer une note à chacune d'elles.
Il s'agit de satisfaire les conditions suivantes:
+
 
 +
Comme il est impossible que chaque membre de la communauté prenne connaissance de toutes les versions, on va construire des paquets d'une dizaine de versions prises au hasard dans leur base de données et les distribuer au hasard parmi les membres de la communauté afin qu'ils notent chacune d'elle. L'algorithme utilisé doit être tel que chaque membre de la communauté ait reçu une dizaine de versions et que chaque version ait reçu un nombre de notes à peu près égal et supérieur à un minimum.
 +
 
 +
A la fin de cette étape on calcule la moyenne obtenue par chaque version. Celles qui ont obtenu la note maximum sont extraites et redistribuées par paquet parmi les membres comme précédemment : c'est la deuxième étape.
 +
 
 +
Si le nombre de versions est très grand, le nombre de notes par version sera faible et la moyenne peu discriminante, on pourra alors relancer une première étape avec une nouvelle distribution des versions parmi les membres et améliorer la moyenne. 
 +
 
 +
La procédure de notation peut être adaptée afin d'éviter les ex-aequo et faire en sorte qu'à chaque étape la proportion de versions retenues diminue notablement.
 +
 
 +
En itérant on obtiendra une ou quelques versions parmi les millions de départ.
 +
 
 +
On peut imaginer des variations de ce schéma. En particulier il est souhaitable de se mettre d'accord sur le contenu du texte commun avant de commencer sa rédaction. Ceci peut être fait dans une étape préliminaire ou simultanément (voir [[#construire le but d'un texte à rédiger]]).
 +
 
 +
Il s'agit donc de satisfaire les conditions suivantes:
 
* chaque participant a le même droit d'intervenir pour proposer un texte ou une modification d'un texte en cours de rédaction.
 
* chaque participant a le même droit d'intervenir pour proposer un texte ou une modification d'un texte en cours de rédaction.
 
* chacun a le même droit droit d'évaluer une proposition par une note ou un vote.
 
* chacun a le même droit droit d'évaluer une proposition par une note ou un vote.
Ligne 22 : Ligne 26 :
 
* chaque proposition doit avoir été examinée par un nombre identique de participants à l'unité près.
 
* chaque proposition doit avoir été examinée par un nombre identique de participants à l'unité près.
  
== on définit un but pour le texte ==
+
== construire le but d'un texte à rédiger ==
 
Lorsqu'une communauté désire écrire un texte commun (appel, charte, manifeste, constitution, texte de loi, ...) c'est toujours dans un certain but. Bien que chaque participant ait sa propre idée du but du texte, celui-ci ne fait jamais l'objet d'une décision collective préalable à la rédaction. Ceci conduit à des conflits, des mal-entendus et une production anarchique de textes très similaires (Voir par exemple la floraison des chartes du mouvement Nuit Debout), car aucun garde-fou n'existe pour encadrer les rédactions vers une volonté commune.
 
Lorsqu'une communauté désire écrire un texte commun (appel, charte, manifeste, constitution, texte de loi, ...) c'est toujours dans un certain but. Bien que chaque participant ait sa propre idée du but du texte, celui-ci ne fait jamais l'objet d'une décision collective préalable à la rédaction. Ceci conduit à des conflits, des mal-entendus et une production anarchique de textes très similaires (Voir par exemple la floraison des chartes du mouvement Nuit Debout), car aucun garde-fou n'existe pour encadrer les rédactions vers une volonté commune.
  
Ligne 61 : Ligne 65 :
 
Chaque noeud d'un sous-arbre est défini par son '''identificateur''' unique '''arbre_id''', son titre,  sa date de création. sa version, la clé publique de son créateur, sa shasum et la liste des '''arbre_id''' de ses fils.
 
Chaque noeud d'un sous-arbre est défini par son '''identificateur''' unique '''arbre_id''', son titre,  sa date de création. sa version, la clé publique de son créateur, sa shasum et la liste des '''arbre_id''' de ses fils.
  
== le protocole synchrone de validation d'une proposition par un groupe restreint ==
+
== le protocole synchrone de validation d'une proposition par un jury restreint ==
 
Dans le cas où une note a du sens, il suffit de collecter les notes attribuées par chaque individu sur chaque proposition et d'en calculer des moyennes ou d'autres valeurs.
 
Dans le cas où une note a du sens, il suffit de collecter les notes attribuées par chaque individu sur chaque proposition et d'en calculer des moyennes ou d'autres valeurs.
  
 
Il existe des situations pour lesquelles il est nécessaire de juger de la validité d'une proposition.  
 
Il existe des situations pour lesquelles il est nécessaire de juger de la validité d'une proposition.  
  
Par exemple, on peut vouloir juger de la cohérence des assertions d'un but de texte, de la non ambiguïté des termes des assertions d'un but, de la conformité d'un texte avec son but.  
+
Par exemple, on peut vouloir juger de la cohérence des assertions du but d'un texte, de la non ambiguïté des termes des assertions de ce but, de la conformité d'un texte avec son but.  
  
Dans ces cas un vote ou une note n'aurait pas de sens, il faut qu'un consensus se dégage sur la validité de la proposition.
+
Dans ces cas, un vote ou une note n'aurait pas de sens, il faut qu'un consensus se dégage sur la validité de la proposition.
  
Une solution simple, consiste à réunir sur un canal Mumble un petit groupe de participants tirés au sort, dont on suppose a priori la neutralité quant à l'issue du résultat.
+
Une solution simple, consiste à réunir sur un canal Mumble un petit jury de participants tirés au sort, dont on suppose a priori la neutralité quant à l'issue du résultat.
 
+
# Chaque élément du groupe est relié aux autres par un canal Mumble (limité à 12).
+
# Le groupe tire au sort un président.
+
# Le président veille aux bonnes pratiques.
+
# Le président tire au sort un participant
+
# le participant formule le raisonnement qui le conduit à juger une proposition comme valide ou invalide.
+
# le groupe accepte ou refuse ce jugement.
+
 
+
== le protocole synchrone de rédaction collaborative d'une proposition par un groupe restreint ==
+
  
 
# Chaque élément du groupe est relié aux autres par un canal Mumble (limité à 12).  
 
# Chaque élément du groupe est relié aux autres par un canal Mumble (limité à 12).  
Ligne 272 : Ligne 267 :
 
== la dernière étape ==
 
== la dernière étape ==
  
Ce processus est double : il fait co-évoluer le texte et sa finalité en maintenant leur liaison formelle.
+
Ce processus est double : il fait co-évoluer le texte et son but en maintenant le texte conforme à son but.
  
 
La version du texte produite par ce processus est unique et conforme à la volonté générale de la communauté exprimée dans le but.
 
La version du texte produite par ce processus est unique et conforme à la volonté générale de la communauté exprimée dans le but.
  
Un tel processus est d'autant plus efficace que le nombre de participants est grand. En effet plus il y a de participants plus il y a de chance de trouver les meilleurs formulation, les plus consensuelles, pour le but et pour le texte.
+
Un tel processus est d'autant plus efficace que le nombre de participants est grand. En effet plus il y a de participants plus il y a de chance de trouver les meilleurs formulations, les plus consensuelles, pour le but et pour le texte.
 +
 
 +
 
 +
== discussions associées ==
 +
On peut ajouter un site de chat ou autre permettant les discussions. Ou le deliberatorium du MIT.

Version du 12 juillet 2019 à 10:25

Introduction

Il s'agit de permettre à une communauté de millions d'ordinateurs ou téléphone portables de produire un texte unique faisant consensus, par exemple sa charte.

Le protocole que nous proposons repose sur un idée simple : laissons tous ceux qui le veulent écrire leur version du texte et utilisons internet pour extraire la meilleure.

Supposons d'une part que les millions de membres de la communauté soient enregistrés dans une base de données et que d'autre part, les millions de versions de la charte soient elles aussi enregistrées dans une base de données.

Supposons que chaque membre de la communauté ne puisse examiner confortablement que 10 versions concurrentes de la charte à la fois et attribuer une note à chacune d'elles.

Comme il est impossible que chaque membre de la communauté prenne connaissance de toutes les versions, on va construire des paquets d'une dizaine de versions prises au hasard dans leur base de données et les distribuer au hasard parmi les membres de la communauté afin qu'ils notent chacune d'elle. L'algorithme utilisé doit être tel que chaque membre de la communauté ait reçu une dizaine de versions et que chaque version ait reçu un nombre de notes à peu près égal et supérieur à un minimum.

A la fin de cette étape on calcule la moyenne obtenue par chaque version. Celles qui ont obtenu la note maximum sont extraites et redistribuées par paquet parmi les membres comme précédemment : c'est la deuxième étape.

Si le nombre de versions est très grand, le nombre de notes par version sera faible et la moyenne peu discriminante, on pourra alors relancer une première étape avec une nouvelle distribution des versions parmi les membres et améliorer la moyenne.

La procédure de notation peut être adaptée afin d'éviter les ex-aequo et faire en sorte qu'à chaque étape la proportion de versions retenues diminue notablement.

En itérant on obtiendra une ou quelques versions parmi les millions de départ.

On peut imaginer des variations de ce schéma. En particulier il est souhaitable de se mettre d'accord sur le contenu du texte commun avant de commencer sa rédaction. Ceci peut être fait dans une étape préliminaire ou simultanément (voir #construire le but d'un texte à rédiger).

Il s'agit donc de satisfaire les conditions suivantes:

  • chaque participant a le même droit d'intervenir pour proposer un texte ou une modification d'un texte en cours de rédaction.
  • chacun a le même droit droit d'évaluer une proposition par une note ou un vote.
  • le nombre de propositions examinées par chaque participant doit être le même à l'unité près.
  • chaque proposition doit avoir été examinée par un nombre identique de participants à l'unité près.

construire le but d'un texte à rédiger

Lorsqu'une communauté désire écrire un texte commun (appel, charte, manifeste, constitution, texte de loi, ...) c'est toujours dans un certain but. Bien que chaque participant ait sa propre idée du but du texte, celui-ci ne fait jamais l'objet d'une décision collective préalable à la rédaction. Ceci conduit à des conflits, des mal-entendus et une production anarchique de textes très similaires (Voir par exemple la floraison des chartes du mouvement Nuit Debout), car aucun garde-fou n'existe pour encadrer les rédactions vers une volonté commune.

Par contre si la communauté, avant toute rédaction d'un texte, se met d'accord sur une vision commune de sa finalité et l'exprime clairement, cela assurera que toute contribution corresponde bien à cette vision.

Le but permet aussi de donner un cadre précis à la forme du document pour en assurer l'homogénéité.

Une méthode simple consiste à rédiger le but sous forme d'une liste d'assertions cohérentes, aux textes clairs, à la terminologie précise et non ambiguë (les termes ambigus seront définis). On remarquera que ceci correspond aux principes fondateurs de Wikipédia qui donnent un cadre strict au contenu et à la forme des articles de l'encyclopédie, permettant que des contributions anonymes deviennent pertinentes et restent cohérentes.

La liste des assertions encadrant la rédaction du texte répondront par exemple aux questions suivantes:

  1. à qui s'adresse le texte ?
  2. quel problème résout-t-il ?
  3. quelle méthode est-elle proposée pour la solution ?
  4. quel est le plan du texte ?

Dans le cas où il s'agit d'écrire un texte de loi, la liste d'assertions deviendra l'exposé des motifs.

Cette liste d'assertions constitue une définition du texte à produire. Elle pourra évoluer au cours du temps quand les intentions de la communauté se préciseront, tout en gardant sa cohérence. puisqu'il s'agit se suivre l'évolution d'un même texte. Si une nouvelle assertion venait rompre cette cohérence en entrant en contradiction avec l'une des assertions existantes elle serait éliminée.

Le but est construit en utilisant une variante du protocole de rédaction collaborative d'un texte.

Le but d'un texte est enregistré dans la base de données des buts.

le texte est structuré comme un arbre

Le texte à produire est organisé selon une hiérarchie d'éléments:

  1. le sommet de l'arbre est le texte.
  2. le texte se subdivise en domaines.
  3. chaque domaine se subdivise en sections.
  4. chaque sections se subdivise en paragraphes
  5. chaque paragraphe se subdivise en alinéas
  6. chaque alinéa se subdivise en phrases.
  7. chaque phrase du texte est une feuille.

Chaque élément du texte est intégré dans un contexte : l'élément de niveau immédiatement supérieur (le noeud père dans l'arbre). Dans le cas où un élément n'a pas de frère, son contexte est le premier sous-arbre contenant d'autres branches que la branche courante.

La rédaction d'un sous-arbre consiste à ajouter un titre, à la rédaction de ses sous-arbres fils. La rédaction des feuilles consiste à écrire des phrases.

Chaque noeud d'un sous-arbre est défini par son identificateur unique arbre_id, son titre, sa date de création. sa version, la clé publique de son créateur, sa shasum et la liste des arbre_id de ses fils.

le protocole synchrone de validation d'une proposition par un jury restreint

Dans le cas où une note a du sens, il suffit de collecter les notes attribuées par chaque individu sur chaque proposition et d'en calculer des moyennes ou d'autres valeurs.

Il existe des situations pour lesquelles il est nécessaire de juger de la validité d'une proposition.

Par exemple, on peut vouloir juger de la cohérence des assertions du but d'un texte, de la non ambiguïté des termes des assertions de ce but, de la conformité d'un texte avec son but.

Dans ces cas, un vote ou une note n'aurait pas de sens, il faut qu'un consensus se dégage sur la validité de la proposition.

Une solution simple, consiste à réunir sur un canal Mumble un petit jury de participants tirés au sort, dont on suppose a priori la neutralité quant à l'issue du résultat.

  1. Chaque élément du groupe est relié aux autres par un canal Mumble (limité à 12).
  2. Le groupe tire au hasard un président.
  3. Le président veille aux bonnes pratiques.
  4. Le président tire au sort un rédacteur.
  5. Le rédacteur propose une modification.
  6. Le groupe accepte ou refuse la modification.
    1. Si la modification est acceptée elle est enregistrée dans la base de données du groupe.
    2. Sinon elle n'est pas enregistrée.
  7. Le président tire au sort un nouveau rédacteur parmi ceux qui n'ont pas encore participé.
  8. Quand tout le monde a participé chacun note les propositions.
  9. La proposition ayant le meilleure score est la seule retenue.

le protocole asynchrone de rédaction collaborative d'une proposition

A un instant donne l'arbre-texte à rédiger est dans un certain état. Il existe des sous-arbres, en attente de rédaction, qui on un titre amis dont la shasum et la liste des sous-arbres fils est vide.

initialisation de la rédaction d'un texte

Une fois le but du texte rédigé, la rédaction de l'arbre-texte peut commencer.

La rédaction de l'arbre de même que celle de ses sous-arbres commence par le titre et se poursuit en descendant la hiérarchie jusqu'aux phrase-feuilles, éventuellement en sautant une étape intermédiaire.

  1. deux arbres peuvent avoir le même titre dans la base de données des arbre-textes.
  2. deux arbres peuvent avoir le même but : ce sont des variantes.
  3. toute intervention sur un arbre-texte doit suivre les injonctions de son but.
  4. chaque état d'un arbre-texte est enregistré dans une base de données définie par un identificateur non-modifiable, un titre modifiable et la shasum du sous-arbre correspondant.
  5. chaque noeud de l'arbre reçoit un identificateur unique.
  6. chaque sous-arbre peut avoir plusieurs versions repérées par un identificateur unique.
  7. chaque version d'un sous-arbre est enregistrée en totalité.
  8. les modifications d'un arbre ne doivent pas être simultanées : il existe un système de verrouillage (lock).
  1. lorsqu'un noeud se connecte au réseau il reçoit un identificateur unique stocké dans la base de données des participants.
  2. lorsqu'un noeud sort du réseau il est noté comme absent dans la base de données.
  3. à un instant donné il existe un certain nombre de noeuds présents.
  4. un instant donné il existe un certain nombre de versions différentes de l'arbre-texte, plus ou moins avancées, dont les états ont été enregistrés dans la base de données correspondante.
  5. on répartit de façon la plus égale possible des bouquets de 10 versions d'un même sous-arbre parmi des participants actifs.
  6. on répartit de même les versions des arbres ou des sous-arbres parmi les noeuds connectés ou non.

shasum d'un sous-arbre

un sous-arbre est sérialisé en une chaîne de caractères ponctuée par des accolades délimitant chaque noeud.

Ainsi l'arbre :

    A
  / | \
 C  D  E
 / / \
F  G  H

est sérialisé en A{ {C{{F}}} {D{{G} {H} } } {E} } la séquence {X }{Y } délimite deux frères X et Y.

La clé de hachage sha notée shasum d'un noeud ou d'un sous-arbre est obtenue par application de l'algorithme de hachage à la chaîne sérialisée.

action asynchrone de notation

  1. en analysant la base de données des examens le réseau construit une liste des arbres à examiner.
  2. en analysant la base de données des participants le réseau construit une liste d'examinateurs.
  3. le réseau tire au sort 10 (ou moins) versions concurrentes parmi les arbres à examiner et les communique à l'un des examinateur tiré au sort pour qu'il en prenne connaissance.
  4. lors de l'examen d'un arbre-texte trois cas peuvent se produire :
    1. l'examinateur attribue une note à l'arbre-textes, sans le modifier. L'identificateur de l'arbre, la clé publique de l'examinateur, la note et la date sont enregistrés dans la base de données des examens.
    2. l'examinateur modifie le texte de l'arbre-texte mais ne modifie pas son but. Ces modifications créent une nouvelle version de l'arbre-texte, enregistrée comme nouvelle entrée dans la base de données des arbre-textes. Elle sera examinée ultérieurement par d'autres noeuds.
    3. l'examinateur modifie le but de l'arbre-texte mais ne modifie pas le texte. Ces modifications créent une nouvelle version du but, enregistrée comme nouvelle entrée dans la base de données des buts des textes dans l'attente de création d'un texte associé.
    4. l'examinateur modifie le texte de l'arbre-texte ainsi que son but. Ces modifications créent une nouvelle version de l'arbre-texte, enregistrée comme nouvelle entrée dans la base de données des arbre-textes et une nouvelle version du but, enregistrée comme nouvelle entrée dans la base de données des buts des textes.

la liste de arbres à examiner

En interrogeant la base de données des examens, le réseau peut calculer le nombre d'examens subis par un arbre. Tant qu'il existera des arbres ayant subi moins d'examens que d'autres, le réseau continuera à les distribuer au hasard parmi de nouveaux examinateurs pris eux aussi au hasard. Le processus s'arrêtera quand tous les arbres auront été examinés par un même nombre d'examinateurs différents (ou éventuellement, lorsque le nombre d'examens aura atteint une certaine limite)

vérification de la cohérence du but

Quand un but est modifié il est nécessaire de vérifier un certain nombre d'invariants :

  1. le but d'un texte est une liste d'assertions.
    1. une assertion est une proposition soit vraie soit fausse.
    2. une assertion ne contient pas de conjonction (deux assertions consécutives remplacent la conjonction).
  2. les assertions d'un but doivent former un système cohérent.
  3. le texte d'une assertion est dépourvu d’ambiguïté.
    1. si un terme est ambigu sa définition est ajoutée entre parenthèse au texte de l'assertion.

Un protocole spécifique est utilisé pour faire cette vérification.

  1. on peut convoquer une réunion synchrone de prise de décision collective

vérification de la conformité au but

Il est nécessaire de vérifier la conformité d'un arbre-texte avec son but.

Ceci est effectué par le #le protocole synchrone de prise de décision collaborative par un groupe restreint

bases de données

Le base de données doivent se comporter comme des blockchains.

base de données des buts des textes

  • block courant :
{
 but_id : number (unique),
 version : number,
 type de l'intervention : string,
 date de l'intervention : date,
 clé publique de l'intervenant : string,
 date de création/modification : date,
 shasum de la version précédente : string;
 shasum : string (unique),
 liste des assertions : [{assertion : string}]
}

base de données des arbre-textes

  • block courant :
{
 arbre_id : number (unique),
 version : number,
 type de l'intervention : string (création, modification, notation),
 date de l'intervention : date,
 clé publique de l'intervenant : string,
 shasum de la version précédente : string;
 shasum de l'arbre : string (unique),
 arbre : {
   but_id : number,
   titre : string (unique),
   sous-arbres : [arbre_id]
   }
}

Pour une feuille, le titre est le texte, la shasum est celle du texte et la liste des sous-arbres est vide []

base de données des examens

  • block courant :
{
 examen_id : number,
 arbre_id: number,
 clé publique de l'intervenant : string,
 note : number,
 date : date,
 shasum de la version précédente : string;
}

base de données des participants

  • block courant :
{
 cle_publique: string,
 adresse mail : string@string.string,
 examens : [{examen_id : string}],
 shasum de la version précédente : string;
}

scenario n°1 de connexion au réseau

  • je me connecte au réseau en allant à l'adresse http://reseau_deliberant.fr
  • je donne mon adresse mail
  • je donne ma clé publique
  • je reçois 10 versions du texte à examiner et les textes de leurs buts.
  • pour chaque version:
    • je vérifie qu'elle est bien conforme à son but.
      • si conforme : je donne une note à cette version.
      • si non conforme je demande une évaluation de conformité par le protocole de vérification de la conformité au but.
        • j'affine le but pour mieux l'adapter à la version du texte.
    • je publie les notes sur le réseau qui les enregistre dans la base de données des examens
    • éventuellement : je crée une nouvelle version par modification de la version courante qui sera ajoutée à la base de données des arbre-textes

Au cours d'une connexion, un internaute peut:

  • noter les 10 versions sans les modifier.
  • demander la vérification de conformité au but d'une ou de plusieurs des 10 versions.
  • créer une nouvelle version qui propose une modification du texte
  • créer une nouvelle version qui propose une modification du but
  • créer une nouvelle version qui propose une modification conjointe du but et du texte

un scenario de la première étape

  • on fixe une limite de temps pour la première étape.
  • éventuellement on fixe une limite au nombre d'examens
  • un participant se connecte au réseau et commence la rédaction du but du texte et simultanément celle du texte.
  • un participant se connecte au réseau et vérifie la conformité du texte au but.
  • des participants se connectent au réseau continuent la rédaction du but et/ou commencent la rédaction du texte conformément au but.
  • des participants se connectent au réseau selon le scenario n° 1
  • lorsque toutes les versions ont été examinées par un même nombre de participants fin de l'étape :
    • avec la base de données des examens on extrait la liste des notes ayant reçue la note maximale. Ces versions serviront de bases à l'étape 2.

un scenario des étapes ultérieures

  • à chaque nouvelle étape on crée une nouvelle base de données des arbre-textes à partir des versions lauréates de l'étape précédente.
  • on itère le processus jusqu'à atteindre le critère d'arrêt.

la dernière étape

Ce processus est double : il fait co-évoluer le texte et son but en maintenant le texte conforme à son but.

La version du texte produite par ce processus est unique et conforme à la volonté générale de la communauté exprimée dans le but.

Un tel processus est d'autant plus efficace que le nombre de participants est grand. En effet plus il y a de participants plus il y a de chance de trouver les meilleurs formulations, les plus consensuelles, pour le but et pour le texte.


discussions associées

On peut ajouter un site de chat ou autre permettant les discussions. Ou le deliberatorium du MIT.