[Home]RésuméDigéré

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

La mécanique d'un wiki (voir CestQuoiUnWiki) résulte généralement dans la commununauté se concentrant sur les ModificationsRécentes. Historiquement, ceci était simplement une liste de pages récemment modifiées ; néanmoins, à moins qu'un ne soit un de ces AccrosModificationsRécentes, il est difficile de suivre le flux rapide de discussion ou de décider comment dépenser utilement le temps limité qu'on peut avoir à notre disposition. Ajouter un résumé à chaque modification profite à nouveau essentiellement aux AccrosModificationsRécentes, parce que seuls les résumés les plus récents demeureront encore affichés. Choisir de voir toutes les modifications, plutôt que les pages modifiées, est un pas plus en avant, mais résulte en une SurchargeInformation. Résumer un tel ensemble de modifications est mieux fait pas les éditeurs wiki, pas par une machine.

Par conséquent, ajoutez une description de vos modifications au résumé de la page. Pour garder un résumé frais, ôtez les descriptions des modifications plus anciennes que la période de RévisionParLesPairs de deux semaines. Pour garder le résumé informatif et utile, digérez le quand il devient trop long.

Mais, ces points sont simplement des lignes de conduite, pas des règles pures-et-dures : le RésuméDigéré est une expérience en cours, et nous accueillons l'expérimentation et les idées dans cet espace. Par exemole, un modle utile qui a émergé utilise le champ de digestion comme une sorte de MiniBlog?, laissant les gens savoir quand une sorte de page comme un CarnetWeb a été mise à jour. Dans ces cas-là, on peut complètement effacer les entrées à partir du résumé, car les lecteurs n'ont seulement besoin de voir que la dernière entrée pour savoir que de nouvelles entrées ont été rajoutées. Elaguer les entrées les plus vieilles, même si elles n'ont que quelques heures, est un moyen propre d'empêcher un MiniBlog? chaud de faire un HoldUpModificationsRécentes.

Comment fonctionne le RésuméDigéré

Durant les discussions actives, certaines pages sont modifiées plusieurs fois dans une seule journée, ce qui s'affiche sur les ModificationsRécentes avec seulement une entrée unique dans la liste (à moins que vous ne demandiez de voir toutes les modifications). Ceci veut dire que les lecteurs arrivant beaucoup plus tard ne savent souvent pas ce qui s'est passé durant le jour ou même la semaine. Un RésuméDigéré fournit une petite quantité de méta-données à propos des modifications pour aider ceux qui sont en train d'écrémer les ModificationsRécentes afin de dire rapidement ce qui s'est passé. Cependant, décrit ainsi, ceci les aide seulement pour la dernière modification, pas la totalité de l'historique des modifications. De ce fait, seuls les AccrosModificationsRécentes ont l'opportunité de comprendre ce qui s'est passé. Nous n'aimons vraiment pas les accros ; ils portent trop de pression sociale sur le wiki. Nous voulons permettre aux personnes de rester à distance du site tant qu'il leur semble raisonnable de continuer à contribuer sans perdre leur temps à rester informées de chaque micro-contribution. Lister tous les résumés sous l'entrée de chaque page dans les ModificationsRécentes amène à beaucoup d'entrées redondantes et sans rapport qui pourraient être simplifiées, tout spécialement quand quelqu'un entre dans un cycle "éditer & voir & sauvegarder", créant de nombreuses nouvelles versions avec le même résumé.

Une solution communauté est de préserver le résumé entre les éditions. Ceci contraste avec la situation antérieure où de nouveaux résumés sont écrits pour chaque édition, même si les éditions successives sont produites par le même auteur. De nouvelles modifications intéressantes peuvent être ajoutées à ce résumé comme une discussion en cours. Le champ résumé devient une "Synthèse (NDT : comment traduire digest le nom)" des modications faites sur la page, une chronique (article de journal, GroupWeblog?) de ce qui a transpiré sur cette page dans l'historique récente. Les événements vraiment vieux ou non pertinents peuvent être supprimés à la main et des choses nouvelles et intéressantes peuvent être fournies de façon naturelle (plutôt qu'une simple liste séquentielle). Ceci est plus proche de la voie du wiki où tout peut être remanié.

Parce que la page des ModificationsRécentes ne fait pas partie de l'InstantWiki, mais bien d'un mécanisme permettant la RévisionParLesPairs et la Communauté, cela fait du sens de démarrer un nouveau résumé quand la dernière révision est ancienne (disons le délai des PagesConservées).

Implémenter ceci est aussi simple que d'élargir la boîte résumé, de la renommer en "Digest" et en remplissant le champ avec le résumé précédent.

Voir aussi ModificationsDigérées.

LangueFrançaise PageTranslation DigestedSummary DossierTechnologieWiki DossierTechnologieWikiNoncommune DossierModificationsRécentes

Une compilation de pensées et commentaires

Durée de Vie du Résumé

Sur EmacsWiki:2005-05-01 j'ai un utilisateur rapportant qu'en fait la plupart des gens ne changent pas le résumé, ce qui donne des résumés trompeurs. Je ne suis pas sûr à ce stade comment arranger ça -- peut-être que le vieux résumé est en fait ce que les lecteurs à basse fréquence (comme Bayle ou Scott) attendraient. Alors c'est simplement une question de réinterpréter ce à quoi sert le résumé. En tant que travail connexe, j'ai suggéré de réduire plus à fond la "durée de vie du résumé" à environ 2 à 3 jours -- bien plus court que l'expiration des pages conservées. Après quelque discussion supplémentaire, j'ai décidé de réduire la durée de vie du résumé à quatre heures. -- AlexSchroeder

As-tu mis à jour le texte présentant le champ résumé ? Je suggérerais aussi de réduire la taille du champ édition. Sur la plupart des navigateurs, vous ne verrez même pas le champ "digest" à moins que vous ne sachiez où regarder parce que c'est tout en bas de la page ; et y'a t'il quelque raison d'avoir une édition de "digest" de 80 lignes quand un résumé si gros inonderait les ModificationsRécentes ? -- ChrisPurcell

Hé bien, j'ai des personnes me disant explicitement qu'elles ne veulent pas un résumé de ce qui se passe -- elles veulent un commentaire seulement sur la dernière édition... J'ai essayé d'expliquer le concept sans renommer le champ. Mais je ne pense pas qu'elles l'apprécient.

Tout comme pour la taille du champ résumé, je pense que ton navigateur échoue à prendre note de la CSS que j'utilise -- mon champ d'edition fait 3 lignes de haut. Je devrais le tester aussi avec d'autres navigateurs. Sur IE le champ édition fait deux lignes de haut. Je m'interroge sur ce que tu utilises. -- AlexSchroeder

[La CSS que tu utilise] dicte "textarea { width:100%; height:80%; }". C'est probablement le problème ici : Safari utilise la balise de hauteur de la CSS, pas le HTML. -- ChrisPurcell

Ah, je testerai dans Safari quand je rentrerai à la maison. J'utilise aussi maintenant la suivante : 

    textarea[name="text"] { width:100%; height:80%; }
    textarea[name="summary"] { width:100%; height:3em; }

Composition Automatique de Résumé

En regardant à quoi ressemble une entrée typique de ModificationsRécentes, j'ai noté une forme :

(Costin) back to Adam Smith (Helmut) Added a reference to WikiIsParadoxical. Some additional criticism. (Costin) In favor of MinimalistLaw as a self-evident principle.

Ce que je vois est que nous adopté comme une convention pas un "résumé digéré" mais la concentration de résumés d'éditions. Il me semble que nous pourrions simplement concaténer des résumés d'édition à l'ancienne mode, préfixer chacune avec les auteurs respectifs et obtenir le même résultat.

(none)
In favor of MinimalistLaw as a self-evident principle.
Added a reference to WikiIsParadoxical. Some additional criticism.

Changé en :

ChrisPurcell
CostinCozianu: In favor of MinimalistLaw as a self-evident principle.
HelmutLeitner: Added a reference to WikiIsParadoxical. Some additional criticism.

Au lieu de ce que nous avons maintenant (voir exemple au-dessus).

-- AlexSchroeder

Oui, le RésuméDigéré a cela en tant que comportement dégénéré. Si les résumés sont courts, quels seraient les avantages de les digérer ? Néanmoins, dans les pages qui bougent plus vite, le résumé est véritablement en train d'être digéré.

Vous perdez aussi le bénéfice de la correction rétroactive de digest-spam si vous concaténez simplement. Voudrions-nous vraiment un "poo to you" provenant d'un spammer sur les ModificationsRécentes ?

(Tu as aussi raté mes modifications CopyEdit dans ton exemple :) -- ChrisPurcell

Hé. Je n'étais bien sûr seulement intéressé que par les modifications majeures. -- AlexSchroeder

A propos du nouveau style des ModificationsRécentes

Vu que vous aviez posé la question de savoir pourquoi une autre personne ne l'aimait pas. Et bien dans mon cas, je l'aimerais beaucoup plus si je pouvais utiliser un affichage d'une ligne comme avant. Parfois, il est mieux d'utiliser le nouveau format si le résumé digéré a beaucoup de choses dedans. Merci de votre attention. -- DavidLiu

Merci de ton commentaire, David. Même si je reviendrai en arrière vers le vieux format si les gens le désirent, je veux donner la chance de voir le nouveau format et des commentaires. Tout changement est par conséquent en train d'aller délibérément vers le glacial. -- ChrisPurcell

J'ai été un peu sévère plus tôt, mais oui j'aime "aussi" vraiment le nouveau design.

-- DavidLiu

Sur la théorie que le problème principal avec le schéma alternatif était d'être trop occupé, je l'ai changé à nouveau. Cette fois-ci, les digestions ne sont pas graissées, mais seulement sur un fond gris (je promets qu'il est facile de restaurer l'original !) -- ChrisPurcell

Est-ce que résumé blanc s'efface lui-même automatiquement après quelques modifications, ou quoi ?

Pour être honnête, je préfère le vieux système. -- EarleMartin

Le système se réinitialise après une période d'inactivité - voir RésuméDigéré. -- ChrisPurcell

Bon. A cette heure, le digest dit "Earle, Sunir and Alex provide some feedback for this feature". Devrais-je ajouter quelque chose, parce que je vous réponds ? Le changer complètement ? Ou le laisser parce que cela couvre cette discussion que nous avons ?

Je pense que ce que je n'aime pas à ce propos est que cela me fait hésiter avant de sauvegarder la page. Le système d'avant ne sollicitait pas les neurones. -- EarleMartin

Je sais, c'est gênant, nous nous mettons en route pour fournir une page ModificationsRécentes digérée de meilleure qualité et c'est toujours sur la voie de nécessiter la pensée, pas un problème de système. La question est de savoir s'il y a une façon de faire ça qui génère moins de souffrance ou est-ce que la souffrance est minime ? -- ChrisPurcell

Je ne suis pas sûr de comprendre comment cela fonctionne. Je pressens même fortement que c'est d'une certaine façon la mauvaise voie. Les éditions individuelles sont individuelles, et ont besoin de résumés individuels. Je demeure intéressé par un résumé global sur un ensemble de modifications (ModificationsDigérées). (apparemment) Ward pensait aini faire fonctionner les Wiki:RecentChanges, ce qui est encourageant. -- SunirShah

Je n'ai pas vu quelque implémentation des ModificationsDigérées qui soit véritablement maintenue. Si cela était possible, j'aurais travaillé pour Wiki:TheSimplestThingThatWorks, en modifiant nommément Wiki:RecentChanges. Je soupçonne qu'à moins que tout ce qui soit requis pour faire une édition soit sur une page unique, les quelques bits "en plus" seront rapidement oubliés. -- ChrisPurcell

Le seul problème que je vois à cette heure est qu'il ya deux types de résumés de modifications. Le résumé pour cette modification, et le résumé pour l'ensemble des modifications qui consituent l'événement. Je me trouve moi-même en situation de ne pas écrire de résumés pour mes éditions, ce qui, je pense, rend plus difficile la RévisionParLesPairs. Si nous faisions à la place un RésuméDigéré pour chaque section sur les ModificationsDigérées qui réfèrent à cette page, ceci ferait beaucoup plus de sens. Et au moins avec les ModificationsDigérées, le RésuméDigéré serait pour toutes les pages incluses dans cet événement en même temps (presque comme une SuperPage?). -- SunirShah

Hmm. Je trouve qu'au moins dans mon workflow, la RévisionParLesPairs veut dire regarder une diff. Je choisis la version vers diff contre celle fondée sur la dernière version de la page que je me souviens avoir vue et approuvée (au moins quand les PagesConservées n'ont pas échoué). Selon moi, un résumé d'édition n'a jamais fait partie de ça. Je serais intéressé par la technologie qui a facilité la validation de la diff la plus sensible. Est ce que cela concorde avec les expériences d'autres personnes ? -- ChrisPurcell

Je pense qu'il y a de la valeur à écrire des résumés pour chaque modification. J'admettrai que cela ne doit pas être une interface spéciale, simplement une convention. Faire qu'un point forme des notes qui peuvent être plus tard retravaillées une fois qu'elles se résolvent en quelque chose de cohérent. Supposez que le résumé ait été parsé comme WikiSyntax ? J'admets que c'est une gêne avec UseModWiki. -- SunirShah (I think there's value in writing summaries of each change. I will admit that this doesn't have to be a special interface, merely a convention. Making point form notes that can later be reworked once they resolve into something coherent. Suppose the summary was parsed as WikiSyntax? I admit this is a pain with UseModWiki. -- SunirShah)

On peut maintenant avoir une convention sociale - ajoutez votre modification simplement au résumé ;) Nous pouvons toujours lancer ensemble une syntaxe spéciale si une véritable convention émerge. (Le code supporte déjà les éditions précédentes catégorisées par un astérisque.) -- ChrisPurcell

Il ne le supporte pas. Regarde. -- SunirShah

Je me suis mal expliqué. Je voulais dire que si vous faites précéder une édition catégorisée par un astérisque, ou la suivez avec la ponctuation, par exemple "* [CopyEdit: some copy-editing];", alors l'astérisque précédent et suivant la ponctuation sont retirés le long du bit catégorisé. J'ai fait ça parce que j'ai vu plusieurs occasions où des astérisques, des plus, etc. sont utilisés pour séparer les éditions catégorisées, et cela ne ferait pas de sens pour eux de rester visibles. De la même façon, si l'astérisque devient un moyen conventionnel de séparer les mises à jour non-digérées, nous pouvons produire une syntaxe pour le supporter. (J'ai fait cela dans un des prototypes originaux.)

Ce qui serait aussi tout à fait utile serait de maintenir le retour chariot dans le digest. Je ne suis pas sûr de la raison pour laquelle il est éliminé, aussi, vais je réparer ça sans consultation. -- Chris

Je me suis éloingé du MeatballWiki depuis quelque temps et revient pour trouver le nouveau format des modifications récentes. Est-ce que c'est la page qui décrit la situation en cours ? Si c'est le cas, est-ce que quelqu'un pourrait être clair sur toutes les interactions et retravailler cette page pour retirer tous les bits prêtant à confusion ? Je ne pressens pas connaître l'histoire suffisamment bien pour faire cela moi-même. Il semble simplement que les personnes renvoient à beaucoup d'itérations différents de solutions, bon nombre d'entre elles qui n'existent plus. -- TedErnst

Fait. Je pense que la plupart s'applique encore. -- ChrisPurcell

Peut-être qu'une solution à la confusion sur la façon d'utiliser le résumé, tout comme la manière dont les EditionMineures tendent à effacer le résumé, ceci pour ne pas mentionner ma réticence à éditer maintenant le résumé quand je ne peux pas trouver réponse à ce que je veux dire, est d'avoir deux champs résumés. En avoir un en une ligne pour la modification en cours, qui peut être appliqué aux éditions mineures si c'est ainsi choisi. Retourner à la boîte à cocher EditionMineure. Disposer d'une aire de texte pour le résumé global. Je pense que j'ai vraiment proposé cela avant, w.r.t. ModificationsDigérées. -- SunirShah

Ceci rendrait l'historique de page plus élégant. Cecla voudra probablement aussi dire que les personnes ne mettront pas à jour le digest, parce qu'elles commenceront par devoir tout écrire en triplicata. Je refuse aussi d'autoriser les éditions mineures :) J'ai vu beaucoup de gens ne même pas utiliser le champ résumé quand c'est un simple résumé d'édition, aussi pourquoi s'en soucier ? Signalez simplement aux personnes le CommentFaire. -- ChrisPurcell

Je n'aime pas le 'résumé digéré'. Je pense l'avoir déjà dit, mais ça s'est perdu. Deux objections : cela alourdit le travail sur le processus d'édition. Ce n'est pas bon pour les débutants wiki, pour ceux même pour qui la simple idée de saisir un résumé d'édition est trop à leur demander. L'afichage de l'historique de la page devient encombré avec de longs résumés, où avant nous avions quelques mot apparaissant à côté de quelques-unes des éditions. Basiquement, l'ensemble de la conception wiki perd de son élégante simplicité. Je peux y voir quelques avantages néanmoins, et ainsi cela fait du sens que de l'expérimenter ici sur meatball, où la plupart d'entre nous sont des utilisateurs wiki expérimentés, ouvert aux nouvelles idées/fonctionnalités. Je suis supris que le groupe soit agglutiné là-dessus depuis si longtemps.

En tout cas, je note que les développeurs du moteur OddMuse ont maintenant adopté cela, ce qui veut dire que de nouveaux wikis commenceront à apparaître sur le web avec cette modification de design. Quelle était l'intention ? C'est un pas en arrière si vous me le demandez. -- HarryWood

Je suis d'accord avec vous sur les historiques de page. Je mettrai le temps dedans sous peu. Néanmoins, je pense que l'audience mérite infiment plus de considération que les nouveaux venus, pour deux raison : un, les nouveaux venus s'arrêtent rapidement d'être des nouveaux venus, parce que l'audience reste toujours une audience ; deux, la RévisionParLesPairs peut corriger manuellement les erreurs tout comme elle peut corriger les fautes d'épellation. -- ChrisPurcell

J'ai aussi noté cela avec une mise à jour récente OddMuse et n'ai pas d'expérience avec en dehors de cela. L'implémentation d'OddMuse semble très confuse et incohérente pour moi. Jusqu'à ce que m'on dise que cette page explique ce qui se passe, c'était vraiment étrange. Les notes de révision étaient maintenant lourdes mais seulement de temps en temps. La nouvelle révision multilignes de la boîte de texte de notes a été l'une des premières choses que j'ai remarqué et qui m'a paru étrange. Elle était toujours utilisée pour être une note résumé/courte, vous n'aviez pas besoin de beaucoup de place. Un peu de ça j'en suis sûr est dû à l'implémentation et peut être amélioré, mais rester cohérent est important.

Ce que j'ai trouvé de vraiment ennuyeux est que les nouvelles éditions chargeaient quelque fois les notes de révisions avec le texte nouvellement ajouté incluant tous les codes de mise en page ou liens. Là où j'ai remarqué ça est une édition d'un spammer et elle va probablement simplement charger n'importe quelle aire de texte avec son spam identique. Quelle que soit la cause, cela encombre certainement l'historique de révision. Si cela est provoqué par le spammer attaquant toute aire de texte, ce devrait être certainement quelque chose à penser. Quel est le niveau de facilité pour revenir en arrière sur un résumé digéré écrasé ?

Je ne sais pas si je suis d'accord avec le souci d'Harry à propos des nouveaux venus. Ils peuvent et ignoreront probablement jusquà ce qu'ils comprennent. Je pense que cela étend vraiment à presque tous, pas pour mal le comprendre, mais parce que c'est peu pratique. Quelques mots pour un résumé est généralement tout ce dont a besoin une révision. Ce n'est pas vraiment utile pour un fil RSS. Autre que le fil RSS utilisé pour le résumé, cela me rappelle les pages discussion du MediaWiki. Les pages Discussion sont bien pour certains wikis, d'autres n'en ont pas besoin. Je pense que le RésuméDigéré peut être comme ça, j'espère qu'il est optionnel s'il reste aux alentours. Bien sûr, il devrait être maintenant en compatibilité descendante avec le digest pour ceux qui le reçoivent dans une mise à jour. Le fait de tronquer serait assez bien probablement parce que ceux qui reviendraient en arrière avec l'ancienne méthode n'utiliseraient pas le résumé comme prévu.

Cela peut avoir été déjà suggéré, mais une alternative qui pourrait fournir quelque chose au fil est de concaténer les résumés d'édition à partir des dernières éditions (fondées sur un intervalle de temps similaire déjà utilisé pour le RésuméDigéré). Les personnes devraient produire leurs résumés d'éditions de manière un peu plus descriptives, mais dans tous les cas les personnes devront s'y habituer. -- JoeChongq?

Alors qu'on ne peut pas retirer un digest de résumé d'un spammer de l'historique de la page (trop vulnérable aux violations), on peut l'enlever des ModificationsRécentes. Ceci n'est pas pas possible si on concatène simplement les résumés d'éditions. (Ceci a déjà été mentionné au-dessus, aussi c'est probablement une raison de le garder au moment d'écrire tout cela en ModeDocument.)

Si votre communauté utilisant OddMuse trouve difficile de se faire au RésuméDigéré, essayez de la guider en en produisant ! Quand vous avez pratiqué la RévisionParLesPairs sur les modifications produites sur une page, foncez et écrivez un digest décent si les derniers auteurs ne l'ont pas fait. On n'a pas besoin d'éditer le texte de la page (en plus d'ajouter un retour chariot pour éviter d'être traité comme un no-op) pour nettoyer le résumé, même si les corrections d'orthographe sont toujours une autre bonne tâche de RévisionParLesPairs. -- ChrisPurcell

Commentaire migré vers RésuméDigéréRésultatsEmpiriques

Ceci est essentiellement copié à partir de [notre wiki] où nous avons discuté comment les résumés touchent le [WikiMinion], le robot antispam de RichardP?. WikiMinion? utilise actuellement le champ résumé pour noter quelle action il a fait (comme une révision qu'il a réinitialisée) afin qu'un humain puisse plus facilement diagnostiquer et corriger les erreurs produites par le robot. Richard a dit "only one or two wikis protected by WikiMinion? are running a new version of OddMuse (and hence are now theoretically using digested summaries) and they're so low traffic that they're pretty much always behave like a wiki that does not use digested summaries."

En imaginant que cette digestion soit étendue à d'autres wikis comme MediaWiki, tout spécialement Wikipedia parce qu'ils utilisent un certain nombre de robots pour différents buts, il y a besoin de quelque moyen standard pour les robots de laisser de l'information. Un robot n'est pas capable d'écrire un résumé propre, tout ce qu'il peut faire est d'écraser ou ajouter au résumé précédent.

La page édition ici mentionne un moyen d'enregistrer des modifications non-discussion comme ceci en utilisant les crochets rectangulaires.

Mettez entre crochets rectangulaires le "copy edit" ou le revirement de spam avec [CopyEdit: ...] ou [WikiSpam: ...]

Mais je ne pense vraiment pas que l'information appartienne au digest. Le but du digest est de donner une compréhension qui a été poursuivi longtemps sur la page et de fournir un fil RSS ayant du sens. Pour ces buts, le digest est bon s'il est utilisé comme prévu. Je ne pense pas que l'information sur le "copy editing" et le nettoyage de spam appartienne au digest, mais il n'y a pas d'autre moyen d'enregistrement où cela peut prendre place. Ces données nont pas ajouté quoi que ce soit à la discussion ou à l'évolution de la page, aussi pourquoi devraient t'elles être incluses dans le digest ?

Alors que l'historique de révision globale peut être plus informative, les historiques de pages sont moins informatives. Les historiques de révision ne sont plus pertinentes pour une révision unique. Au lieu de regarder des notes courtes, vous devez lire les digests les plus longs et trouver ce qui a changé entre eux pour localiser la révision que vous voulez. Allons-nous avoir besoin de diffs sur les historiques de digest ? Cela ne ferait meêm pas de sens. -- JoeChongq?

Vous devez vous souvenir que sur MB, les crochets rectangulaires comme ceci sont automatiquement retirés du fil RSS et aussi des ModificationsRécentes pour la plupart des lecteurs. Jetez un oeil sur CatégoriesModification. -- ChrisPurcell

Ce sera seulement ma troisième édition ici en plusieurs mois aussi je suis généralement acclimaté avec l'implémentation OddMuse qui apparemment a un moyen d'aller pour rattraper MB. Une fois que le filtre crochet est ajouté à OM, ceci résoudra le problème du robot auquel je pense. Nous avons aussi trouvé que la date d'expiration sur les résumés digérés sur OM n'est que de seulement 4 heures. Pour un wiki même bien parcouru, c'est probablement trop court, cela l'est même certainement pour un wiki utilisé modérément si les résumés sont utilisés comme prévus. -- JoeChongq?

Où devrait arriver la "digestion" ?

ChrisPurcell a dit sur RésuméDigéréRésultatsEmpiriques que l'historique de page peut être le bon endroit.

Quand les personnes éditent une page, leur première réaction est d'écrire une entrée de journal dans le champ résumé. Elles résument uniquement leur modification, en ajoutant leur texte, ou pensent que leur modification n'a pas besoin de quelque explication. Les chiffres actuels sont respectivement de 44% et 15%, mais nous avons besoin de comptabiliser le fait que 29% des modifications sont des modifications de "follow-on", par exemple le meme auteur a jugé non nécessaire d'écrire un résumé, ce qui pourrait indiquer que les véritables ratios soient 44/71 et 15/71 au lieu de 44% and 15%.

Il me semble que ceux qui éditent les pages ne sont pas vraiment intéressés pour résumer les discussions récentes dans le champ résumé d'une page.

Cependant, il semble y avoir un intérêt à fournir de tels résumés. Les VisiteurRare?s aimeraient les voir sur les modifications récentes. Ce qui nous amène à deux questions : Qui les écriraient, et où écriraient t'ils ces résumés ? Si nous supposons que ceux qui résument les activités ne sont pas ceux qui écrivent la page, alors je pense qu'il devrait être évident que la page d'édition ne soit pas le bon endroit pour faire ça. En outre, beaucoup d'implémentations wiki ne sauvegarderont pas une édition à moins que le texte de la page ne soit modifié. Il y a un endroit où nous pouvons regarder les modifications en une page unique, la page historique. Si vous pouvions éditer le résumé en cours (en écrasant le résumé de la dernière édition) à cet endroit, alors peut-être que cela donnerait aux bonnes personnes la bonne information pour écrire le résumé, et de placer le résumé là où les rares visiteurs le verront véritablement : Sur la dernière édition visible sur les ModificationsRécentes. -- AlexSchroeder

Un trio de pensées : (1) Toute implémentation wiki sauvegardera une édition si vous la programmez pour - permettre simplement à tous les posts à partir de l'historique de page de réussir. (2) Si vous écrasez le dernier log, vous retirez la PisteAudit et toute possibilité de revenir en arrière sur les digests de spam, ainsi c'est dehors. (3) Les nombres sur cette page ne supportent pas votre conclusion que "ceux qui éditent les pages ne sont pas vraiment intéressés pour résumer les discussions récentes", tout simplement parce qu'ils ne les réfutent pas. -- ChrisPurcell

Je suis d'accord avec ta raison au sujet du retour en arrière de spam, si le résumé est une cible pour le spam ou le vandalisme. Comme pour les nombres, où n'es tu pas d'accord ? Il me semble que 44% ont simplement on ajouté au résumé, 15% n'ont rien fourni, 3% l'ont digéré, et nous pouvons ignorer les autres (mauvais usage, spam et modifications de follow on). -- AlexSchroeder

Les chiffres ne nous disent pas quels résumés ont été digérés. Les CopieStableRésultatsEmpiriques? nous disent que 90% des périodes instables n'ont probablement pas besoin de résumé - étant trop courts - et même pour les 10% restants, le résumé n'est certainement pas exigé sur chaque édition. Durant les plus longues périodes instables, la digestion peut être simplement aussi simple que d'ajouter un petit mot à une phrase existante, qui est compté comme un ajout dans l'alogrithme que j'ai utilisé. -- ChrisPurcell

Une prochaine étape logique est de permettre une syntaxe wiki arbitraire dans le champ résumé. Nous pourrions ensuite 1) parser cette syntaxe sur la page historique ; 2) la parser sur les ModificationsRécentes ; et 3) l'émettre dans le RSS comme CDATA plutôt que comme texte brut. L'effet net est que si vous choisissez d'utiliser le résumé de la sorte, vous pouvez produire des ModificationsRécentes et du RSS bien plus proche du blog.

LangueFrançaise PageTranslation DigestedSummary

Discussion

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