EchecModification

Cette page a démarré sur ChangeFailure

"L'EchecModification" se déroule quand le monde change plus vite que le ProcessusIntelligence? apte à intégrer les modifications à l'intérieur de sa DatabaseIntelligence?. C'est un cas particulier d'EchecIntelligence.

Echec Modification et Documentation

Supposons que vous produisiez un wiki pour documenter un programme que vous écrivez. Vous écrivez quelques morceaux de votre programme, puis le documentez au fur et à mesure de vos idées. Vous écrivez plus et documentez plus. Ecrire, documenter, écrire, documenter. Puis vous avez quelques idées et vous documentez encore bien plus.

Votre ProcessusIntelligence? écrit de la documentation pendant que vous écrivez du code et pensez aux idées.

Votre DatabaseIntelligence? est votre DatabasePage de wiki. Elle rassemble vos idées à propos de votre programme de telle façon que vous pouvez disposer de la bonne information au moment où vous en avez besoin – bien plus rapidement et mieux organisée que lire actuellement dans le code source.

Ecrire de la documentation fonctionne et c'est bien.

Mais après deux jours, vous trouvez que vous avez programmé vous-même dans votre coin et allez devoir effectuer un changement fondamental. Le temps de modifier le code est de seulement 5 minutes, mais vous avez maintenant des heures de travail documentaire à faire. Vous devez vérifier toutes vos pages et retirer toutes les références à la vieille structure et les mettre à jour vers des notes à propos de la nouvelle structure.

C'est un cas d'échec de modification. Le monde a changé plus vite que la capacité de votre ProcessusIntelligence à produire les modifications vers la DatabaseIntelligence.

Pertinence Particulière pour le Wiki

Dans le wiki, nous sommes vulnérables aux EchecModifications.

LeWikiEstFondéSurLeDocument plutôt que basé sur le temps ainsi il a beaucoup d'intégration interne. Quand quelque chose est découvert qui casse le vieux moyen de penser, le wiki est ensuite erroné. Vous ne pouvez pas vous contenter simplement de le modifier à un seul endroit ; vous avez besoin de modifier un grand nombre de pages. Plus l'idée était fondamentale pour le wiki, plus vous aurez de pages à modifier. Vous serez obligé de secouer le wiki dans son intégralité.

Supposons que nous ayons eu wiki au 17° siècle. Et supposons que vous aviez une théorie wiki de WikiPedia:Phlogiston. Alors vous découvrez que le Phlogiston est faux. Que pouvez-vous faire ? Vous secouez le wiki.

Un exemple dans la vraie vie était le wiki de LionKimbro WikiNodes. Lion construisait un wiki pour détailler comment devaient fonctionner les noeuds [1]s. Puis AlexSchroeder a souligné que c'était probablement sur-spécifier les choses et que ce wiki devait être maintenu moins en tension, plus lâche. LionKimbro est tombé d'accord, mais eut par la suite beaucoup de travail à réaliser : des pans entiers du wiki, fondés sur de vieilles assertions devaient être nettoyés.

LeWikiEstFondéSurLeDocument. Il y a beaucoup d'intégration interne. Des modifications non triviales vers le wiki peuvent avoir des effets nettoyants.

(Il y a aussi un argument pour les petits wiki, TrancherWiki.)

C’est un EchecModification. Le ProcessusIntelligence ne peut pas intégrer ces modifications suffisamment rapidement dans la DatabaseIntelligence.

Solutions

Que pouvez-vous faire ?


LangueFrançaise PageTranslation ChangeFailure DossierOrganisationInformation DossierThéorieIntelligence

Le texte au-dessus est OriginellementDomainePublic?.

Discussion (translated from ChangeFailure)

BlocRésumé :

  • Récap : Les idées entrent. Acceptez ou Rejetez. (IntégrationEtIdentité.) Si acceptation, Petite Modification (ok) ou Grosse Modification (EchecModification)
  • Problèmes avec page. (Une Digression.)
    • Besoins de compter les réalisations internes pas seulement les modifications en conditions externes
    • Dire directement : EchecModification est un EchecIntelligence parce que cela m'a pris beaucoup de temps d’intégrer les nombreuses modifications dans la DatabaseIntelligence?.
  • Question à Alex :
  • L'intention de la CouvertureFroide est de ralentir la modification.
  • En essayer de couper les mauvaises idées, nous pouvons accidentellement couper de bonnes idées.
  • En essayant de préserver des bonnes idées, nous pouvons accidentellement préserver de mauvaises idées.

Wiki est les deux quand il est élaboré, il est essentiellement en mode fil de discussion et quand il est vraiment bon, en mode document. En même temps. WikiEstModeFiletModeDocument?1 en même temps - toujours. Il peut charrier une idée condensée commune dans un document commun section du texte qui a été développé en dehors de la discussion. Les blogs ne le peuvent pas, les wikis le peuvent. Meatball a beaucoup de ça. La base du wiki néanmoins demeure la communication directe simulée et verbale (ici sur CW non seulement avec la recommandation amicale d'UtiliserUnVraiNom mais aussi d'UtiliserDeVraisImages? !). C'est un protocole de pensées à l'heure. Les choses écrites plus tôt n'ont pas nécessairement besoin d'être modifiées quand une modification générale de pensée arrive et en pratique, elles n'arrivent pas. Elles sont vieilles, écrites avant la modification et doivent être comprise dans le contexte, l'ambiance, le façonnage du saut de la fourmi/termite (StigMergie) qui est sorti juste au moment où elles ont été écrites. Par conséquent le timbre chronodaté est vraiment important. Le document commun, la matière avant la barre de discussion doit être modifié, quand la pensée se modifie, oui. Mais le mode fil de discussion, le protocole qui dit la façon dont vous ête parvenu à développer le document commun, non. 85% de notre communication est simplement un protocole important de ces 15% qui ne sont pas joliment condensés à cette heure et éparapillés un peu partout, mais ce sont des biens. Si ceux-ci s'élaboraient mieux le travail aussi a provoqué par une modification de pensée serait plus facile à organiser par une communauté. Selon moi, ces choses s'arrangent de mieux en mieux avec plus de personnes impliquées. Et avec plus de temps (pour réfléchir).

Oh, ce que je voulais dire était - la technologie wiki est fondée sur les documents.

Je ne voulais pas dire en termes sur la façon dont nous créons véritablemnet nos pages - nous parlons, puis nous produisons un document, et nous parlons, et ensuite nous éditons le document. Avec ce respect : Oui, la conversation (en mode-fil) est la "base" de nos pages.

Mais en termes de technologie, ce qui est révolutionnaire à propos de wiki est que c'est fondé sur le document. (LeWikiEstFondéSurLeDocument).

A long terme, je pense que nous verrons des choses comme WikiFeatures:DocViewThreadViewSplit, (et, sur ses traces WikiFeatures:BuiltinThreading) et tout cela fera partie du Futures:TheEndOfWiki. Vous aurez des documents et ils seront dissociés proprement de nos conversations à leur propos. (Ceci résoudrait beaucoup de problèmes).

Oui, ce que vous avez dit à propos de nos conversations est correct : ELles ne sont pas sujettes à l'EchecModification, parce que les timbres horodatés et les chronologies rendent tout très clair. Nos conversations sont des messages, pas des documents.

Mais les sections de pages qui sont en ModeDocument – celles ci sont sujettes à l'EchecModification.

Je pense que tu portes un point intéressant : la RévisionParLesPairs peut limiter l'opportunité d'un EchecModification, en reliant un problème dans le derrière suffisamment tôt. Je mettrai cela dans le document. La sagesse dela communauté (WikiKM:InformationKnowledgeAndWisdom) tempère la page de manière à ce qu'un EcheModification? soit moins probable.

(Hmm, I perçois un besoin d'écrire MessagesVsDocuments? pour parler des différences entre eux à une échelle particulière).

BlocRésumé :

La RévisionParLesPairs agit aussi comme une CouvertureFroide si elle est appliquée trop tôt, aussi elle ralentit aussi les modifications lentes. Par conséquent, il n'est pas clair de savoir pourquoi la RévisionParLesPairs aide : aide t'elle à fortifier le document contre les échecs modifications, ou arrache t'elle simplement les sections susceptibles ? Si c'était ainsi, perdons nous quelque chose au moment d'appliquer la révision par les pairs pour éviter l'échec modification ?

Il y a beaucoup de choses ici.

Voyons. Nous parlons de l'EchecModification : quand le monde change plus vite que nous ne pouvons le suivre. Bien que ce ne soit pas nécessairement le monde - ce pourrait être aussi une réalisation.

Ainsi, une idée nous vient à l'esprit (nous jouons ici comme une Base de données d'Intelligence) et nous devons décider que faire. Nous pouvons la rejeter (IntégrationEtIdentité,) nous pouvons l'accepter. Si nous l'acceptons, ce pourrait être une petite modification, auquel cas nous produirons la petite modification. Ou ce pourrait être un gros changement, auquel cas nous avons un EchecModification (menant à beaucoup d'EchecIntelligence, parce que cela prend beaucoup de temps de mettre à jour la DatabaseIntelligence? par notre SystèmeIntelligence?).

Déjà je vois deux problèmes avec la page :

  • Elle a besoin de comptabiliser les réalisations, pas simplemnet les modifications dans l'environnement. Le point-clé est que c'est un nouveau quelque chose (réalisation interne, modification dans le monde extérieur) exigeant beaucoup de changements.'
  • L'EchecIntelligence arrive parce que cela prend beaucoup de temps à intégrer les modifications à l'intérieur de la DatabaseIntelligence?. (Il pourrait être établi plus directement, dans le texte en ModeDocument ci-dessus).

Toujours pas capté encore ce tu dis.

"La RévisionParLesPairs agit aussi comme une CouvertureFroide si elle est appliquée trop tôt, aussi elle ralentit aussi les modifications lentes. Par conséquent, il n'est pas clair de savoir pourquoi la RévisionParLesPairs aide : aide t'elle à fortifier le document contre les échecs modifications, ou arrache t'elle simplement les sections susceptibles ? Si c'était ainsi, perdons nous quelque chose au moment d'appliquer la révision par les pairs pour éviter l'échec modification ?"

Hmm… Je n'ai pas encore pigé.

La CouvertureFroide n'a pas besoin d'être secoué de frissons ; Ce peut être "Hm, es-tu sûr ?"

L'intention est de ralentir le changement ou d'éviter un changement complet. Et ce peut être exactement ce que nous désirons. Parce que ce pourrait être une modification néfaste ou erronée. Si j'écris UnPlusUnEgaleTrois? - "Super nouvelle théorie", j'espérerais que les gens puissent en discuter, "Mais, imaginez UnPlusUnEgaleTrois? - comment réflutes tu le grand X plus X produisant XX, parce que tu les mets côte à côte, et XXestDeux? ?" De ce fait éviter la modification. Ainsi, le ralentissement du changement est bon à ce titre.

Nous sommes préservés d'un EchecModification : La réalisation que notre wiki tout entier sur (disons) les mathématiques est complètement buggé, parce qu'il est fondé sur UnPlusUnEgaleTrois?. La RévisionParLesPairs nous a préservé d'un EchecModification.

Je ne pense pas que nous perdions quelque chose.

Il peut arriver que nous coupions des idées parfaitement bonnes, parce que c'est véritablement que nos affirmations de base qui sont mauvaises.

C'est reconnaître que nous pouvons avoir tort dans nos fondamentaux, nos affirmations de base qui fait que nous voulons un DroitDePassageMental? et pratiquer une InclusionRadicale InternetWide?. Nous pouvons ne pas vouloir une idée intégrée dans notre propre DatabaseIntelligence?, par IntégrationEtIdentité, mais nous aimerions qu'elle soit intégrée dans quelque DatabaseIntelligence? ailleurs. De cette façon, si nous avons tort, l'idée a germé en toute sécurité à un autre endroit.

OH ! Mais : pendant que j'ai écrit le BlocRésumé, je pense que j'ai appris ce que tu as voulu dire :

Et si la RévisionParLesPairs a l'effet de geler pensées ? Et si et si nous devenions conservateurs. Et si nous tombons amoureux de nos idées avec la DatabasePage et puis rejetons les les grosses modifications, tout simplement parce que cela impliquerait de mettre le bazar sur nos superbes pages. Et si la DatabasePage pervertit notre raisonnement et nous rejetons l'EchecModification simplement pour éviter de changer toutes les pages. Nous pourrions ne pas le faire à un niveau conscient, mais nous pouvons bien le faire à un niveau subconscient.

Je sais que -quand j'ai travaillé sur my goliath notebooks system- que j'ai tout simplement expérimenté ce problème. Je l'ai appelé le "glaçage mental" et j'ai même écrit à ce sujet.

Est ce dont tu parles ? Devrions nous produire une nouvelle page, BlocageMental?, pour parler de ce qui arrive quand une DatabaseIntelligence? dépasse notre esprit, et nous empêche de nous impliquer à cartographier plus de territoire par un vieux paradigme, plutôt que de sauter dans le navire et de migrer tout droit vers la nouvelle compréhension ?

En ce sens, la RévisionParLesPairs comme système pour éviter l'EchecModification : il me semble revenir en arrière vers IntégrationEtIdentité. Les conclusions sont les mêmes :

  • La RévisionParLesPairs peut vous aider à éviter de faire des erreurs profondes et de maintenir propre la DatabaseIntelligence?. Ceci empêche l'EchecModification.
  • La RévisionParLesPairs peut étouffer les changements importants et nécessaires. En ce cas, elle provoque un EchecModification, parce qu'éventuellent, la communauté va réaliser que c'est hors de portée de la réalité (Eventuellement)

Je crois que, toutes choses égales par ailleurs, il est mieux d'être vérifié par une communauté, que de ne pas l'être.

Le système fonctionne comme ça : vous trouvez une communauté qui partage des valeurs et objectifs similaires aux votres et comprend les choses plus ou moins de la même manière. Vous travaillez avec cette communauté pour sortir des compréhensions et vous discipliner vous-même vers vos valeurs et objectifs. La communauté vous aide à rester en état de vérification et vous aider à maintenir la communauté en état de vérification.

Mais un jour, vous découvrez quelque chose qui change votre pensée, d'une façon que vous ne pouvez pas revenir en arrière. Peut-être que vous voyez une plus grande image. Peut être vous voyez une de ces Synthèses Plus Profondes, décrite dans l'IntégrationEtIdentité et vous ne pouvez pas persuader le reste des membres du SystèmeIntelligence? que la vision plus profonde vaut la peine d'être intégré à l'intérieur de la DatabaseIntelligence?.

Dans ce cas, vous allez quelque part ailleurs, là où les personnes partagent des valeurs et objectifs similaires aux vôtres, et comprennent les choses plus ou moins de la même façon. Puis vous travaillers avec elles dans leurs efforts.

Jusqu'à, une fois de plus, ce que vous bougiez.

Je crois que nous avons besoin d'un nom pour ces idées. C'est une notion vraiment fondamentale, de ce que je crois.

(Néanmoins, vous vous souvenz toujours d'où vous venez, et aimez vos amis, sans prendre en considération les désaccords mentaux et tant de trucs. C'est tout simplemnet un ensemble de messages qui passent après tout. L'Amour est quelque chose de plus important.)

BlocRésumé :

  • Récap : Les idées rentrent. Acceptées ou Rejetées. (IntégrationEtIdentité). Si acceptées, Petite Modification (ok) ou Gros Changement (EchecModification)
  • Problèmes avec page. (Digression A.)
    • Besoin de compter sur les réalisations internes pas seulement les changements dans des conditions externes.
    • Dit directement : l'EchecModification est un EchecIntelligence parce que ça prend beaucoup de temps d'intégrer les nombreuses modifications à l'intérieur de la DatabaseIntelligence?.
  • Question d'Alex :
  • L'intention de la CouvertureFroide est de ralentir la modification.
    • Cela met à l'abri notre DatabaseIntelligence? de la corruption et d'éventuel EchecModification.
  • En essayant de couper court aux mauvaises idées, nous pouvons accidentellement couper court aux bonnes idées.
  • En essayant de préserver de bonnes idées, nous pouvons accidentellement préserver les mauvaises idées.
    • Parce que nous ne savons pas, pour finir, quelles sont les bonnes et mauvaises idées :
    • Préserver un DroitDePassageMental?, pratiquer une InclusionRadicaleInternetLarge?.
    • IntégrationEtIdentité nous amène à avoir besoin de protéger notre base de données.
    • L'humilité nous amène à avoir besoin de nous assurer que les gens trouvent un chemin pour faire germer leur idée.
  • Le BlocageMental? peut arrivr, si nous tombons amoureux de notre DatabaseIntelligence?.
    • Nous pouvons devenir conservateur, et pratiquer la RévisionParLesPairs des bonnes idées hors d'existence.
    • Mais il est bon d'être vérifié par la communauté.
    • (Par conséquent, c'est un danger nécessaire.)
  • IdeaSamsara? (WikiPedia:Samsara - "Sam: Together, Sara: it Flows")
    • Trouver les gens qui partagent vos valeurs et bus, et travailler avec eux.
    • Eventuellement, migrer, quand vous réalisez quelque chose que tous les autres ne peuvent pas ou ne voudront pas faire.

(Désolé pour la divagation , en espérant que vous pourrz suivre… ! je déambule sur ce territoire, moi-même, essayant de le représenter).

Est-ce que quelque idée a du sens ? Je demande car je regarde la pendule et elle me dit qu'il est minuit, et je sais d'expérience que je ne fais pas je ne produis pas un enfer de choses autour de minuit.

LionKimbro

C'est exactement ce dont je parle. J'aime "Et si nous devions conservateurs ?" Et si tombions amoureux de nos idées avec la Databasepage et puis rejetions les grosses modifications, simplement parce que cela tout simplement parce que cela impliquerait de mettre le bazar sur nos superbes pages ?"

Oh, okay.

Bien, dans ce cas, nous avons un BlocageMental?, qui mène à un EchecModifiation? massif.

;)

Mais, tu sais… Il y a toutes sortes d'endroits dans le monde où il y a un BlocageMental?, qui persiste en quelque sorte à un niveau social. Il n'y a, tu sais - qu'à piocher quelque chose – de tous ces Ayn Rand-ites, qui ne voient pas les failles dans leur système. Un jour, ils le voudront. Mais ils ne pourront pas convaincre tous leurs amis. Les gens entrent et sortent, de ce système particulier de pensée. (je pense vraiment que ces personnes devraient avoir un wiki, à eux).

LionKimbro

Les Fans de la Singularité Vingean tendent à appeler ceci le "future schock". Essaye de lire le travail de Yudowski tel que celui-ci[2]. Le point est que parce que nous approchons la Singularité mythique, le taux de modification technologique accélère jusqu'aù stade où personne ne peut coopérer, au moins en utilisant les techniques actuelles. Si l'hypothèse de la Singularité est correcte, alors l'EchecModification est un problème vitalement important.

Oui, je suis conscient de cette idée. Je participe au wiki SL4 de temps en temps et me considère moi-même "au" Niveau de Shock 4, selon leur terminologie étrange. (Je ne sais pas - cela me choque d'être cette sorte de goofy. Cela me rappelle l'OT de la Scientologie et les schémas "Catégories 1-9" de de Bono pour les gens. Je ne suis pas friand de ces systèmes, mais sans considération - je flashe mes couleurs).

Mon sentiment est que la plupart des gens on zéro idée de ce qui leur arrive droit dessus, et la petite influence que quiconque a sur ça. C'est ce à quoi sont destinés les films néanmoins. Minority Report, Terminator 3, I, Robot- font un bon boulot pour expliquer les choses, je pense.

Je ne suis pas sûr d'être d'accord avec le point général de cette page, au moins en termes de comparer wiki a de véritables alternatives. Si vous faites un gros changement mental, alors jusqu'à ce que vous redocumentiez la totalité du champ de cette modification, d'autres personnes devront deviner quels bits de l'archive sont encore pertinents.

Hmm, laissez moi essayer d'être encore plus clair. Comparons l'organisation du changement entre un wiki et un blog. Supposons que nous parlons de quelque morceau de pensée qui prend une belle quantité de langage écrit pour être exprimée. Disons que cela prendrait l'équivalent de 5 moitiés de pages wikis. Et la version précédente de cette pensée a déjà été complètement documentée. Dans ce wiki, cela pourrait prendre 5-10 (ou beaucoup plus) de pages différentes (parce que vous cassez les choses logiquement plutôt que simplement sur la base de la taille de la page - DecomposeIntoLogicalChunks?). Sur le blog vous pouvez avoir de 1-5 (ou beaucoup plus) documents couvrant cette pensée (sur l'affirmation que les blogs n'encouragent pas les modèles type DecomposeIntoLogicalChunks?, aussi il y a un plus grand risque que vous finissiez avec une grosse page de référence plus logiquement similaire à un vieux document Word).

Aussi, maintenant vous avez cette modification, qui est dans votre tête et cela prendra du temps à documenter. Peut-être plus de temps que vous n'en avez à cette heure.

J'avancerai que c'est 'plus difficile/plus lent' de mettre à jour incrémentalement votre GrossePageBlogUnique? que vos 10 pages wiki.

Hmm, je suppose que j'aurai besoin de revenir plus tard et de sauvegarder cette revendication. Mais j'espère que j'ai défini un peu de contexte qui pourrait amener les autres vers ce même train de pensée.

Désolé, j'ai pris tant de temps à répondre. Quelque part, je ne prêtais tout simplemnet pas attention aux Modifications Récentes et ne l'avais pas vu.

Bon, je pense que nous nous comprenons simplement mal l'un et l'autre.

Quand vous participez dans un wiki, et qu'il arrive une réalisation majeure, bouleversant la valeur de disons - 20 pages- alors vous ressentez quelque obligation de revenir en arrière et de réviser ces pages.

C'est parce que le wiki représente quelque chose comme une approbation vivante.

Mais dans un blog, si vous dites quelque chose qui était faux dans le passé - vous ne revenez pas sur votre corpus global pour l'éditer. Peu importe la longueur du corpus, ou combien de pages contenaient votre vieille idée : Vous n'éditez simplement pas les vieilles pages.

Une démonstration :

Si votre blog dit…

http://www.bigreds.com/TURTLE2.gif
"La meilleure tortue mutante ninja est clairement Rafael. C'était la plus cool. Je veux dire, elle a eu le Sai ; quel pistolet est plus cool que ça ? – LionKimbro, 9 ans"

… ensuite il n'y a pas de raison de la retirer. Je veux dire, vous aviez 9 ans.

Mais si c'est votre wiki, et s'il a encore une page QuelleTortureNinjaMutanteEstLaPlusCool, bon - c'est probablement quelque chose que vous voudrez retirer. EchecModification.

Juste quelque pensée plus récente :

Le cerveau semble avoir une capacité étonnante à gérer le changement. Si vous passez votre vie durant 10 ans avec une philosophie, et puis avez un changement majeur dans la philosophie, le cerveau fait vraiment des choses étonnantes, comparé à un ordinateur, qui est incroyablement difficile à modifier. Dans les ordinateurs, les changements doivent être soigneusement préparés et mis en application, ou sinon tout casse.

Aussi, comment est-ce possible ? Je peux penser à deux explications possibles.

  • Possibilité 1 : Le cerveau humain est capable de maintenir des explications multiples A en une fois. Si l'une venait à être fausse, il bascule vers l'explication B, qui lui est déjà familière.
  • Possibilité 2 : Le cerveau humain est incroyablement dynamique et nous pensons la plupart des choses en temps réel. Un "gros changement" dans la philosophie n'est pas vraiment par la suite un gros changement système. C'est plutôt et vraiment simplement un petit changement, et nous pouvons le gérer parce que nous avons toujours extrapolé un gros compromis de petits morceaux - en ne comptant pas sur des systèmes codés dans le dur.

Qu'est-ce que ce serait si la Posssibilité 1 était avérée sur les ordinateurs ? Cela voudrait dire que vous avez programmé des ordinateurs avec de multiples explications en une fois. Quand l'ordinateur voulait savoir comment faire quelque chose, il essaierait quelques explications. En même temps. Si une échoue, … eh, utilise l'autre.

Qu'est-ce que ce serait si la Posssibilité 1 était avérée sur les ordinateurs ? Alors ils seraient des programmes super-super temps réel, s'appuyant sur un tout petit nombre de "faits" à un temps donné. Vous changez un petit fait, et ça va il est toujours en train de regarder bouger 2000 coups d'échecs en avance.

Ceci étant dit : je ne suis pas expert ici. Je n'ai pas d'idée de ce dont je parle. Je n'ai jamais pris même un cours en IA. Ce sont juste des pensées que je trouvais intéressantes, en rapport avec l'EchecIntelligence.

Yeah, je suis d'accord (avec les deux possibilités). Bien sûr, c'est purement spéculatif de ma part.

Footnotes:

1. WikiisThreadandDocumentMode?

Define external redirect: EcritureLaconique OriginellementDomainePublic UtiliserDeVraisImages ProcessusIntelligence EchecModifiation DroitDePassageMental EcheModification DatabaseIntelligence NonEcriture WikiEstModeFiletModeDocument BlocageMental MessagesVsDocuments IdeaSamsara DecomposeIntoLogicalChunks UnPlusUnEgaleTrois XXestDeux InclusionRadicaleInternetLarge WikiisThreadandDocumentMode InternetWide GrossePageBlogUnique SystèmeIntelligence

EditNearLinks: UtiliserUnVraiNom DatabasePage CouvertureFroide

Languages: