[Home]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 :

Améliorations possibles :

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 :

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é.

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.

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

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 :

Mais est-ce important ? 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

Discussion

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