Journal Tracim - développement d'une fonctionnalité "journal de bord" - envie de tester ?

Posté par LeBouquetin (site web personnel, Mastodon) le 23 février 2024 à 16:37. Licence CC By‑SA.

Étiquettes :

fév.

2024

Bonjour,

Dans notre logiciel collaboratif Tracim nous sommes en train d'implémenter une fonctionnalité de journal de bord.

Le but de cette fonctionnalité est de permettre de tenir un journal de bord pour un projet, le suivi d'une expérimentation, d'une opération terrain, etc.

Exemple d'extrait de journal :

13/08/2023 - CR Réunion
- JR nous envoie les specs du matériel mobile
- MEP prévue : semaine du 11/09 au 14/09
- Devises: pb de stockage en DB - à clarifier

08/09/2023 - Visio
- ML va vérifier les vues en DB
- Envoyer le screen au dév mobile
- Mise à jour backend ok.
- Tests manuels à faire

11/09/2023 - Mise en prod ?
- ...
- ...

Si vous ne voyez pas de quoi il s'agit, l'idée c'est de gérer un contenu dans tracim qui aurait un rendu un peu similaire à ceci : https://jsfiddle.net/8jbuw2kt/4/

Les informations qu'on prévoit d'intégrer dans notre journal :
- titre
- description (texte riche)
- date et heure
- champ libre textuel
- couleur de la carte

Je suis à la recherche de personnes qui seraient intéressées pour tester la version de développement et me faire des retours sur cette fonctionnalité en particulier.

Les personnes que je recherche ne sont pas nécessairement utilisatrices de Tracim mais des personnes qui tiennent d'une manière ou d'une autre des journaux de bord dans le cadre de d'une activité régulière (professionnelle, associative)

J'avais notamment eu l'occasion d'échanger sur ce sujet il y a quelques années lors de la publication de la version 2.5 de tracim

Y-a-t-il des intéressé(e)s ? On peut aussi juste échanger ici en commentaire.

# L

Posté par raphj le 23 février 2024 à 22:26. Évalué à 10. Dernière modification le 23 février 2024 à 22:28.
Je vis pas mal dans le terminal et je suis brouillon. J'ai parfois besoin de noter un truc en vitesse sans friction pour être sûr de ne pas le perdre, pour finalement souvent ne jamais y retourner, mais au moins c'est consigné xD

Du coup, j'ai un petit script écrit en plus ou moins une fois (vous savez, ces hacks qui deviennent définitifs ?) que j'utilise depuis des années (y compris quand j'étais à Algoo :-)).

Son utilisation est simple : dans le terminal, je tape L, puis ce que je veux noter.
```
L une note
```
Ça ajoute une entrée dans un fichier texte synchronisé avec Nextcloud, avec la date.

On peut consulter le journal en tapant L. Ça ouvre le fichier avec less (ou autre outil configurable), et comme les notes les plus récentes sont en haut du journal, c'est plutôt pratique.

Une entrée :
```
Fri, 23 Feb 2024 22:09:36 +0100:

        Une note
```
Et on peut appeler l'éditeur de texte de son choix sur le journal avec L e.

L'aide de l'outil :
```
Usage:
    L           - show the content of the journal
    L message   - add message to the journal, with a date
    L + message - add message to the previous entry in the journal
    L -         - add stdin to the journal
    L + -       - add stdin to the journal, without a date
    L e         - edit the journal manually
    L h, L -h  - show this help

Config file is in /home/raph/.config/Ljournalrc
```
Ça supporte les étiquettes de la manière la plus débile possible : il suffit d'ajouter "l'étiquette" à la ligne de cette manière : [tag], et une recherche dans le fichier la retrouvera.

Je l'ai mis en ligne pour l'occasion : https://git.jakse.fr/raph/L/src/branch/main/L

Bien sûr, personne ne l'utilisera, parce que chacun a sa manière de prendre ses petites notes, voire de réinventer son outil. Sinon il y a les gens organisés qui écrivent des notes markdown et qui parfois même font des liens entre les notes. Moi, ça m'explose le cerveau xD.

J'ai abandonné l'idée d'utiliser un outil plus complexe que L depuis longtemps. Il faut que l'outil soit discret et immédiat (aucun lag possible, ça peut tuer une pensée. Ça a tendance à marcher sur les smartphones que je peux utiliser aussi (avec Termux sous Android, ou de manière native sur un mobile Linux). C'est extrêmement user-friendly… pour moi. Finalement, ça fait le taf et c'est rentré dans mes habitudes. Je pourrais améliorer ça un peu et respecter un peu la syntaxe Markdown maintenant que Nextcloud prend ça en charge nativement.

Et sinon, pour les gens qui utilisent un shell avec une gestion sensée de l'historique (comme zsh), un petit # avec la note dans la suite marche aussi. C'est un commentaire en shell et ça reste dans l'historique, et ça ne nécessite aucune installation. Mais gare aux historiques corrompus, ça a pu m'arriver de temps en temps.

En tout cas j'espère que vous aurez du succès avec cette nouvelle fonctionnalité de Tracim :-) C'est une bonne idée, et c'est plutôt malin.
- [^] # Re: L
  
  Posté par Gil Cot ✔ (site web personnel, Mastodon) le 23 février 2024 à 23:59. Évalué à 2.
  
  Je l'ai mis en ligne pour l'occasion
  
  Je crois que le dépôt n’est pas public (tu peux tester avec une fenêtre de navigation privée)
  
  “It is seldom that liberty of any kind is lost all at once.” ― David Hume
  - [^] # Re: L
    
    Posté par raphj le 24 février 2024 à 07:04. Évalué à 2.
    
    Oups, corrigé, merci :-)
    - [^] # Re: L
      
      Posté par Gil Cot ✔ (site web personnel, Mastodon) le 24 février 2024 à 09:24. Évalué à 7. Dernière modification le 24 février 2024 à 09:24.
      Merci tout plein :) J’en profite pour soumettre mon premier patch : which peut ne pas être présent sur certaines bécane (ce n’est pas requis par POSIX qui par contre demande que la fonctionnalité de base soit rendue par command -v interne au shell) comme MacOS…
      
      - if [ -f "$(which nano)" ]; then + if command -v nano >/dev/null; then EDITOR=nano - elif [ -f "$(which vim)" ]; then + elif command -v vim >/dev/null; then EDITOR=vim - elif [ -f "$(which emacs)" ]; then + elif command -v emacs >/dev/null; then EDITOR=emacs fi
      
      En vrai, ce genre de truc je le fais plutôt ainsi (plus facile à étendre) :
      
      if [ -z "$EDITOR" ]; then for prog in 'nano' 'jed' 'jove' 'vim' 'nvim' 'emacs' ; do if command -v $prog >/dev/null; then EDITOR=$prog break fi done fi exec "$EDITOR" "${JOURNAL_FILE}"
      
      “It is seldom that liberty of any kind is lost all at once.” ― David Hume
      - [^] # Re: L
        
        Posté par raphj le 24 février 2024 à 13:59. Évalué à 4.
        
        C'est une bonne amélioration, surtout la dernière version. Ça simplifie le code mais ça fait mieux :-)
        
        Je peux faire un commit avec le bon auteur si tu me donnes le nom et l'email à utiliser.
        
        [^] # Re: L
        
        Posté par Gil Cot ✔ (site web personnel, Mastodon) le 25 février 2024 à 18:43. Évalué à 3.
        
        Merci :)
        
        Pour le nom/pseudo c’est “Gil Cot”/“gilcot”
        Pour le mail, tu peux en utiliser un générique (genre contrib-ext@jakse.fr par exemple ?) …et jouter le lien vers cette discussion.
        
        Je profite pour amender la ligne 25 ainsi
        
        - CONFIG_FILE="${HOME}/.config/Ljournalrc"; + CONFIG_FILE="${$XDG_CONFIG_HOME:-$HOME/.config}/Ljournalrc";
        
        (mais pourquoi avoir choisi Ljournalrc au lieu de Lrc ? en tout cas c’est à ce dernier que je me serais attendu…)
        
        “It is seldom that liberty of any kind is lost all at once.” ― David Hume
        
        [^] # Re: L
        
        Posté par raphj le 26 février 2024 à 08:58. Évalué à 4.
        
        Merci, c'est commité ! J'ai retiré le dollar en trop, et tant qu'à faire le point virgule que j'avais laissé là pour aucune raison valable. J'ajoute cette substitution dans ma boite à outils shell pour le futur. Je ne pensais pas avoir une contribution aussi vite après une annonce caché dans un commentaire sur un script sans grande importance xD.
        
        Pourquoi avoir nommé le fichier de configuration Ljournalrc plutôt que Lrc ? Je ne me souviens plus, mais je vois trois raisons qui me pousseraient à reprendre la même décision aujourd'hui :
        
        Clarté : Lrc dans la listes des fichiers dans .config serait potentiellement cryptique. C'est beaucoup plus facile de percuter avec Ljournalrc.
        
        Éviter les clashs : si tout le monde appelle son petit script avec une lettre, ça va vite devenir la foire.
        
        Nom du « projet » : J'avais peut-être, pour ces deux raisons, pensé le nom du projet comme Ljournal plutôt que simplement L, mais opté pour L pour le nom du script. Aujourd'hui, j'appellerais peut-être plutôt le script Ljournal et suggérerais aux gens de mettre en place un lien ou un alias nommé L. Et c'est peut-être ce que je ferai si jamais un jour je m'embête à mettre en place un processus d'installation. Pour l'instant, cette responsabilité repose sur la personne qui va réutiliser mon code.
        
        [^] # Re: L
        
        Posté par Gil Cot ✔ (site web personnel, Mastodon) le 26 février 2024 à 11:45. Évalué à 3.
        
        Oups… me suis pas bien relu pour le dollar en trop.
        Merci pour avoir pris le temps d’éclairer mes interrogations ; c’est surtout que ça n’était pas clair (pour moi) que le projet s’appelle Ljournal.
        
        “It is seldom that liberty of any kind is lost all at once.” ― David Hume
        
        [^] # Re: L
        
        Posté par raphj le 26 février 2024 à 11:54. Évalué à 3.
        
        Pour moi non plus xD
        
        C'est juste un vieux script qui traine à la base.
        
        [^] # Re: L
        
        Posté par Gil Cot ✔ (site web personnel, Mastodon) le 29 février 2024 à 03:13. Évalué à 2.
        
        Désolé LeBouquetin< ; nous squattons ton annonce ;D Je voulais signaler un autre truc à raphj<
        Il y a un bloc qui pourrait avoir le même traitement que l’éditeur…
        
        else exec "${VIEWER}" -- "${JOURNAL_FILE}" fi
        
        Je m’explique : le visionneur de fichiers a déjà sa variable d’environnement POSIX nommée PAGER. C’est normalement défini (au moins quand il y a man et associés qui sont installés), et si ça ne l’est pas on est dans le même cas que EDITOR qui est vérifié… Or que se passe-t-il si la commande que tu mets par défaut dans le fichier de config n’existe pas ? (c’est de plus en plus rare mais j’ai croisé des bécanes sans less)
        
        else if [ -z "$PAGER" ]; then for prog in 'less' 'most' 'pg' 'more' 'lv' 'pager'; do if command -v $prog >/dev/null; then PAGER=$prog break fi done fi if [ -z "$PAGER" ]; then >&2 printf 'No pager found. Please set $PAGER.\n' exit 1 fi exec "${PAGER}" -- "${JOURNAL_FILE}" fi
        
        Avec cela on peut retirer la ligne du VIEWER de la configuration par défaut.
        Pour la configuration par défaut, mes postes persos sous Linux n’ont pas de sous-répertoire Documents …sauf le seul qui a un DE mais où j’ai plutôt Dokumentoj, Muziko, Filmetoj, etc. Du coup, j’arrive à quelque chose comme
        
        if [ ! -f "${CONFIG_FILE}" ]; then mkdir -p "$(dirname "$CONFIG_FILE")" JOURNAL_DIR="${HOME}/Documents" if [ ! -f "${JOURNAL_DIR}" ]; then JOURNAL_DIR="${HOME}" fi printf 'JOURNAL_FILE="${JOURNAL_DIR}/journal.txt"\n' >> "${CONFIG_FILE}" unset JOURNAL_DIR printf 'LESS='"'"'-~ -e +G'"'"'\n' >> "${CONFIG_FILE}" fi
        
        Voilà, c’est tout, je pense.
        
        “It is seldom that liberty of any kind is lost all at once.” ― David Hume
        
        [^] # Re: L
        
        Posté par LeBouquetin (site web personnel, Mastodon) le 29 février 2024 à 12:19. Évalué à 4.
        
        ah ah. J'ai remarqué ;) C'est pas un soucis :-D
        
        C'est le risque en publiant sur linuxfr, et c'est aussi l'avantage de cet espace : les échanges peuvent digresser et c'est ce qui en fait tout l'intérêt. (raphj n'aurait peut-être pas partagé son script sans mon journal, et manifestement ça intéresse donc c'est très bien comme ça)
        
        #tracim pour la collaboration d'équipe __ #galae pour la messagerie email __ dirigeant @ algoo
        
        [^] # Re: L
        
        Posté par Gil Cot ✔ (site web personnel, Mastodon) le 29 février 2024 à 14:45. Évalué à 4.
        
        Le pire que j’ai vu cette année, c’est sur l’annonce de seraf1 : c’est parti dans tous les sens (je pensais pas qu’il y avait encore de l’intérêt pour les scripts shell) :-D
        Au moins ce ne sont pas des centaines de commentaires sur le complotisme-anticomplotisme-etc.
        
        “It is seldom that liberty of any kind is lost all at once.” ― David Hume
        
        [^] # Re: L
        
        Posté par Thomas Douillard le 29 février 2024 à 13:32. Évalué à 3.
        
        Il y a également la possibilité d’utiliser la variable XDG_DOCUMENTS_DIR et les commandes xdg pour ce genre de choses, cf. https://wiki.archlinux.org/title/XDG_user_directories
        
        [^] # Re: L
        
        Posté par Gil Cot ✔ (site web personnel, Mastodon) le 29 février 2024 à 14:15. Évalué à 2.
        
        Ah bien vu ; je m’en doutais un peu mais suis pas parvenu à trouver cette liste.
        Du coup, la partie de la configuration se simplifie ainsi :
        
        if [ ! -f "${CONFIG_FILE}" ]; then mkdir -p "$(dirname -- "$CONFIG_FILE")" printf 'JOURNAL_FILE="${XDG_DOCUMENTS_DIR:-$HOME}/journal.txt"\n' >> "${CONFIG_FILE}" printf 'LESS='"'"'-~ -e +G'"'"'\n' >> "${CONFIG_FILE}" fi
        
        La commande xdg-user-dir n’est pas présente partout sinon on aurait pu écrire
        
        printf 'JOURNAL_FILE="$(xdg-user-dir DOCUMENTS )/journal.txt"\n' >> "${CONFIG_FILE}"
        
        Merci pour la découverte.
        
        “It is seldom that liberty of any kind is lost all at once.” ― David Hume
        
        [^] # Re: L
        
        Posté par raphj le 03 mars 2024 à 13:48. Évalué à 2.
        
        Merci, c'est commité !
        
        XDG_DOCUMENTS_DIR n'est pas définie chez moi donc j'ai ajouté un fallback sur ~/Documents quand même si le dossier existe.
        
        Tout ça fait de L un de mes projets avec la plus grande proportion de code contribué xD.
        
        [^] # Re: L
        
        Posté par Gil Cot ✔ (site web personnel, Mastodon) le 04 mars 2024 à 02:17. Évalué à 2.
        
        Justement, si XDG_DOCUMENTS_DIR était défini il vaudrait ~/Documents chez toi. Donc si tu tiens à avoir ce fallback il faudrait plutôt faire ainsi :
        
        if [ ! -f "${CONFIG_FILE}" ]; then mkdir -p "$(dirname -- "$CONFIG_FILE")" if [ -d "$HOME/Documents" ]; then printf 'JOURNAL_FILE="$HOME/Documents/journal.txt"\n' >> "${CONFIG_FILE}" else printf 'JOURNAL_FILE="${XDG_DOCUMENTS_DIR:-$HOME}/journal.txt"\n' >> "${CONFIG_FILE}" fi printf 'LESS='"'"'-~ -e +G'"'"'\n' >> "${CONFIG_FILE}" fi
        
        La forme {nom_de_variable:-valeur si variable non définie ou vide} est utilisée pour assigner HOME en fallback ;) (c’est la même technique qui a été utilisée pour XDG_CONFIG_HOME juste avant.)
        https://pubs.opengroup.org/onlinepubs/9699919799/utilities/V3_chap02.html#tag_18_06_02
        
        “It is seldom that liberty of any kind is lost all at once.” ― David Hume
        
        [^] # Re: L
        
        Posté par raphj le 04 mars 2024 à 07:30. Évalué à 2.
        
        Je vois comment cette construction fonctionne mais on est ici dans une partie du script qui écrit un chemin dans un fichier de configuration et ça a des implications spécifiques.
        
        Cette dernière version que tu proposes ne respecte pas XDG_DOCUMENTS_DIR si elle existe. Or, je pense qu'il faut la privilégier par rapport au chemin "plan B" hardcodé.
        
        Ensuite, je veux que le fichier journal ne bouge pas d'endroit si XDG_DOCUMENTS_DIR venait à devenir définie sur mon système.
        
        Cependant, je peux imaginer que quelqu'un déplacerait ses dossiers standard et trouver raisonnable que L suive automatiquement (par exemple si la session change de langue, ou que /etc/xdg/user-dirs.defaults est modifié - certains environnements proposent ce renommage automatiquement). C'est un cas qu'on ne peut raisonnablement prendre en charge que si XDG_DOCUMENTS_DIR est définie au moment de la création du fichier de config, sauf à faire de la magie dans le fichier de config et je ne suis pas très fan de ça.
        
        Sans ça, hardcoder le chemin du fichier journal dans le fichier de config serait mieux, le fichier journal n'est pas censé bouger et son emplacement ne devrait pas dépendre de l'existence d'une variable après première configuration idéalement (mais difficile de faire comme ça et permettre le renommage de ces dossiers standard).
        
        Et j'ai utilisé la syntaxe pour se rabattre sur HOME si XDG_DOCUMENTS_DIR venait à ne plus être définie mais en réalité ce n'est pas terrible. Il faudrait certainement éviter cette syntaxe dans le fichier de configuration. Il faudrait plutôt détecter que JOURNAL_FILE n'existe pas / plus et se plaindre. Et en même temps, je veux vraiment éviter de stocker des chemins qui sortent du HOME dans une config autogénérée dans la mesure du possible. Évidemment, si HOME n'est pas défini, all bets are off, mais aussi ça me parait terriblement peu probable.
        
        Voilà l'explication de mes choix. Ce n'est pas parfait parce que c'est le résultat de compromis subtiles.
        
        [^] # Re: L
        
        Posté par Gil Cot ✔ (site web personnel, Mastodon) le 04 mars 2024 à 11:55. Évalué à 2. Dernière modification le 04 mars 2024 à 11:57.
        
        (par exemple si la session change de langue, ou que /etc/xdg/user-dirs.defaults est modifié - certains environnements proposent ce renommage automatiquement)
        
        Ah… C’est donc pour cela que j’ai d’autres noms : c’est nommé d’après mon choix de langue d’interface (espéranto.)
        
        le fichier journal n'est pas censé bouger et son emplacement ne devrait pas dépendre de l'existence d'une variable après première configuration idéalement
        
        Normalement, si le fichier journal bouge, il faudra que l’utilisateur mette à jour manuellement le fichier de configuration. Le bloc en question (lignes 27 à 37) n’est appelé que pour la première configuration …et donc JOURNAL_FILE n’est plus modifié ;)
        
        Il faudrait plutôt détecter que JOURNAL_FILE n'existe pas / plus et se plaindre.
        
        Ça c’est un autre point qu’il faut adresser entre les lignes 62 et 63 (avant les utilisations de la variable, et après avoir lu la configuration) par quelque chose comme :
        
        if [ ! -f "${JOURNAL_FILE}" ]; then >&2 printf 'Cannot found %s.\n' "${JOURNAL_FILE}" >&2 printf 'Please correct JOURNAL_FILE= in %s.\n' "${CONFIG_FILE}" exit 1 fi
        
        “It is seldom that liberty of any kind is lost all at once.” ― David Hume
        
        [^] # Re: L
        
        Posté par raphj le 04 mars 2024 à 15:15. Évalué à 3.
        
        le fichier journal n'est pas censé bouger et son emplacement ne devrait pas dépendre de l'existence d'une variable après première configuration idéalement
        
        Normalement, si le fichier journal bouge, il faudra que l’utilisateur mette à jour manuellement le fichier de configuration. Le bloc en question (lignes 27 à 37) n’est appelé que pour la première configuration …et donc JOURNAL_FILE n’est plus modifié ;)
        
        J'utilise des guillemets simples, les variables ne sont donc pas interprétées à la création du fichier de configuration. Elle sont interprétées à chaque exécution. Donc ça devrait marcher tout seul, l'utilisateur n'aura pas besoin de mettre à jour son fichier de configuration manuellement s'il XDG_DOCUMENTS_DIR était défini lors de la création du fichier de configuration et que le journal reste à tout moment dans XDG_DOCUMENTS_DIR :-)
        
        C'est l'intérêt de mon code un peu plus complexe qu'il ne pourrait l'être.
        
        Je n'ai plus qu'à trouver pourquoi je n'ai pas XDG_DOCUMENTS_DIR, et éventuellement rapporter un bug auprès de mon environnement de bureau ou de ma distrib.
        
        par quelque chose comme :
        
        Exactement, c'est ce que je comptais faire mais tu m'as battu :-) Je commiterai probablement dans la journée.
        
        [^] # Re: L
        
        Posté par Gil Cot ✔ (site web personnel, Mastodon) le 04 mars 2024 à 19:58. Évalué à 2.
        
        Ah oui, m’étais demandé pourquoi des simple quotes, puis j’ai oublié.
        À voir du coup pour améliorer le test (-n s’assure qu’il y a une valeur de taille non nulle, mais une variable peut être définie et la chaîne avoir une longueur nulle)
        
        “It is seldom that liberty of any kind is lost all at once.” ― David Hume
- [^] # Re: L
  
  Posté par cg le 24 février 2024 à 15:11. Évalué à 5.
  Je m'étais fait le même genre de truc pour créer des tickets dans Redmine depuis un terminal, pour éviter d'oublier de noter des tâches courtes par flemme ou surcharge temporaire.
  
  Un script Perl redmineaction qui poste un nouveau ticket, et des liens symboliques vers ce script, comme :
  - todo crée un ticket en "new"
  - doing crée un ticket en "in progress"
  - did crée un ticket en "closed"
  - incident crée un ticket type incident en "in progress"
  - fixed crée un ticket type incident en "closed" etc…
  Le script détecte sous quel nom il a été lancé et fait la bonne sous-commande (fonctionnement inspiré de Busybox, notre ami à toutes).
  
  On peut mettre 2 paramètres, le premier est le sujet du ticket, le second, optionnel, est la description (courte en CLI, fatalement) :
  
  did Mise à jour anti-virus sur le serveur webmail
  
  J'ai perdu ce script en changeant de travail, c'est moche :(.
- [^] # Re: L
  
  Posté par LeBouquetin (site web personnel, Mastodon) le 24 février 2024 à 16:34. Évalué à 3.
  
  Tu fais des notes "one line" uniquement ? Ou tu as des notes non datées ? Quel intérêt (quel usage) par rapport aux notes que tu horodates automatiquement ?
  
  #tracim pour la collaboration d'équipe __ #galae pour la messagerie email __ dirigeant @ algoo
  - [^] # Re: L
    
    Posté par raphj le 24 février 2024 à 23:30. Évalué à 3. Dernière modification le 24 février 2024 à 23:34.
    
    En général oui. Sinon, je commence avec la première ligne et je complète en ouvrant l'éditeur, donc c'est toujours daté. Il est également possible de prendre en note l'entrée standard : Je lance L - et je tape ou je colle plusieurs lignes et CTRL+D pour finir la note. L e permet ensuite de corriger des choses si besoin. L + et L + - permettent aussi de compléter la dernière note.
    
    Rien n'empêcherait d'enregistrer ces notes dans un système plus complexes que ce bête fichier texte :-)
# Une vue ?

Posté par cg le 25 février 2024 à 08:30. Évalué à 2.

Hello,

est-ce que ce genre de journal ne pourrait pas être une vue/un mode d'affichage des tâches telles qu'elles existent dans un Kanban par exemple, mais affichées de manière chronologique ?

Comme ça j'ai l'impression qu'il y a un risque de répétition d'info entre un doc de compte-rendu, des tâches et ce nouvel outil de journal. Je n'ai peut-être pas tout à fait compris l'usage, ceci dit.
- [^] # Re: Une vue ?
  
  Posté par LeBouquetin (site web personnel, Mastodon) le 26 février 2024 à 10:15. Évalué à 3.
  Hello,
  
  On peut voir ça comme redondant, effectivement ; ce qui importe c'est l'usage qu'on en fait. Si tu suis un projet, aujourd'hui dans tracim tu vas par exemple créer une note avec une liste à puce et chaque point sera une étape, par exemple :
  - 11/12/2023 : Point projet avec le client
  - 08/01/2024 : Mise jour du cahier des charges
  - …
  C'est l'utilisateur, par sa rigueur, qui va devoir garantir la structure de l'information.
  
  L'utilisation d'un kanban dans ce contexte n'est pas forcément appropriée car l'objectif est d'avoir une vue temporelle synthétique : toutes les tâches qu'on mettrait dans un kanban n'auraient pas vocation à être visible dans ce journal de bord.
  
  En pratique, cette nouvelle fonctionnalité recouvre un peu les fonctionnalités qu'on peut avoir par ailleurs mais elle est différente (et complémentaire) dans l'usage :
  - les notes vont être utiles pour faire une suivi détaillé/exhaustif des compte-rendus de réunion
  - le kanban va permettre de suivre la réalisation effective de tâches multiples
  - le journal de bord va permettre d'assurer un suivi temporel d'un projet, d'une expérimentation.
  Selon les cas de figure et/ou avec qui tu participes, tu auras tendance à utiliser plutôt le journal de bord, plutôt le kanban ou plutôt des notes.
  
  Tu as raison sur le fait que ça peut se téléscoper avec les autres fonctionnalités ; c'est l'utilisateur qui décidera quel outil est le + pertinent dans quel contexte.
  
  #tracim pour la collaboration d'équipe __ #galae pour la messagerie email __ dirigeant @ algoo
  - [^] # Re: Une vue ?
    
    Posté par cg le 26 février 2024 à 13:18. Évalué à 3.
    Ah oui je comprend mieux, merci !
    
    Est-ce prévu de pouvoir mettre des liens dans ces notes, vers d'autres objets (doc, tâche, url externe) ?
    
    Genre:
```
10/02/2024 : Traduction en tagalog terminée ! [#3874]
08/01/2024 : Mise jour du cahier des charges [cdc_brocolis_a_plumes]
```
    les trucs entre crochets étant des liens vers d'autres ressources.
    
    C'est un truc que j'avais bien aimé dans le tandem Jira/Confluence, et qu'on retrouve un peu avec les "chips intelligents" dans Google Workspace (pouvoir faire des items de todo, des liens… etc dans n'importe quel doc). Mine de rien ça unifie par mal les produits entre eux.
    
    (bon en même temps c'est très facile de transformer Google Drive en gros bordel incontrôlable :D)
    - [^] # Re: Une vue ?
      
      Posté par LeBouquetin (site web personnel, Mastodon) le 26 février 2024 à 13:33. Évalué à 3.
      
      C'est de base dans Tracim les liens interdocuments oui.
      
      #tracim pour la collaboration d'équipe __ #galae pour la messagerie email __ dirigeant @ algoo

Suivre le flux des commentaires

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