Conflit Édition

importé de Bonnes Pratiques Qualité Pour Les Wikis Discussion, cette page sera remaniée pour la rédaction des Bonnes Pratiques Qualité Pour Les Wikis.

Ajout d'une idée qui me passe par la tête : (mais à discuter directement sur Opquast ?)
La +/- bonne façon de gérer (au niveau système) ou de prévenir (niveau usage) les conflits d'édition ? Par expérience, c'est assez pénible quand ça arrive, qu'on n'est prévenu d'un conflit qu'au moment de la sauvegarde de la page, et qu'il faut faire des pieds et des mains parce que votre contribution se chevauche de partout avec les modifs sauvegardées juste avant. Plus simple quand votre contribution est un bloc, qui s'ajoute. L'outil peut aider en mettant en regard les diffs (avec des codes couleurs, etc.). Ne serait-t'il pas également intéressant de disposer d'un "verrouillage/contrôle de ce verrouillage" au moment de l'ouverture en édition d'une page ? Et qui nomme l'utilisateur courant (à associer à des témoins de présence) ? -- Sébastien Sauteur

Bonjour Sébastien,
Actuellement, existe t-il une technique qui soit déjà opérationnelle sur les principaux wikis?
Une telle solution existante dès maintenant nous permettrait de commencer à travailler sur une proposition, sachant que très probablement, nous serions plus dans ce cas précis proche d'une recommandation que d'une bonne pratique applicable et répandue. Ca ne pose pas vraiment de problème, mais il vaut mieux le savoir. Si tu veux aiguiller le débat dans cette voie, il faut qu'on commence à lister les méthodes existantes qui répondraient à la problématique "Prévention et correction des confilts d'édition". --Elie Sloïm

Bonjour tous,
je n'ai toujours pas fait de session MoonEdit, mais dans mes fantasmes, j'imagine une sorte d'écran noir façon terminal UNIX, sur lequel chacun déplace son curseur et peut faire une sorte d'édition de texte en parallèle. Parfois j'imagine même que chacun se matérialise sous la forme d'un caractère @ de couleur différente, et peut déplacer des rectangles de texte en les poussant, killer des lignes ou les dupliquer, voir faire des choses amusantes comme dans le jeu rogue où le caractère peut creuser des galeries ou envoyer des projectiles (pour certaines "GuerreDuFeu+s", ce comportement logiciel serait salutaire...). Mais bon, ce sont mes fantasmes. Pour en revenir à ce que tu dis, ne pourrait-on pas imaginer une sorte de MoonSession (telle que je l'imagine) sur un rectangle de texte illimité, et permanente ? avec éventuellement plusieurs étages de texte (ou levels, comme dans les jeux d'aventure sur ordinateur) ? Au final, quel différence y aurait-il entre cela et un wiki classique, à ceci près que cela serait "géographisé" dans une sorte d'espace mental palpable, et que ce serait de l'interaction en temps beaucoup plus réel ? (ah oui, et ce serait plus fun, aussi...) -- esc

Bonjour,

Parmi les solutions actuelles face aux conflits de versions, je vois 3 grandes catégories :

la non-solution: l'utilisateur apprend au dernier moment que la sauvegarde de ses modifications est impossible parce qu'un autre utilisateur a édité et sauvegardé la page entre-temps. Il doit reprendre entièrement son travail en ré-éditant la "nouvelle" page.
la double version : l'utilisateur est avertit d'un conflit de version. Le wiki lui rappelle sa version et lui laisse le soin de la fusionner à la main avec la version plus récente, directement éditée.
la tentative de fusion : le wiki tente de fusionner les deux versions. Si les deux utilisateurs ont modifié des parties différentes du document, la fusion est faite de manière transparente et le résultat sauvegardé comme si de rien n'était. Sinon, l'utilisateur se retrouve dans la situation 2 ci-dessus. A noter: la notion de partie différente dans la page est très variable, et peut aller de la phrase à la section.

AMHA, il faudrait distinguer :

BP 1: les conflits d'édition ne doivent pas provoquer la perte des modifications apportées par un des utilisateurs. Celui-ci doit pouvoir au minimum poursuivre son travail sans avoir à tout recommencer (éviter la non-solution 1 ci-dessus)
BP 2 ou sans doute recommandation (potentielle) : en cas de conflit d'édition, le wiki différencie clairement les deux versions (champs distincts, codes de couleur, tableau...). PHP Wiki en V.O. est un bon exemple de ce qu'il ne faut pas faire ;)

-- Laurent Denis

Bonjour tous et merci de nous donner l'occasion de gérer un sujet non trivial et qui fait toute la force du wiki. A l'époque, je me souviens avoir fait l'expérience avec Arnaud lors d'une Wiki School où nous étions environs 7 ou 8. Nous avions demandé à tous les élèves de modifier en même temps la page d'accueil du Autrans Wiki pour les inviter à vivre le conflit.

Je pense que nous pourrions recommencer ce type d'expérience pour la production de screenshots et assortir cette page de Langage Visuel.

En outre, nous avions fait l'expérience sur Crao Wiki qu'on pouvait travailler simultanément à deux sur une même page. Si un contributeur travaille en haut de la page et un autre en bas de la page, le système ne déclare pas de conflit de versions.

Je pense que nous devrions passer tous les systèmes wiki au torture-test du conflit d'édition.

Les photos d'écran pourraient aider le lecteur à se faire une opinion avant de rédiger une bonne pratique.

Pour finir, il existe quelques ressources riches et barbantes à regarder et remanier sur la page frère MeatBall:ConflitEdition pour construire cette page.

Qui serait prêt à faire un ting dédié sur les tortures-tests de pages bac à sable de la Terre Wiki pour la production de Screen Cast ?

Parce qu'à deux le problème est simple...

Mais si nous sommes disons 5 ou 6, le problème des marqueurs de conflit d'édtion dans une MeatBall:FusionAutomatique est moins trivial.

En plus ce pourrait être amusant d'imaginer un scénario qu'on pourrait écrire à plusieurs sur le Wiki Ting ?

Laurent et Elie. Je pense en outre que certaines de vos bonnes pratiques mériteraient d'être illustrées et sonorisées pour être mieux comprises. Mais c'est un autre débat Hors Sujet sur cette page ...

-- Christophe Ducamp

Bonjour tous,

vous oubliez une quatrième solution pour éviter les conflits d'édition : on donne une bombe atomique à chacun ;-)

Plus sérieusement, si le wiki était une MoonSession ouverte en permanence, je verrais les modifications de texte d'autrui en temps réel... comme une sorte d'effervescence du texte façon dessin animé... Il n'y aurait donc pas de conflit d'édition possible (il est vrai qu'au début ça choquerait un peu... mais le wiki, quand nous l'avons découvert, ne nous a-t-il pas choqué ?) -- esc

Et on pourrait prendre un "snapshot" de la page à tout moment ? Mais est-ce qu'on ne flirt pas un peu avec le Wiki Du Futur là ? Où est la frontière ? -- Sébastien Sauteur

Voir les modifications de texte d'autrui en temps réel ? Nous pourrions tenter quelque-chose de très approchant via XMLHTTPRequest, non ? (désolé pour le gros mot)

-- Laurent Denis

Solutions annexes et peut-être complètement débiles, à vous de juger

Module de chat ou affichage de messages en direct concernant les éditions en cours
Utilisation de fils RSS pour transmettre également les éditions en cours. Concernant le RSS, je dis ça comme ça, sans idée précise ou préconçue, vu qu'à mon avis, ça peut-servir à tout :-D

Mais le vrai truc, c'est sans doute XMLHTTPRequest ou de l'AJAX. De l'AJAXWiki, en quelques sorte.

Je ne sais pas si ça existe.

-- Elie Sloïm

@xtof : "Je pense que nous devrions passer tous les systèmes wiki au torture-test du conflit d'édition." : et synthétiser les résultats sous la forme d'un tableau ici ? Définir des critères de test ? Les systèmes à tester ? L'idée ensuite de Wiki Ting dédiée(s) me semble aussi une bonne idée pour avancer là-dessus.

--Sébastien Sauteur

Héhé. Cette idée pourrait être produite disons début juillet 2005 pour présentation des résultats lors de la prochaine Wiki School Paris du 26 juillet.

Je pense que nous sommes désormais en mesure de nous attaquer à bon nombre de solutions. Tant les grands moteurs libres"" (Use Mod, Media Wiki, Php Wiki, Moin Moin, Odd Muse, Pm Wiki, Tiki Wiki, Wiki Ni, XWiki) que quelques moteurs commerciaux (Social Text, Jot Spot et Fractal Wiki) méritent une visite filmée. Réfléchissons à une mise en scène amusante et vidéogénique''.

Je verrais bien une belle attaque de gaulois venus de la terre du Crao Wikix. Il me semble que Le Public aime bien les combats de gladiateurs ? J'imaginerais bien pour ce Scénario Interactif :

que le tableau produit puisse s'intégrer dans une page du Guide Du Routard Vers La Terre Wiki ?
que tout le monde puisse assister et participer à cette attaque des bacs à sables ou des pages-tests.

Quant à l'organisation du projet, on peut s'organiser ici ou utiliser le Compte Public du Base Camp du Point Wiki qui roupille si on veut poser des dates-jalons et tester aussi la résistance de notre Base Camp à une intrusion massive ?

Il nous faut trouver un nom de code pour cette opération commando. Quant à la stratégie des moyens pour savoir quels talkies-walkies utiliser durant l'assaut, je crois que nous avons le choix. Nous pourrions même en utiliser plusieurs car ils ont tous leurs limites.

Bon peu de temps ces prochains jours. Mais tout prêt à suivre et tenter d'aider. Je veux bien m'occuper du système pour imaginer que chacun puisse repartir avec une "vidéo-souvenir" ?

Et si... on en parlait tous de vive voix au prochain Paris Carnet ? Je pense que ça pourrait amuser les blogueurs. Ainsi informés, voire formés aux tactiques de combat, ils pourraient même venir nous rejoindre pour nous épauler et découvrir la force de La Voie Du Wiki.

Au fait, inutile d'aller chercher JeanRichard pour le buzz

Sa page ici est orpheline...

source iGenerator

La MerDeSable est à nous.

-- Christophe Ducamp ===> Envahissons la terre-wiki

Si quelqu'un possède un serveur avec connexion Telnet, je peux lui bricoler ma version de ce que j'ai appelé plus haut MoonSession, et nous pourrions jouer avec (du moins, ceux qui ont Telnet)... -- esc

Dernière modification le lundi 27 juin 2005 15:54:17