Suivi — Proposition Revoir complètement le système de rédaction commun

#446 Posté par  . État de l’entrée : corrigée. Assigné à Bruno Michel.
Étiquettes :
0
29
avr.
2011

Je pense qu' il faudrait de complètement revoir de A à Z le système de rédaction. qui a tellement de bugs qu'ouvrir des suivis pour chacun d'eux semble démontrer qu'il faut revoir en profondeur ce système. Si nono s'en sent le courage et le temps. Il faudrait alors lui fournir des idées pour qu'il puisse juger de la meilleure manière de résoudre tous les problèmes liés à l'espace de rédaction.

Donc je propose ici quelques idées pour faire avancer le sujet :

  • Je pense que vraiment réutiliser le système de wiki avec un système de de diff-3-way-merge comme celui de git résoudrait tous les problèmes d'édition concurrente. Si un commit détecte un conflit, il propose de gérer ça par un 3-way-merge classic.

Cela permettrait d'éditer de manière concurrente différents paragraphes de manière transparente pour l'utilisateur. Le 3-way-merge ne se lancerait que si on modifie un même paragraphe qu'un autre utilisateur. Il n'y aurait plus besoin de gérer de lock (d'ailleurs, linus torvalds a tellement craché sur le système de lock de CVS qu'il en est venu à détester tous les systèmes de gestion de version centralisés ). Mais on peut faire du 3-way-merge même en centralisé. Le souci serait de trouver une bonne librairie en ruby qui permette d'afficher les conflits et de permettre de facilement régler les conflits en 3-way-merge de manière visuelle.

  • Sinon faire de l'édition collaborative de manière asynchrone en streaming comme sur google wave. celà demanderait d'utiliser de l'Ajax et que le serveur de DLFP supporte des techniques de long-polling ou bien des websockets... ça semble cependant vraiment être trop lourd à implémenter pour une seule personne.
  • # Bof

    Posté par  . Évalué à 4 (+0/-0).

    Je ne suis pas vraiment sûr que ce soit utile, je pense que simplement mettre un timeout de 30 minutes ou 1h pour les modifications suffirait largement. L'édition concurrente me semble inutile, si quelqu'un supprime le paragraphe, le déplace ou le reformule totalement, ça ne sert à rien qu'un autre corrige l'orthographe du paragraphe en même temps.

    « Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche

    • [^] # Re: Bof

      Posté par  . Évalué à 2 (+0/-0).

      Un 3-way-merge sera capable d'appliquer les changements sur le déplacement...
      Si je propose ça, c'est que le système de découpe en paragraphe est complètement buggé quand il y a des titres, et il y a des problèmes de lock non stop sur toutes les dépêches en rédaction. c'est vraiment pas top à l'heure actuelle. Mieux vaut un bon système utilisant une technique épprouvé qu'un système bancal qui provoque des bugs partout.

      • [^] # Re: Bof

        Posté par  . Évalué à 3 (+0/-0).

        Un 3-way-merge sera capable d'appliquer les changements sur le déplacement...

        Ça ne résoud pas la suppresion ou la reformulation. Ou même 2 personnes qui corrige l'orthographe en même temps, ça fait du travail inutile.

        et il y a des problèmes de lock non stop sur toutes les dépêches en rédaction

        Ça c'est parce les gens ferme la page sans cliquer sur ok, mais ça pourrait être résolu par un timeout. Et ça me semble beaucoup plus facile à mettre en place. Ce que tu propose me semble beaucoup trop gros et complexe pour le système ici.

        « Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche

    • [^] # Re: Bof

      Posté par  (site web personnel) . Évalué à 1 (+0/-0).

      Je suis de cet avis là aussi:

      • Correctement mettre en valeur le fait qu'on a posé un lock (un bandeau rouge?)
      • Éventuellement le désactiver si l'utilisateur quitte la page (avec un watchdog? un long polling vers le serveur?)
      • Lui rappeler au bout de 5, 10 ou 30 minutes qu'il a un lock et qu'il va bientôt expirer, et lui proposer de le "relocker" pour encore X minutes
      • [^] # Re: Bof

        Posté par  . Évalué à 3 (+0/-0).

        Correctement mettre en valeur le fait qu'on a posé un lock (un bandeau rouge?)

        Et mettre un bouton annuler à côté du bouton ok, mais ça fait déjà l'objet d'une autre demande.

        « Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche

  • # Pas de 3-way-merge

    Posté par  (site web personnel) . Évalué à 3 (+0/-0).

    Je pense que vraiment réutiliser le système de wiki avec un système de de diff-3-way-merge comme celui de git résoudrait tous les problèmes d'édition concurrente.

    Oulà, non. Le 3-way-merge sur du code avec des outils adaptés, ça se fait bien, mais pour du texte redigé et dans une interface web, c'est juste l'horreur à utiliser. Et en plus de ça, c'est vraiment chiant à implémenter. Donc, si je dois refaire l'espace de rédaction, ça n'utilisera pas le 3-way-merge pour la résolution de conflit.

  • # Nouvelle version

    Posté par  (site web personnel) . Évalué à 2 (+0/-0).

    Une nouvelle version de l'espace de rédaction a été mise en place. Je pense qu'elle répond aux besoins exprimés dans cette entrée de suivi.

Envoyer un commentaire

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.