[Home]ModificationsDigérées

MeatballWiki | RecentChanges | Random Page | Indices | Categories
Cette page a démarré sur DigestedChanges

1. Résumé

Les ModificationsDigérées sont un blog (cf CarnetWeb) du wiki. Pour les événements actuels de la journée (par exemple ce qui est apparu sur les ModificationsRécentes), quelque chroniqueur ou journaliste écrit une prose résumée. Ce peut être déjà fait, parce c'est simplement de l'écriture et cela a déjà été tenté sur plusieurs wikis (par ex. RésuméMeatball). La différence est de renvoyer vers une page qui rassemblera tous ses ModificationsRécentes sous ce résumé. Les modifications non résumées seront amassées en haut jusqu'à ce que quelqu'un se soucie de les résumer. En ce sens, alors que les ModificationsRécentes ne fournissent que des données sages (ce que le RésuméDigéré essaye de résoudre), les ModificationsDigérées fournissent une chronique décrivant l'histoire des mofications qui fournit le contexte.

Parce qu'un autre avantage essentiel, le fait de maintenir le résumé est beaucoup plus astreignant, parce que fournir une information modifiée et à jour rend le résumé plus intéressant pour les AccrosModificationsRécentes. Bien sûr la valeur économique des ModificationsRécentes est simplement : combiner l'information mise à jour de modification avec la capacité de remanier les ModificationsRécentes.

Retour d'expérience sur mon résumé encore peu clair

Tout travail vraiment créatif est le résultat de tension :) Je ne suis pas clair sur ce que tu veux dire. Je pense que je n'ai jamais été aussi peu clair sur ce que veut dire ModificationsDigérées, de fait ma préférence va vers le RésuméDigéré. Peut-être qu'une "histoire utilisateur" du comment le système devrait fonctionner quand plusieurs modifications se cumulent pourrait aider ? -- ChrisPurcell

Les ModificationsDigérées sont exactement un welbog du wiki plus un ajout crucial. En bas de chaque entrée, pour tous les liens dans l'entrée vers les pages sur le wiki, nous listons la liste des ModificationsRécentes pour ces liens. Les ModificationsRécentes sans une entrée de weblog les décrivant sont affichées en haut. De cette façon, comme maintenant les liens non décrits sont évidents pour les personnes qui veulent écrire unen entrée de weblog à ce propos. -- SunirShah

ok, dodo maintenant. plus à venir plus tard. -- sunir

---

ModificationsRécentes est la page la plus centrale sur un wiki, se concentrant sur l'activité de la totalité du wiki en un format unique de présentation. Pour les petits wikis, le faible taux d'AbandonPage fait des ModificationsRécentes un SchémaIndexation malléable pour les modifications. Néanmoins, au fur et à mesure que les wikis croissent en popularité et en souffle, le nombre de sujets sans rapport qui peuvent être discutés à un jour donné s'accroît. En outre, parce que la complexité de la DatabasePage augmente, le nombre de pages qui peuvent être touchées dans une discussion donnée grandit tout autant, parce que les discussions s'éparpillent sur de multiples pages. La plupart des implémentations des ModificationsRécentes dégringolent aussi toutes vers la même page dans une liste unique, disant seulement aux AccrosModificationsRécentes insouciants que la page a changé, pas son historique totale sur ce laps de temps ce qui est souvent important à connaître. Le fait de lister chaque modification submergerait rapidement le lecteur avec une SurchargeInformation, parce que certains éditeurs éditent souvent les pages une dizaine de fois ou plus jusqu'à ce qu'elles soient parfaites. En outre, il peut y avoir un très grand nombre d'éditions si la discussion est très chaude ou s'il y a une GuerreEdition, ou si le vandalisme est en cours, ou durant une GuerreDeMot, ou durant tout autre FeuDeForêt ce qui ressemble à un HoldUpModificationsRécentes.

Ce ne sont pas seulement les AccrosModificationsRécentes qui souffrent, mais aussi les visiteurs de passages qui ont seulement le temps de regarder le wiki de temps en temps. Ils ne peuvent pas se prendre la tête sur ce qui se passe et cela brise rapidement les connexions sociales et le SavoirCommunauté nécessaire pour tenir ensemble le groupe. Après tout, comment se comporte un lecteur occasionnel pur savoir qu'un événement dramatique est arrivé si sa première impression est qu'un bavardage de pages a été édité durant une semaine ou deux, enseveli dans une mer d'autres modications. Il n'en saura rien. Ceci peut aussi conduire à des échecs massifs de SécuritéDouce parce que les critiques par RévisionParLesPairs perdent toute trace de ce qui se passe et par conséquent la confiance peut s'évaporer.

Aussi, la plupart des implémentations ModificationsRécentes sont des fournitures par le programme du log interne de modification, plutôt qu'une simple page wiki comme WikiWiki. Ceci est fait pour plusieurs raisons, comme le fait d'accroître le pouvoir des OptionsModificationsRécentes tout comme le fait de normaliser les ModificationsRécentes et de les maintenir automatiquement. Le compromis signifie que les utilisateurs normaux ne peuvent pas éditer les ModificationsRécentes, faisant de cette page une une exception lumineuse du wiki. Ceci veut aussi dire que les ModificationsRécentes sont la cible de n'importe quel texte qui n'est pas éditable par les critiques de RévisionParLesPairs. Le texte offensif sur la page n'est pas éditable. Les résumés sont dubliqués. L'image de haut-niveau est perdue dans la liste entrelacée de style-"UseNet". Et fait très important, le bruit donné a la même priorité que le signal, écrabouillant de ce fait le RapportSignalBruit des ModificationsRécentes.

Bien sûr, les ModificationsRécentes du WikiWiki ne sont pas vraiment remaniables parce que le système créera de nouvelles entrées quand les plus anciennes sont effacées, et migrera les plus vieilles entrées quand elle sont modifiées à nouveau. Et bien sûr, vous violerez la confiance du wiki si vous tordrez la réalité en altérant les ModificationsRécentes (in significant ways). Fait intéressant, les personnes ont commencé à faire ça en toute mauvaise fois (bien que SunirShah fût le premier connu à tordre les Wiki:RecentChanges, bien qu'il l'ait fait de bonne foi). Telle est la raison pour laquelle nous ne laissons pas les ModificationsRécentes éditables.

La solution commune à ce stade a été de créer un résumé manuel séparé des modifications ; dans un sens, un JournalEnLigne du wiki. Ceux-ci peuvent prendre différentes formes, comme celui assez original Wiki:ChangeSummary de CliffordAdams, le Wiki:ManualTopTen, et le RésuméMeatball. Ces tentatives sont de fournir un résumé édité des événements d'une façon plus ordonnée sémantiquement qu'une simple liste chronologique. Ils peuvent fournir une structure utile et bien rangée comme la connexion d'un jeu de pages assemblées en une description, narrant l'histoire des connexions qui a provoqué leurs AbandonPage. Ils filtrent aussi le bruit, ignorant ou appelant explicitement les pages qui ne valent pas la peine d'être lues par le lecteur occasionnel.

Malheureusement, maintenus par un guérisseur isolé la plupart du temps, ces essais échouent parce qu'ils sont oubliés. Mais ils sont utiles car ils fournissent de l'information ayant du sens. Aussi, pourquoi est-ce que les ModificationsRécentes oubliées sont un tel puisard si puissant auxquelles s'accrochent les personnes jusqu'à ce que vous soyez en mesure de fournir quelque chose de mieux et ceci est très difficile. Seulement au moment où WikiWiki a offert Wiki:QuickChanges s'est produit une migration significative de personnes, parce que c'était simplement plus rapide et en ordre chronologique inversé. Une liste manuelle est même pire parce qu'elle est rarement à l'heure. En outre, elle ne liste vraiment pas toutes les modifications, la rendant inutile pour la RévisionParLesPairs. A la place de cela, elle semble être une duplication de l'information, et nous voulons MoinsDeRedondance.

Par conséquent, combinez les ModificationsRécentes et le résumé en un seul SchémaIndexation. Même si c'est un concept puissant, la façon d'y parvenir n'est pas immédiatement très claire. En outre, nous voulons couvrir tous les cas listés au-dessus.

Commençons avec un exemple de jeu de données. Voilà la sortie des ModificationsRécentes pour le 8 janvier 2004 (toutes les modifications, y compris les éditions mineures) ([pour sauter plus bas]):

January 8, 2004

Cette liste est ridiculeusement longue et labyrinthique, et ce n'est qu'une seule journée. Comment n'importe quel visiteur hebdomadaire pourrait se faire quelque idée de ce qui se passe ? Il n'en saura rien et partira. Nous pourrions résumer cela comme :

1. Résumé
1.1. DossierTechnologieWiki
1.2. DossierRemaniement
1.3. Socio-économie
1.4. Meta
1.4.1. GuerreDeMot
1.4.2. Culture
1.4.3. GuideStyle
1.4.4. Nouveau développement de programme
1.4.5. Les gens
1.4.6. Ménage de maison
1.4.6.1. Bruit

1.1. DossierTechnologieWiki

1.2. DossierRemaniement

MartinHarper travaille sur la CategoryReworking (ndt DossierRemaniement) : RefactorAsYouGo? BazarFil HitAndRunRefactoring ProblèmesRemaniement WhatIsReworking RemoveIdentity (ndt EnleverIdentité) RefactorLater? (ndt SarclerPlusTard? ou RetravaillerPlusTard?)

1.3. Socio-économie

1.4. Meta

1.4.1. GuerreDeMot

Helmut et Sunir discutent du problème diplomatique en cours sur HelmutLeitner, après l'avoir déménagé en dehors de la page (censurée pour ce cas) et la page nom de MartinHarper. Dans cette course, Sunir a généré une matrice de différentes communautés vers les relations extérieures qu'il a migrée vers NousEtEux. Il y a eu aussi un écart sur l'échec en cours des PagesConservées qui a provoqué quelques malentendus. Sunir suggère une solution : le problème est vraiment de DéfendreContrePassion en ne l'exigeant pas.

1.4.2. Culture

Meatball parle plus à propos de lui, DossierMeatball. (CategoryMeatball). YourOwnWikiCommunity? migre vers MeatballAlternatives (ndt AlternativesMeatball en français), incluant le FermentWiki. Nous jouons avec les MoreIntroductoryLinks? provenant du MeatballWiki. Nous discutons le MeatballDigest (ndt RésuméMeatball) sur MeatballDigestDiscussion. Copyright et Meatball en viennent à nouveau au concordat. MeatballOpenContent? est redirigé vers OpenMeatballWiki. Nous commençons à en apprendre un peu plus à propos du PrimarilyPublicDomain et que ce CopyrightDoesntMatter dans une OpenCulture (CultureOuverte?). Spillover catégorise InfoAnarchyWiki. Nous continuons aussi à débattre de l'adhésion communauté CommunityMember. (MembreDeLaCommunauté)

1.4.3. GuideStyle

Sunir suggère "voir aussi" à l'intérieur du texte de la body sur le StyleGuide (ndt GuideStyle), en utilisant le CommunityLore (ndt SavoirCommunauté) comme exemple. Ceci nous à mené à migrer la discussion des notes de bas de pages vers ShallowPage (PagePeuProfonde).

1.4.4. Nouveau développement de programme

ScottMoonen avance en remplaçant le script UseModWiki sous-jacent au MeatballWiki par un script OddMuse d'AlexSchroeder, comme il l'a annoncé sur MeatballWikiSoftwareDiscussion. Pour cela, Sunir lui offre une BarnStar (ndt EtoileDeGrange), qui est en rapport avec la discussion en cours du AwardRitual (RituelDeRécompense).

1.4.5. Les gens

SunirShah parle de rejoindre LiveJournal dans son journal en ligne pour sa classe KMD1002. Il répare aussi un bug de longue durée du DeletedPage qui obligeait de laisser une ligne blanche bancale. Beaucoup d'activités en cours avec MartinHarper, SteveDunlop? et HelmutLeitner. EarleMartin salue à nouveau. LukeStark présente son nouveau ContactsMusicWiki. FlorenceDevouard rejoint MeatballWiki. Josef nous invite à participer à l'événement en espace ouvert de UnitedDiversity.

1.4.6. Ménage de maison

Martin et SteveDunlop? nettoient quelques CategoryHomePages mortes, tout spécialement les cas suivant de CategoryRealNames : AlexBromfield, AredridelNiothke?, AvishalomShalit, KabAds?, LoriZ?-->LorraineLee, MatrixFrog?, PrinceOfStories?, PubWan, TecSpectr?, TheCunctator. Ils effacent aussi WhyUseRealNames pour essayer de simplifier UseRealNames. Tout en faisant ça, la discussion sur le VraiNom UseRealNamesDiscussion revient à nouveau, tout comme le WhatIsMultiplicity et SockPuppet (ndt ChaussetteMarionnette). Les pseudos sur les pages RecentVisitors (VisiteursRécents), SillyTextFormattingRules, InformationWantsToBeFree doivent être retirés.

1.4.6.1. Bruit

Il y a souvent seulement une ModificationsRécentes. Queques wikis ont fourni des ModificationsSouscrites pour donner aux utilisateurs le contrôle nécessaire pour produire leurs propres ModificationsRécentes. Dans un sens nous avons appris de :

Le phénomène peut comprendre de telle choses en soulageant les guerres du feu par une capacité de les résumer plus vite.

"Vous avez besoin de personnes." Il y a toujours des personnes... vous devez simplement leur donner un stimuli.

Le résumé ne doit pas être unique non plus, aussi vous pouvez maintenir des journaux projets sur une plus longue période de temps que dans les ModificationsRécentes. Ou même des journaux en ligne.

C'est littéralement un "wiki log"; c'est à dire un "log" un journal de bord de toutes les transactions du wiki. 

<NamNT> et ppl __devrait__ aussi fournir un résumé rapide
<Sunir> par page ? ou par pages ?
<NamNT> par édition
<Sunir> oui... usemod wiki permet cela ; moin fait ainsi ?
<NamNT> à vrai dire il le fait
<NamNT> un court champ "commentaire" 
<Sunir> mais cela n'aide pas à capter toute l'histoire. les personnes se perdent après 20 modifications qui arrivent dans la discussion chaque jour, parce qu'il n'y a pas de temporalité dans un wiki.
<NamNT> c'est limité néanmoins
<Sunir> bien, aissi c'est plus gros, uniforme, multi-paginé, et intemporel.
<Sunir> c'est littéralement du "journalisme" pour le wiki. Un traitement "Que se passe t'il ?".
<Sunir> Ce qui est tout à fait franchement ce dont j'ai besoin, parce que je ne lis pas mon propre wiki à ce niveau de profondeur. c'est une perte de temps.
...
<NamNT> fait que le champ commentaire soit un petit plus gros
<NamNT> de façon qu'il puisse s'accomoder une histoire complètement résumée
<Sunir> peut-être rates-tu ce que je dis...
<NamNT> est-ce que ça le fera ?
<Sunir> Tu écris l'histoire..


<NamNT> ceci requiert réellement un éditeur actif
<Sunir> bien sûr, c'est ce que fait un wiki.

Vous créez simplemnet une attente communauté pour créer le résumé. C'est néanmoins plus facile sur MeatballWiki. Le fait que cela trace les ModificationsRécentes est un bon moyen pour inviter les personnes à en prendre soin. Les solutions précédentes étaient construites au sommet des modifications récentes, aussi personne n'en prenait soin... Les personnes ne lisaient que les modifications récentes. Ceci supplantera les modifications récentes.

Pensez à cela : pourquoi est-ce ModificationsRécentes est la seule page que nous pouvez pas remanier ? le mode fil est infernal. Les modifications récentes est un pauvre mode fil de l'homme.

par exemple, je voulais parler de cartes.

La "CategoryCartography a été créée pour contenir le champ de CyberCartography?, qui en ligne n'est pas vraiment la carte de ObjectiveSpace?, mais plus de l'EspaceSémantique?. Nous nous dirigeons vers l'EspaceSocialSémantique?, comme avec les ChatCircles. Un autre travail intéressant comprend StarryNight."

Ainsi, tous ces ModèleDeLiens [sic] renvoient vers des pages qui sont en train d'être modifiées (ou seront modifiées). En dessous de ce résumé sur ModificationsDigérées les modifications pour ces pages apparaîtront...

Pensez le comme un weblog.. mis à part le fait que le traçage des ModificationsRécentes soit rompu par entrée. Pour donnée une ligne du temps globale des événements, une ligne du temps résumée sommairement est présentée dans une colonne sur la gauche. [c'est un weblog... mais un *wiki* log ; un weblog des transactions du wiki]

Prenez l'exemple des modifications vers ces pages sont les mêmes que celles en cours

NamNT? : Afficher les modifications récentes de toutes les pages dans cette page.

Si ce n'est que je peux être vraiment plus magique en le faisant par section en utilisant la table des matières et les titres numérotés et les syntaxes de règles horizontales que nous avons déjà. Bien que par page soit plus facile à comprendre, ceci conduit à beaucoup de pages, ce qui peut ou ne pas être une bonne chose. Mais ceci rend plus difficile le remaniement de deux histoires ensemble, ce qui se passera. Mais les organisations actuelles des incarnations de wiki log ont une page par entrée, avec des commentaires approvisionnés simplement à la mode wiki vers ces entrées (tirer un trait horizontal, commencer à saisir) ainsi peut être que ce n'est pas un mauvais chemin à suivre pour quelques personnes.

Un autre avantage est que le RSS pour wiki craint vraiment aujourd'hui. Les ModificationsRécentes ne sont pas ce qu'est le RSS ; c'est un "spooge" d'un médium à un autre. C'est un magnifique défi.

Est-ce que cette fonctionnalité a besoin d'un éditeur pour compiler les modifications ? Mais parce que la culture wiki tourne en orbite autour des ModificationsRécentes, ce sera facile à obtenir. Vous ne pouvez pas produire une machine à résumé des communications sur un wiki parce qu'il est sémantique. Tout ce qui a à voir avec la communication, nécessite une intervention humaine pour y parvenir.

Un autre avantage des ModificationsDigérées est que c'est la voie du wiki que de filtrer le bruit. Beaucoup de personnes désirent utilisé des ModificationsRécentesFiltrées, par auteur, regex, domaine, catégorie, etc. Les Modifications digérées simplifient plutôt l'information et l'organisent ; la même raison pour laquelle nous utilisons un wiki plutôt qu'un forum de discussion qui est plein de bruit.

Stimuli économique

En outre, nous sommes très intéressés par les weblogs.

Aussi, ceci nous aide à attirer de l'attention vers d'autres conversation autrement si mal comprises. Si vous essayez de présenter une idée, vous pouvez maintenant fournir un résumé dans un lieu unique et central. Le seul autre moyen était votre journal en ligne, qui ne fonctionnait pas parce que j'étais le seul avec un journal en ligne.

Plus, si vous pouvez produire des ModificationsRécentes aussi ennuyeuses que possible et des ModificationsDigérées aussi belles que possible, cela peut aider.

DossierTechnologieWiki DossierTechnologieWikiNonimplémentée

Quelques problèmes :

Vous pourriez réparer ceci sans vous éloigner trop loin du schéma des ModificationsDigérées en ayant une ModificationsRécentes très limitée. Elle liste les modifications pour de tout petits intervalles de temps dans le passé (je suggérerais 24 heures), mais n'affiche pas de résumé de modification (ce n'est une sorte de ModeFil) et probablement ordonne en priorité par IP/nomutilisateur, plaçant les nouveaux venus au sommet.

J'aimerais voir où vous prenez des ModificationsDigérées avant d'ajouter quoi qeu ce soit d'autre de mon input personnel. -- ChrisPurcell

Je suis quelque peu confus. Est-ce une proposition de produire une liste éditable des ModificationsRécentes (et encourager les personnes à l'éditer libéralement) ou à ôter les ModficationsRécentes? et les remplacer par le RésuméMeatball ?

Oui. Les deux. Editer les ModificationsRécentes en résumés.

Je suis complètement pour les ModificationsDigérées, mais en plus, pas en remplacement des ModificationsRécentes.

Si les personnes veulent encore lire les ModificationsRécentes après l'introduction des ModificationsDigérées, ceci voudrait dire que les ModificationsDigérées n'ont pas encore fourni à ce stade tout des fonctionnalités des ModificationsRécentes. "Legislating away" notre désirs de modifications récentes en les ôtant ferait seulement une production de quelques désirs non rencontrés.

Par ailleurs, pour moi c'est un cas spécial de WebLogDigest. Les différents moyens de raconter une histoire sur ce qui se passe dans le wiki pourrait être réalisé par des ModificationsDigérées séparées, multiples (PointDeVue à nouveau) Les modifications récentes filtrées sont analogues aux versions des ModificationsDigérées qui ne mentionnent pas chaque modification réelle. -- BayleShanks

ModificationsDigérées est ModificationsRécentes avec plus de fonctionnalités. -- SunirShah

Désolé, je n'ai pas compris ça. Aussi il sera possible de "voir" les vraies modifications non éditées ? -- BayleShanks

Oui; c'est impératif, autrement ce ne sera pas utilisé. Toute l'information des ModificationsRécentes mais mieux organisée. J'ai besoin d'écrire le texte en haut de la page mais j'ai mal au crâne. -- SunirShah

En regardant l'échantillon des ModificationsDigérées sur cette page, il me semble qu'avoir du texte pour chaque groupe de modifications serait difficile à gérer (par ex cela demanderait beaucoup trop d'efforts d'écrire pour des modifications éphémères, ainsi personne n'écrirait). Cependant, le simple fait de grouper les modifications dans une structure hiérarchique en arbre serait valable.

La question est, comment faire ceci vraiment vraiment vite ?

S'il existe une hiérarchie figée, alors le fait d'assigner chaque modification à sa place dans la hiérarchie est simplemnet une question de l'assigner vers une liste de catégories (par ex chaque lieu dans la hiérarchie est une "catégorie"). Ainsi ceci pourrait être produit via CategorizedEdits. Le dialogue édition pour la page ModificationsDigérées pourrait afficher chaque modification avec un jeu de boîtes à sa droite. Pour assigner la modification à une catégorie différente, vous éditez la page et puis cochez l'une des boîtes à côté de cette modification. Toutes ces modifications pourraient démarrer dans la catégorie "uncategorized" category.

-- BayleShanks

Sur le SolaRoofWiki? nous avons un système d'utilisation des WikiGroupe?s de PmWiki qui n'est pas pensé comme une structure en arbre pour organiser l'EspaceNom principal, qui est notre travail collectif sur une base de connaissance, mais qui sont des SousWikis indépendants et qui ont tous leurs propres fonctions de Modifications Récentes. Un des WikiGroupe?s est notre Profiles/User Name qui est un groupement des "pages personnelles" de nos membres. Par conséquent, j'ai référencé les Modifications Récentes des pages dans ce groupe comme "Member Activity" de telle façon qu quand de nouveaux membres créent des pages personnelles ou quand des membres produisent des modifications (ou se font éditer leurs pages personnelles par quelqu'un d'autre) alors ceci apparaît comme "Member Activity". Nous installerons aussi un "Fil" vers chacune de ces pages noms d'un résumé des pages nouvellement écrites ou édités de WikiLog par ce membre. Les logs individuels des membres ont leurs propres ModificationsRécentes comme ceci se fait sur l'espace projet du membre ou sur le NousWiki? personnel. Par conséquent nous pouvons visiter ces différentes WikiGroupe?s et voir les ModificationsRécentes ou être tuyautés à propos des modifications d'intérêt général en regardant Member Activity et rien de cette activité n'étouffera l'aspect important de tracer les modifications et le développement de la base de connaissance. Nous avons beaucoup de travail à faire sur toutes ces idées - aussi nous regarderons pour quelque aide si quelqu'un aimerait s'impliquer. - RichardNelson

LangueFrançaise PageTranslation DigestedChanges

Discussion

MeatballWiki | RecentChanges | Random Page | Indices | Categories
Edit text of this page | View other revisions
Search: