Todo

Écrire rapidement des listes de choses à faire, sans se prendre la tête.

Ce plugin est une extension de Textwheel, il ajoute de nouveaux raccourcis typographiques permettant de générer rapidement une liste de choses à faire proprement présentée, et triable.

Il ne s’agit pas d’une fonctionnalité mais juste de la présentation.

Installation

La branche v1 du plugin est compatible SPIP 2.1 et nécessite Textwheel ainsi que Bonux. Les nouvelles branche v2 et ultérieures ne nécessitent plus que Textwheel distribué par défaut avec SPIP.

Les branches v2 et ultérieures apportent de nouvelles fonctions au plugin mais assure une compatibilité ascendante parfaite avec la branche v1.

Utilisation de base

Une liste commence par une suite de trois +++ suivie d’un retour à la ligne, et se termine de la même façon ; ou bien elle est incluse entre les marqueurs <todo></todo>. Cette deuxième solution se dégrade mieux lorsque le plugin n’est plus là : les balises deviennent invisibles et il ne reste que la liste à l’intérieur.

Ensuite, c’est le premier caractère qui détermine le statut de la tâche qui se limite pour la branche v1 à :

  • + indique quelque chose à faire ;
  • o (lettre o minuscule) signifie une tâche en cours ;
  • - indique une chose faite.

Pour les branches v2 et ultérieures, les nouveaux statuts ci-dessous ont été rajoutés :

  • x (lettre x minuscule) indique une tâche abandonnée ;
  • = signifie une tâche arrêtée temporairement ;
  • ! indique qu’une action est nécessaire pour débloquer cette tâche ;
  • ? indique qu’on ne connait pas le statut exact de cette tâche.

Utilisation avancée avec les branches v2 et ultérieures

A partir de la branche v2 le plugin se dote des améliorations suivantes :

  • qualification des tâches avec une priorité, des catégories et des informations typées ;
  • regroupement de tâches par projet ;
  • précision du titre d’une tâche avec un descriptif libre.

Toute ces informations complémentaires s’écrivent à la suite du titre de la tâche séparées par un espace.

Priorité

Toute tâche peut être affectée d’une priorité écrite @n ou #n où n est un chiffre compris entre 1 et 9.

Catégories

Toute information écrite @tag ou #tag est considérée comme une catégorie à partir du moment où « tag » est une chaine alphanumérique.

Attention : le choix @ ou # est fait une fois pour toute pour le site au travers d’une constante qui vaut @ par défaut. Vous pouvez la modifier dans votre config/mes_options.php.

Pour chaque tâche la liste des étiquettes est collectée et affichée précédée d’un petit caractère habituel pour les tags. Si un tag correspond au titre d’un mot-clé SPIP, alors il est affiché comme un lien vers la page mot-clé associée.

Informations complémentaires typées

Les informations typées sont écrites avec la syntaxe type:valeur où type et valeur sont des mots pouvant contenir des caractères alphanumériques y compris « - », « . » et « _ ». Les types d’information sont extensibles mais le plugin ToDo propose déjà 4 types prédéfinis :

  • « debut » : pour la date de début de la tâche sous la forme 2012-06-02 ;
  • « fin » : pour la date de fin de la tâche sous la forme 2012-06-09 ;
  • « commit » : pour un numéro de commit générant un lien vers son dépôt et pouvant s’écrire,
    • z72463 pour la zone en SVN,
    • c12922 pour le core en SVN,
  • « version » : un numéro de version.

A partir de la v3, la forge git de SPIP est prise en compte dans l’information « commit » et dans une nouvelle information nommée « issue ». Pour chacune des ces informations le format est g:orga:repo:ref, où :

  • g indique la forge git de SPIP,
  • orga est un identifiant abrégé d’un caractère pour l’organisation soit
    • x pour spip-contrib-extensions,
    • s pour spip-contrib-squelettes,
    • t pour spip-contrib-themes,
    • o pour spip-contrib-outils,
    • g pour spip-galaxie,
  • repo, le nom du dépôt
  • et ref est soit le sha complet du commit, soit le numéro du ticket.

Il est possible d’insérer plusieurs informations de commit pour la même tâche. Celles-ci seront affichées comme une liste de révision séparées par une virgule.

Projets

Un projet est détecté par le caractère « :» en début de ligne. Tout le reste de la ligne constitue le nom du projet. Les tâches d’un projet sont regroupées dans un même bloc de visualisation et numérotée de 1 à n.

Descriptif complémentaire libre

Toute ligne ne commençant pas par un caractère signifiant (statut ou projet) est donc un descriptif libre. Chaque ligne du descriptif est affichée à la suite du libellé de la tâche.

Intégration au Porte-plume

La branche v2 pour SPIP 3 permet aussi d’utiliser la barre d’édition du Porte-plume pour ajouter une tâche ou en changer le statut. Un bloc spécial d’édition est dédié aux todos et propose un bouton par statut.

Evolutions

  • version 3.0.2 : compatibilité spip 4 et ajout de la prise en compte de la forge git de spip pour les commits et les tickets
  • version 2.2.0 : changement de la stratégie et du prototype des fonctions de formatage des informations typées
  • version 2.0.7 : ajout de la possibilité de lier le tag à un mot-clé SPIP
  • version 2.1.0 : ajout du # comme indicateur de priorité ou d’étiquette en plus du @ qui reste la valeur par défaut.
  • version 2.1.1 : ajout d’une classe « fermee » à la todolist si celle-ci ne contient que des tâches dans un état final.
  • version 2.1.2 : ajout d’un attribut format optionnel à la balise <todo> qui permet d’utiliser le squelette inclure/todo_$format.html pour afficher la todo.
  • version 2.1.3 : ajout d’une ancre au début de chaque todo d’une page.
  • version 2.1.4 : amélioration de la regexp pour éviter l’incompatibilité avec le raccourci page ou onglet du CS.

Exemple pour la branche v1

+++
- Ça c'est déjà fait
+ Une chose
+ Deux ou trois choses
o Suis en train de le faire
- Well done
+++

ou bien

<todo>
- Ça c'est déjà fait
+ Une chose
+ Deux ou trois choses
o Suis en train de le faire
- Well done
</todo>

Ce qui génère automatiquement ceci, avec les titres de colonnes permettant de trier par statut, par titre, ou de remettre dans l’ordre :

Exemple pour la branche v2

<todo>
:Projet 1
- Refaire fonctionner l'aide en ligne des plugins fin:2013-05-26 commit:z72345 @1 @aide @sad
o Utiliser Tickets pour remonter les problème du site, les actions à réaliser voire les erreurs sur la présentation des plugins @2 @sad commit:z70345 
- Ajouter un menu des langues disponibles fin:2013-05-26 commit:c12345 @1 @traduction
+ Vérifier la gestion correcte des langues dans les pages @1 @traduction
+ Vérifier les traductions @1 @traduction
On parle ici des traductions du plugin Plugins SPIP et du Upload de SPIP !
x Mettre en place la gestion des tags en plus des catégories (plugin étiquettes ?) fin:2013-05-28
= Revoir la présentation du formulaire de sélection des plugins en vedette ou supprimer cette fonction

:Projet 2
! Etendre le serveur d'aide et le promouvoir @2 @aide @sad
? Ajouter une fonction d'agrégateur de profil utilisateur pour compléter l'aspect développement @3
</todo>

Ce qui génère automatiquement ceci, avec en particulier la colonne Révision qui possède des liens vers la Zone ou le Core :

Discussion

14 discussions

  • 7

    Hello,

    pourquoi ne pas se passer des +++ et utiliser des raccourcis qui se dégraderaient même sans le plugin ? Exemple :

    -* DONE Ça c'est déjà fait
    -* TODO Une chose
    -* TODO Deux ou trois choses
    -* DOING Suis en train de le faire
    -* DONE Well done

    ce qui donne à l’état brut :

    • DONE Ça c’est déjà fait
    • TODO Une chose
    • TODO Deux ou trois choses
    • DOING Suis en train de le faire
    • DONE Well done

    Le plugin pourrait accepter le tiret simple aussi (-) et un éventuel deux-points (:) après le TODO/DOING/DONE.

    Avantages : aucun raccourci nouveau à se rappeler, et se dégrade naturellement.

    • Comme discuté avec Denis l’autre jour, c’était volontaire de ne pas utiliser le type de liste de SPIP, pour ne pas dépendre de ça justement, et donc toujours être valable même si on passe à markdown par exemple.

      Explication :
      Le +++ c’était pour être sûr de différencier le tiret simple de celui d’une liste classique. Le + pour un truc à faire et le - pour un truc terminé, je l’avais déjà rencontré plusieurs fois avant (mais je ne sais plus où) et ensuite on l’a utilisé en interne dans ma boite dans les todo.txt qu’on a parfois.
      Pour le o là c’est moi qui est inventé, pour trouver un caractère facile à faire sur les claviers classiques et qui soit circulaire (la métaphore « truc en train de tourner = tâche en train de se faire » étant assez commune).

      Pour ta proposition, je ne trouve pas intéressant d’utiliser des mots, qui plus est anglais mais peu importe la langue. Le principe d’un raccourci typo c’est d’être relativement neutre du point de vue de la langue, mais aussi d’utiliser le moins de caractères possibles pour que ce soit rapide à écrire. Là « mot entier + en anglais + en majuscule » c’est beaucoup plus lent et ça fait assez « geek développeur » alors que je ne pense pas que les listes de tâches dans un contenu soient réservées aux développeurs.

      Je suis évidemment très intéressé pour trouver quelque chose de portable, mais 1) sans le relier spécialement à ce qui existe dans SPIP et 2) en raccourci typo avec des caractères faciles à faire.

      Il faudrait chercher s’il y a déjà des expériences d’écriture de todolist en format texte brut. Ainsi que demander à des gens, pas forcément développeur, comment ils auraient envie de l’écrire le plus simplement pour eux.

      J’ai trouvé ça : http://todotxt.com/
      Qui utilise ce format : https://github.com/ginatrapani/todo.txt-cli/wiki/The-Todo.txt-Format

      Mais vu qu’il n’y a pas un truc constant en début de ligne, il faut donc forcément entourer l’ensemble d’un repère pour le dissocier du reste (d’où le +++).

    • Un mini-outil pour générer une liste de tâche à partir de Markdown + JS. En fait il ajoute un type de raccourci à Markdown qui est traité par son JS à lui :

      https://github.com/claes/lessmess#how-to-write-markdown-for-lessmess

    • Pour mon espérience personnelle je note sur un carnet, à raison d’une liste par page (ou feuille —recto-rerso— si la liste est importante) et en précédant chaque tâche par un simple tiret et non un plus (c’est une vraie/simple liste quoi). Quand la tâche est terminée on la barre...
      Les tâches peuvent être décomposée en sous-tâches donnant lieu à des sous-listes imbriquées par indentation... S’il y a une date buttoire est est enregistrée entre parenthèses juste après l’espace du tiret ; et quand je dois garder trace de la date d’achèvement elle est mentionnée en dernier après le texte barré
      Quand les tâches sont hiérarchisées, les tirets sont remplacées par des numéros d’ordre (nombre point espace), donnant l’allure d’une table des matières à la liste.
      Au passage, je fais remarquer la décomposition d’une tâche en sous-tâches résoud le problème de marquage de « tâche en cours » : tant que toutes les sous-tâches ne sont pas terminées (donc barrées) c’est que la tâche est en cours.
      Enfin, les tâches étaient triées par priorité/importance (les choses les plus importantes apparaissent en tête de liste et les moins importantes viennent à la fin), ce qui m’amenait parfois à reprendre une liste.

      Je viens de retrouver deux belles présentations de ToDo.txt sur LifeHacker : http://lifehacker.com/5743081/why-i... et http://lifehacker.com/5859642/why-y... Et effectivement, quand je dois noter une liste informatiquement (et non sur papier donc) j’utilise du texte brut car je suis alors amené à consulter et modifier ces listes sur/dans divers supports/conditions : un autre ordinateur (raison pour laquelle il faut un document qu’on puisse ouvrir avec un éditeur de texte), ma calculatrice à une époque, puis PDA (mais je dois avouer que depuis quelques années la belle interface de PalmOs et le fait de répondre à tous mes besoins m’a peu à peu détourné de l’idéal texte jusqu’à ce que je me retrouve à faire des exports/conversions en tous sens en plus de juste synchroniser mon remplaçant papier avec l’ordi... maintenant je suis prévenu)
      Pour en revenir à ma notation informatique d’avant ToDo.txt, les tâches à faire étaient sur une ligne qui commence par un tiret (suivi d’un espace et de la date limite entre parenthèse) et ordonnées par priorité. Les tâches achevées ne sont pas marquées d’un symbole particulier qui remplacerait le tiret, mais les lignes en question sont purement et simplement supprimées pour garder une liste claire (avec juste l’essentiel et plus de texte barré qui au demeurant est difficile à faire et m’évite quelque marquage superflu)... En fait, je tiens souvent deux fichiers parallèles : la « ToDo-list » en elle-même et la « Done-list » qui n’est que le journal (« .log ») des tâches/lignes supprimées de l’autre au fur et à mesure.
      Perverti par SPIP, mes tirets ont rapidement été suivi de l’astérisque ; et plutôt que d’utiliser la tabulation (indentation) pour les sous-tâches j’augmentais le nombre d’étoiles/astérisques. Quand les tâches doivent être séquencées, les étoiles sont remplacées par des numéros d’ordre (suivi du point) ; et il va de soit que quand la dite liste doit être publiée dans SPIP, ces nombres deviennent juste des dièses ! De même, quand la liste doit être partagée via SPIP, je laisse les tâches achevées mais les encadre de <s> et </s> (les vieilles habitudes héhé.)
      Voilà pour mon expérience (et pour répondre à la question de savoir quelles autres conventions sont utilisées par ailleurs)

      L’article n’oublie pas de signaler l’existence de :

      • TaskPaper (pour MacOs X et iPhone)/TodoPaper (pour Windows), programmes propriétaires que j’ai pas trop regardé (de toute façon je n’ai pas les plate-formes prérequises pour démarrer)
      • Org-Mode (avec Emacs) qui est en fait pour prendre des notes avec la possibilité d’y insérer des listes de « choses-à-faire » ; chaque chose à faire étant étant un « titre » débutant par TODO comme le suggère Cédric, et les tâches achevées étant pareillement marquées DONE...
        Les tâches peuvent être prioritisées par [#A] ou [#B] ou [#C] juste après la mention TODO. Mais on ne gère pas de « deadline »...
        De plus, les tâches étant saisies comme des titres (lignes commençant par une ou plusieurs étoiles), elles sont donc imbriquées sur plusieurs niveaux... (le même effet serait obtenu avec les listes à la SPIP comme le suggérait Cédric) C’est assez pratique pour décomposer les tâches en étapes et avoir une sorte de mini-projet ; et dans cet esprit Org-Mode enregistre la date d’achèvement afin de représenter l’évolution du projet dans un calendrier....
      • ToDo.txt est un script shell-Unix pour manipuler une liste écrite suivant un formalisme simple (pour moi car proche de ma pratique) et assez complet (ça prend en compte les priorités et les dates d’achèvement) et pourtant un peu lâche (comparé à l’usage d’un format délimité necessitant tous les champs —ce qui serait pratique pour récupérer dans un tableur ou une table d’une base de donnée) mais est extensible en modifiant le script (on peut rajouter des mots-clés pour prendre en compte les échéances, la dépendance à l’achèvement d’une autre tâche, tout comme on gère déjà les catégories et les projets avec les signes @ et +, de quoi rivaliser simplement avec les « task-manager »s graphiques ou pas)
        Ici il y a une tâche à faire par ligne, et les tâches achevées commencent par x (équivalent du tiret actuellement dans ce plugin). Pour chaque tâche on peut commencer par indiquer sa priorité par (A) ou (B) ou (C) puis/ou sa date de début. La date de début passée (pour une tâche non achevée) peut donc être considéré comme un indicateur de tâche en cours (équivalent du o dans ce plugin).
        Bon, il n’y a pas gestion de sous-tâches... Mais je me ratttrape encore avec la notation -*/-**/... Sinon, autre point intéressant : ce genre de fichiers (à la David Allen) peut être exploité de plein de manières (en dehors du script)
    • Ouep j’ai déjà lu tous ces liens dans ma précédente recherche, merci quand même.

      Le truc avec Emacs et TODO c’est typiquement un truc de développeur, donc ce que je voudrais éviter (d’ailleurs qui utilise Emacs à part les gros devs geeks ET barbus ?).

      Les syntaxes simples ne peuvent convenir en elles-mêmes puisqu’il faut pouvoir les distinguer des listes normales, que ce soit celles de SPIP ou de Markdown ou autre. Voilà pourquoi il faut obligatoirement soit un signe distinctif (les crochets imitant une case à cocher sont pas mal) soit entourer la liste de quelque chose (là c’est +++ pour l’instant, mais ça peut être des balises ou autre). Cédric proposait d’entourer plus simplement de <todo></todo> comme ça si le plugin est enlevé, au moins ces signes disparaissent à l’affichage. C’est sûrement le plus propre.

      Quant au besoin final, là il ne s’agit pas de gérer des tâches ! En tout cas pas complexes. Pour ça il y a des logiciels de tickets qui existent, y compris en plugin SPIP déjà.

      Là il s’agit surtout de communication : c’est pour afficher rapidement à un public des listes de tâches dans un contenu SPIP. Ça peut être pour lister les choses qui manquent dans un plugin sur Contrib, ou dans un site en construction pour lister au client ce qui reste à faire et ce qu’on est en train de faire mais en contexte (pas dans un système de tickets séparé), ou encore pour lister des idées de devs qui nous trottent dans la tête sur notre page perso, etc.

    • C’est vrai que c’est très dév Emacs, les TODO FIXME et autre (quoique parfois on peut avoir des surprises : j’ai déjà rencontré des non-développeurs qui utilisent RCS/CVS/SVN par exemple mais ce sont des atypiques « anglophones »)
      Quand aux tickets c’est plus pour la comm’ en complément du planning de gestion de projet informatique (j’en ai pas encore vu l’usage en dehors de ce domaine par contre)

      Le problème des listes de choses à faire est qu’il a plusieurs besoins (que ce soit en mode texte ou avec une lourde interface) :
      ceux qui veulent juste faire une/un liste/pense-bête (le seul hic comme tu le soulignes est de le différencier des autres listes, et là du raccourci +++ ... +++ au tag maison <todo> ... </todo> on peut imaginer plein de solutions) ou une « whish list » (à part le nom qui indique que c’est une liste de désidératas il n’y a pas grande différence ...ou l’intégration avec le/la site/boutique d’une façon ou d’une autre) ou une « wedding list » etc.
      ceux qui veulent gérer les priorités (l’importance et ou l’urgence) et éventuellement la date liée
      ceux qui veulent faire une seule grande liste composée de plusieurs liées par des étiquettes (catégories et/ou projet etc.)

      L’idée d’un « tag » todo me semble être un meilleur point de départ pour laisser plus de liberté dans le formalisme tout en mettant en exergue ce bloc (comme les cadres ou le code). Je plusois

    • Hop, je viens de tester ce plugin et c’est bien pratique, simple et efficace.

      Juste une remarque sur les raccourcis utilisés : je pense qu’il est plus facile/naturel de rédiger une liste à base de - et non de +. Et comme dans todo.txt je trouve plus logique d’indiquer une tâche terminée avec un x.

      On pourrait peut être ajouter cette possibilité au plugin vu qu’elle n’entre pas en conflit avec la syntaxe existante (au moins pour le x).

      ++

    Répondre à ce message

  • Bonjour,

    Sous SPIP 2.1.19 [19922], Sarka-SPIP 3.0.4 [40664] je voulais utiliser le plugin Todo qui fait appel à TextWheel

    mais ...

    ... le plugin TextWheel 0.8.6 - stable annule les redirections d’articles.

    Pouvez-vous corriger SVP

    Bien cordialement

    FDG

    Répondre à ce message

  • Le plugin qui manquait pour gérer les milliers de petits trucs à faire quotidiens ! Vraiment cool.

    Ah ! et si on pouvait aussi utiliser cette manière d’écrire les todo dans les squelettes en cours de fabrication...

    Merci pour cettte contrib !

    ++
    Cyril

    Répondre à ce message

  • Excellent de simplicité !

    Répondre à ce message

Ajouter un commentaire

Avant de faire part d’un problème sur un plugin X, merci de lire ce qui suit :

  • Désactiver tous les plugins que vous ne voulez pas tester afin de vous assurer que le bug vient bien du plugin X. Cela vous évitera d’écrire sur le forum d’une contribution qui n’est finalement pas en cause.
  • Cherchez et notez les numéros de version de tout ce qui est en place au moment du test :
    • version de SPIP, en bas de la partie privée
    • version du plugin testé et des éventuels plugins nécessités
    • version de PHP (exec=info en partie privée)
    • version de MySQL / SQLite
  • Si votre problème concerne la partie publique de votre site, donnez une URL où le bug est visible, pour que les gens puissent voir par eux-mêmes.
  • En cas de page blanche, merci d’activer l’affichage des erreurs, et d’indiquer ensuite l’erreur qui apparaît.

Merci d’avance pour les personnes qui vous aideront !

Par ailleurs, n’oubliez pas que les contributeurs et contributrices ont une vie en dehors de SPIP.

Qui êtes-vous ?
[Se connecter]

Pour afficher votre trombine avec votre message, enregistrez-la d’abord sur gravatar.com (gratuit et indolore) et n’oubliez pas d’indiquer votre adresse e-mail ici.

Ajoutez votre commentaire ici

Ce champ accepte les raccourcis SPIP {{gras}} {italique} -*liste [texte->url] <quote> <code> et le code HTML <q> <del> <ins>. Pour créer des paragraphes, laissez simplement des lignes vides.

Ajouter un document

Suivre les commentaires : RSS 2.0 | Atom