HistoriqueVersion

MeatballWiki | RecentChanges | Random Page | Indices | Categories

Cette page a démarré sur VersionHistory

Une historique de version enregistre les versions antérieures d'une page, de telle manière qu'elle puisse être retrouvée à une date ultérieure.

: 1. Implémentations
: 2. Pourquoi fournir quelque historique de version ?
: 3. Pourquoi ne pas fournir d'historique de version ?
: 4. Pourquoi fournir une historique complète de version ?
: 5. Pourquoi ne pas fournir une historique complète de version ?
: 6. Pages clouées
: 7. Pages bifurquées

[DossierTechnologieWiki]

1. Implémentations

Beaucoup d'idées ont été proposées pour les schémas d'historique de version. Elles comprennent :

Pas d'historique de version (MetaBaby, WikiWiki original)
CopieModification : la copie de l'auteur précédent est conservée comme une sauvegarde. Par conséquent le vandalisme permanent requiert au moins deux auteurs. (WikiWiki plus tard)
CopieStable? : La dernière version non modifiée pour un jour ou plus est conservée comme sauvegarde. Le vandalisme permanent requiert une journée sans intervention. (PeriPeri)
VersionsConservées? : obsolète par les PagesAuteur?. L'implémentation autoriserait chaque auteur à marquer certaines révisions pour "conservation". Elle a été rejetée parce qu'elle ne permet pas de PardonnerEtOublier.
PagesAuteur? : Rendues obsolètes par les PagesConservées. L'implémentation serait plus complexe, en conservant la dernière copie de chaque auteur durant un certain laps de temps.
PagesConservées : Conserver les plus vieilles révisions (sans se soucier de l'auteur) durant un certain laps de temps seulement. Ceci permet de tout PardonnerEtOublier en nous permettant encore de RéinitialiserPage?s. (UseModWiki)
HistoriqueComplète de chaque (MediaWiki)

Améliorations possibles :

Fournir des UseMod:DifferenceLinks entre les versions dans l'historique de page
Classement des modifications par le même auteur en une seule modification. Soit classer les changements consécutifs par le même auteur ensemble, ou effacer toutes les autres révisions par l'auteur récent. Ceci ne fonctionne pas pour les WikiPersonnels tout comme les sites qui distinguent leurs auteurs par les adresses IP qui attirent aussi des utilisateurs multiples à partir d'un seul domaine.
FractalWiki utilise une historique de version cachée qui est seulement visible pour certains utilisateurs.
WayBackMode ala Wiki:CvWiki
Stocker les deltas ou compresser les anciennes versions pour minimiser l'espace (au coût du temps CPU)
Quelques pages et quelques pages seulement sont "versionnées". Utile pour des choses comme les journaux de projets ou WikiAsSourceControlRepository.
HistoriqueVisualisationFlux? - voir comment une page a changé au fil du temps.

En plus, les utlisateurs peuvent toujours archiver les versions de pages qu'ils souhaitent protéger sur leurs propres disques durs, et les copies peuvent être archivées par Google, ou par l'InternetArchive?. Ceci permet une protection limitée même sur des sites sans historique de version. Pour conclure, vous pouvez créer une historique manuelle en copiant périodiquement une page à l'intérieur des vieilles versions archivées.

2. Pourquoi fournir quelque historique de version ?

L'historique version aide un wiki à se relever du vandalisme, comme l'est une ModificationRéversible. Ceci veut dire que les utilisateurs peuvent mieux dormir. Une historique complète ou les PagesConservées, fournit en fait une protection complète contre les vandales. La CopieModification fournit une protection limitée, mais ne protège pas contre les agresseurs malicieux et instruits. Tout comme pour les vandales agissant délibérément, l'historique de version protège aussi contre le "vandalisme" accidentel des nouveaux venus.

L'historique version réduit les ProblèmesRemaniement : l'historique donne aux personnes toute confiance pour s'engouffrer sur une page. Les personnes se sentent plus libres pour retirer le contenu de la version en cours parce que les vielles versions resteront disponibles durant un laps de temps décent. Les programmeurs en particulier seront conscients du niveau de facilité pour modifier radicalement le code avec la confiance d'une source sauvegardée et avec un répertoire de code-source. La même chose s'applique à d'autres contenus, bien que ce se soit moins important si vous valorisez la CommunautéSurContenu.

Aussi :

Permet la RévisionParLesPairs des modifications (cf la PisteAudit)
Rassurer les contributeurs (cf PerceptionDeVulnérabilité?)
Utile si une GuerreEdition doit être résolue

3. Pourquoi ne pas fournir d'historique de version ?

L'historique de version protège aussi le travail des agresseurs. Par conséquent, l'agresseur peut simplement comme un défenseur facilement RéinitialiserPage?. Ce problème peut être réduit en produisant une historique difficile à obtenir (SécuritéParObscurité) ou en la rendant disponible seulement à des utilisateurs privilégiés (NiveauxAccès).

4. Pourquoi fournir une historique complète de version ?

Une historique complète décourage les vandales : parce que quiconque peut ajouter des mots grossiers et les avoir ainsi stockés pour la postérité, nous pratiquons ainsi le LimiterLaTentation?. En particulier, ceci décourage les vandales de rajouter maintes fois le même morceau de vandalisme dans effort de l'empêcher d'être à jamais complètement supprimé.

Fournit un CréditPaternitéOeuvre? (mais il existe d'autres moyens de faire cela)
Nécessaire pour un site sous la LicenceDocumentationLibre? (mais est-ce la meilleure licence CopyLeft pour un wiki ?)
Renforce le DroitDePartir et le DroitDeBifurquer : les contributeurs peuvent retrouver le texte exact qu'ils ont proposé et le réutiliser sans CopyrightParanoia (mais est-ce que ces droits affaiblissent la communauté ?)
Permet une analyse formelle de la façon dont les articles évoluent : par exemple il existe des projets pour analyser les articles WikiPedia à partir de cette perspective, comme la VisualisationFluxInformation?.
Permet de citer des versions spécifiques des articles : CocktailContenu.

Une historique complète est aussi agréable pour la nostalgie, et pour démontrer que le processus wiki fonctionne. Cependant, vous n'avez pas besoin d'une historique complète pour ça : des captures d'écran régulières serviraient le même objectif. Alternativement, un CarnetModification? peut aussi servir la nostalgie et ce même sans les contenus des pages

: [1] - vous pouvez voir qui a parlé sur une page, son niveau d'activité et les résumés d'édition.

5. Pourquoi ne pas fournir une historique complète de version ?

Une historique complète encourage le vandalisme en le conservant pour la postérité. Ceci permet "les performances d'artistes de usenet" et assimilés de faire un lien vers la version vandalisée pour démontrer leur humour supérieur et leur socio-empathie.

Une historique complète rend plus délicat le retrait des violations de copyright. Cela peut se discuter, les violations de copyright dans l'historique sont acceptables, parce que l'HistoriqueVersion n'est pas en train d'être "publiée", mais c'est plutôt un "outil éditorial" pour aider des utilisateurs à construire des articles. Les personnes qui se plaignent des violations de copyright sont généralement satisfaites du retrait du contenu de la version en cours, se souciant beaucoup moins de l'historique, par conséquent défendez-vous contre la CopyrightParanoia.

Tous les membres d'une communauté doivent être conscients du pouvoir de destruction

potentiel de leur wiki et doivent défendre leur wiki. Ceci renforce le sentiment de communauté.

Une historique complète mâche de l'espace de stockage
Une historique complète contrecarre le PardonnerEtOublier (plus important).
Ne disposer que d'une historique limitée de version valorise le WikiMaintenant?.
L'historique complète bloque le DroitDeDisparaître.

6. Pages clouées

Au lieu de garder beaucoup de pages, conservez (ou clouez) une copie de la page. La prochaine fois que quelqu'un cloue une page, détruisez l'ancien clou. De cette façon, quand une page se stabilise -- disons après un remaniement --, vous pouvez la clouer et continuer avec une discussion.

: J'ai aussi pensé à ça et j'ai appelé cela les pages "acceptées".

Je peux produire une telle option pour des sites qui veulent soit plus de contrôle éditorial (les versions acceptées pourraient être ce que les utilisateurs ordinaires voient) ou soit ne veulent pas conserver des versions plus anciennes. Une différence est que je limiterais les personnes qui peuvent accepter une page (Je ne pense pas que la fonction "pages acceptées" arrivera sur Meatball.) -- CliffordAdams

7. Pages bifurquées

Faire exister une page dans un espace-temps non linéaire ! Permet aux utilisateurs de bifurquer une copie de la page qui est aussi éditable (bien que non nécessairement bifurquable). Seule la dernière version du fil principal de la page est directement pointable. Le reste peut aussi être vu à travers une vue protégée "historique de cette page". Ceci permettra aux versions d'être produites simplement pour que les corrections soient faites pour retirer la gêne.

: Mon point de vue est qu'une version sans entrave des vieilles erreurs

devrait être simplement retirée (probablement avec quelque contenu copié ailleurs). Dans des circonstances exceptionnelles la totalité de la page pourrait être ôtée et redémarrée avec le contenu actuel. Les auteurs auront probablement plus de contrôle sur leurs contributions et leurs "pages personnelles". -- CliffordAdams

Je pensais que cela était intéressant, parce que sur EnglishWikipedia nous en sommes venus à des bifurcations efficaces : implémentées de deux façons :

La version bifurquée va dans une page "/temps" et est développée là. Ceci cause des problèmes pour le CréditPaternitéOeuvre?, quelle que soit la façon dont la bifurcation est résolue, l'historique est perdue.

Mais est-ce important ?

Les deux versions co-existent sur la même page - si la version A est la page en cours,

alors on charge la version B à partir de l'historique, on produit les éditions et on les sauvegarde de nouveau sur le sommet de la version A. Ceci rend les diffs plus complexes et représente souvent une source de conflit.

Ce serait intéressant d'avoir un support explicite de bifurcation dans le logiciel - pourrait aider à ElargirEspace. Cependant, je soupçonne que cela puisse représenter un énorme travail de code pour si peu.

: ''Vous pourriez résoudre la perte de l'historique et parvenir à une forme de bifurcation

en permettant aux pages d'être copiées et renommées. Copier ArticleDisputé vers ArticleDisputé/temp et l'historique est copiée. Renommer un ArticleDisputé/temp plus tard comme ArticleDisputé et la nouvelle historique est migrée avec elle. Vous pourriez même conserver les deux versions dans les sous pages, les liant toutes les deux vers elles à partir de la page principale, et ripper dans n'importe laquelle celle dans laquelle on "gagne" en fait.

: Ceci est PointDeVue.

: ''Je n'irai pas si loin. Tout le monde peut visualiser chaque bifurcation,

vous ne pouvez pas avoir différentes pages mappant vers le même nom pour différentes personnes, etc. Tout ce que je suggère est que vous puissiez dupliquer l'historique d'une page sur une autre (nouvelle) page.''

Un exemple de la relation entre certaines fonctionnalités wiki et la voie du wiki est la disponibilité des diff. PyWiki? par ex. n'a pas de diff. Bien sûr Denham l'utilise en priorité comme un PIM, même s'il invite des contributions. Mais du fait du manque de diff combiné avec des pages plutôt longues, il est difficile de travailler de manière normale. Ainsi PyWiki? n'est pas d'une grande utilité pour des intentions de communication et demeure plus ou moins un PIM.

-- HelmutLeitner

Je pense qu'il serait intéressant que nous pensions à une HistoriqueVersion nécessaire pour le crédit de l'auteur, quand une simple liste de contributeurs serait suffisante. Après tout, il est inutile d'essayer d'attribuer chaque mot écrit dans un effort collaboratif.

''Cette page ne fait pas état qu'une historique complète de version est simplement un moyen de donner le CréditPaternitéOeuvre?, et probablement pas le meilleur moyen. Le CréditPaternitéOeuvre? comporte beaucoup plus de détails, y compris l'option TagContributeur? que tu mentionnes.''

Ce serait utile en WikiSciencePublication d'être capable de retenir les liens durs vers des versions antérieures des articles scientifiques si ces articles scientifiques étaient ouverts pour être édités. Une critique d'un article devrait pointer vers les versions de l'article qui fût récemment critiqué, pas la version actuelle. Une bonne version. Une bonne page de système historique pourrait faciliter l'accès hypertexte des liens "médiatés" vers les vieilles versions des articles. -- JohnSchmidt

LangueFrançaise PageTranslation VersionHistory