*Simple, blog-aware, static sites* *Second Crack* (PHP)

/150466

  • @severo
    severo PUBLIC DOMAIN
    3
    @rastapopoulos
    @habbon
    @kent1
    3
    @severo

    Je rêve d’un système de gestion des tickets a) auto-hébergé, b) simple d’utilisation (pour organisation interne du travail d’une équipe, pas pour des développeurs), c) simple de conception (solution du genre de celles proposées dans le fil ►http://seenthis.net/messages/150466) et d) accessible depuis partout e) avec éventuellement authentification.

    Les raisons sont les suivantes :
    – a) contrôle des données, utilisable en local/intranet/internet, reproductible
    – b) c’est tellement efficace, les tickets, pourquoi le réserver au développement logiciel ?
    – c) facile à maintenir, exporter/importer, archiver
    – d) les avantages du web
    – e) pour le contenu interne (mais binaire : connecté = accès à tout le contenu, non-connecté = rien - facile à gérer au niveau du serveur web)

    J’aimerais que les tickets permettent :
    – 1. un ticket par tâche, avec commentaires successifs (un ticket, quoi)
    – 2. un statut (ouvert/fermé, ou en cours/terminé)
    – 3. des labels/mots-clés pour indexer et regrouper les tickets
    – 4. assigner le ticket à une personne
    – 5. s’abonner à un ticket (pour recevoir des notifications de mise à jour) ou abonner qqn d’autre
    – 6. fixer une date limite (voire des dates limites)
    – 7. envoyer des alertes automatiques par mail 15 jours avant la date limite

    Pour être plus simple, mieux vaut diviser le problème. On peut donc imaginer :
    – un système de forum simple comme #seenthis ou #nononsense : permet 1, 3 et 5.
    – pour 2., peut être peut-on se servir de mots clés : #fermé, #réouvert, etc. et le plus récent est celui qui vaut.
    – pour 3., peut être peut-on aussi se servir de mots-clés : resp:@severo (id. le plus récent indique le/la responsable en cours)
    – pour 5. on peut imaginer abonner qqn·e d’autre simplement en le/la citant : @severo - implique qu’un script analyse tous les messages et ajoute la personne citée comme « abonné » au ticket
    – pour 6., on peut imaginer simplement mettre une URL vers un événement dans un calendrier partagé (implique de mettre en place un système de calendrier partagé - voir #baikal par exemple). Autre solution : un mot-clé : due:2014-01-17
    – pour 7. il faudrait trouver un programme qui se branche sur le calendrier partagé, et qui envoie les alertes (ça doit exister) - reste à définir le délai d’envoi par rapport à la date limite

    Je suis preneur de tout conseil ou commentaire !

    severo PUBLIC DOMAIN
    • @severo
      severo PUBLIC DOMAIN
      @fil @severo @maieul

      Oui c’est une possibilité, même si le plugin Tickets est clairement fait pour la gestion de bugs. On pourrait rendre optionnels certains champs (priorité, type de bug) et permettre d’ajouter d’autres champs, comme les mots-clés par exemple.

      Pour les dates, j’ai l’impression qu’il faut plutôt se brancher sur un système à part.

      En fait, le plugin Tickets est sûrement une bonne idée pour la partie serveur. Mais au delà, j’aimerais travailler sur la partie « client ». Pour l’affichage, un format auto-descriptif du modèle de données, c’est à dire que l’HTML du ticket suffise à l’importer dans un autre système. Il faudrait donc que toutes les données soient présentes sur le texte du commentaire. Ce qui irait dans le sens de l’import export en format mail que propose @fil :
      ►http://seenthis.net/messages/216935

      Une mise à jour du ticket, où on changerait la personne assignée, le statut, on ajouterait un mot-clé et on écrirait un commentaire, pourrait donc être affichée de la manière suivante

      Un commentaire

      resp:@severo #todo statut:#open #conception

      C’est surtout une question de squelette pour l’affichage du ticket.

      Et si une syntaxe est définie, on pourrait aussi publier à partir de la seule plage de texte. Comme on ferme habituellement des commits avec « fixes #1234 », on pourrait ainsi changer de responsable en écrivant « resp:@maieul » dans le texte, au lieu d’utiliser un formulaire. Ce commentaire pourrait être envoyé par mail, entré sur le site, etc.

      severo PUBLIC DOMAIN
    • @rastapopoulos
      RastaPopoulos CC BY-NC

      Pour « tout faire en texte », c’est assez fluide et compréhensible pour l’ajout, comme ce que fait seenthis (l’ajout de tags dans les commentaires est pris en compte dans la recherche de seens), mais si tu veux enlever des infos (tag, date, ou autre), ce n’est plus aussi simple pour les néophytes. Si on doit rajouter une syntaxe en plus genre « -#truc » ou « -resp :@truc »… ça commence à faire beaucoup de ptits caractères partout, et ça me parait assez geek.

      Vu que tu parles de tickets, et donc de todolist finalement, et en plus de texte, je t’invite aussi à lire les discussions qu’il y a eu autour du plugin « Todo » pour SPIP, dont le but était justement de générer à partir de texte brut uniquement ET que ce texte brut soit aussi lisible tel quel même avant transformation.

      ▻http://contrib.spip.net/Todo#forum462129

      Tu trouveras notamment des liens vers des tentatives de formats « standardisés » de todolist en texte brut. Notamment le format TodoTxt : ►https://github.com/ginatrapani/todo.txt-cli/wiki/The-Todo.txt-Format

      La version SPIP en est inspirée mais n’est pas pareille.

      Bien sûr, que ce soit TodoTxt ou celui de SPIP, ce sont des trucs pour une seule personne. Mais ça peut quand même donner des idées pour un système multi-utilisateurs avec commentaires.

      RastaPopoulos CC BY-NC
    Écrire un commentaire