Slack

Journaux liées à cette note :

Première description du gestionnaire de projet de mes rêves #projet-24, #idée, #project-management

Introduction

Cela fait depuis 2022 que je souhaite prototyper un outil de gestion de tâches (issues) avec certaines fonctionnalités que je n'ai trouvées dans aucun outils Open source ou closed-source.

En novembre 2022, j'ai commencé le tout début d'un modèle de données PostgreSQL, mais je n'ai pas continué.

Je souhaite, dans cette note, présenter mon idée de prototype, présenter les fonctionnalités que j'aimerais implémenter.

Nom du projet : Projet 24 - Prototyper le gestionnaire de projet de mes rêves

Ces idées de fonctionnalité sont tirées de besoin personnel que j'ai rencontré depuis 2018, dans mes différents projets professionnel en équipe.

Pour réduire mon temps de rédaction de cette note et la publier au plus tôt, je ne souhaite pas détailler ici l'origine de ces besoins.
Je souhaite juste décrire quelques fonctionnalités que je souhaite et quelque détail technique sans expliquer l'origine de mon besoin.

Sources d'inspiration

Mes principales sources d'inspiration :

Je me projette d'utiliser Projet 24 dans les framework de gestion de projets suivants :

Ainsi qu'avec la technologie sociale Sociocratie 3.0.

Liste de fonctionnalités en vrac

  • Permettre d'importer / exporter une ou plusieurs issues dans un format de fichier YAML.
    • Permettre d'importer / exporter ces fichiers via Git.
    • Permettre l'utilisation de branche : création, suppression, merge de branches.
    • Permettre la gestion des branches via l'interface web.
    • Visualisation web des diff entre deux branches.
    • Permettre de commit ou créer des snapshots d'une branche.
  • Permettre d'attribuer à une issue une estimation basse et haute de temps d'implémentation.
  • Permettre d'activer un Hill Charts sur toute issue.
  • Permettre d'indiquer un niveau d'approximation d'une issue
  • Permettre aux lectures d'une issue d'indiquer leur niveau de compréhension de l'issue
  • Permettre de configurer la taille maximum en mots d'une issue. Pour forcer un certain niveau de synthèse.
  • Permettre de calculer le poids d'une issue en faisant la somme basse et haute de toutes ses dépendances.
  • Système inspiré de Tinder pour prioriser les issues. L'application présente deux issues choisies selon un algorithme Elo et invite l'utilisateur à désigner celle qu'il considère comme prioritaire.
  • Implémenter un système de tags d'issues personnalisés où chaque utilisateur peut créer ses propres étiquettes. La visibilité de ces tags serait configurable : mode privé pour un usage personnel ou mode partagé pour les rendre disponibles aux autres utilisateurs.
  • Permettre de créer des portfolios d'issue par utilisateurs.
  • Pas de séparation des entités Epic (gestion de projet logiciel) / Issue contrairement à ce que fait GitLab.
  • Permettre d'utilisation d'une extension Browser pour enrichir les pages GitHub, GitLab, Linear ou Forgejo avec les fonctionnalités de Projet 24.
  • Permettre au Projet 24 d'améliorer une instance privé Forgejo avec un wrapper HTTP.
  • Système de dashboard pratiquement identique à GitHub projects.
  • Système de commentaire comme GitHub, mais avec un système de thread.
  • Support de wikilink et alias au niveau de toutes les ressources texte.
  • Support d'une fonctionnalité de publication de notes éphémères attachées à chaque utilisateur.
  • Permettre la création d'issues ou de notes "flottantes". Une issue "flottante" n'appartient à aucune ressource spécifique — elle n'est rattachée ni à un projet, ni à un groupe. Cette fonctionnalité me semble essentielle et je compte la détailler dans une note dédiée prochainement.
  • Proposer une extension Browser qui détecte automatiquement les issues liées à l'URL de la page actuelle. Cela permettrait d'accéder rapidement aux issues ou notes "flottantes" selon le contexte de navigation.
  • Très bon support Markdown, contrairement aux implémentations de Slack, Notion ou Linear. Il devrait être possible de basculer entre le mode d'édition riche et le mode markdown. Le contenu copié doit générer du markdown valide dans le presse-papier.
  • Respect strict des conventions Web : permettre l'ouverture de toutes les pages dans un nouvel onglet, etc.
  • Mettre l'accent sur la performance de rendu des pages. Implémenter en priorité un système de métriques pour mesurer les temps de rendu.
  • Proposer un système de génération de titre d'issue et de tag basé sur un LLM.
  • Mettre en place un système qui utilise un LLM pour proposer automatiquement des titres d'issues et des tags.
  • Alimenter une base de données vectorielle avec les descriptions d'issues et leurs commentaires pour activer la recherche sémantique.

Expérience utilisateur

Comme SilverBullet.mb, un outil fait dans un premier temps pour les hackers.

Détails techniques

  • Stockage dans Elasticsearch pour faciliter les recherches par tags et plain text.
  • Utilisation de nanoid de 5 caractères pour identifier les issues.
  • Utilisation de Git hook pre-receive côté serveur pour importer des données (issues, notes, etc)

Journal du vendredi 19 juillet 2024 à 18:06 #JaiDécouvert

#JaiDécouvert Timeful Texts de Andy Matuschak.

Consider texts like the Bible and the Analects of Confucius. People integrate ideas from those books into their lives over time — but not because authors designed them that way. Those books work because they’re surrounded by rich cultural activity. Weekly sermons and communities of practice keep ideas fresh in readers’ minds and facilitate ongoing connections to lived experiences. This is a powerful approach for powerful texts, requiring extensive investment from readers and organizers. We can’t build cathedrals for every book. Sophisticated readers adopt similar methods to study less exalted texts, but most people lack the necessary skills, drive, and cultural contexts. How might we design texts to more widely enable such practices?

Cela rejoint une réflexion que j'ai eue concernant les documentations d'onboarding ou handbook d'organisation.

Problème

Il est courant de demander à aux nouveaux employés d'une startup de lire la documentation d'onboarding ou le handbook de l'organisation.

En pratique, je trouve cela peu efficace. Les premiers jours ou heures dans une nouvelle organisation sont souvent à la fois excitants et stressants. C'est une période où les individus cherchent à créer des liens, à rencontrer les autres et à comprendre qui est qui. Conséquence : je pense qu'il est difficile d'entrer en deepflow de lecture pendant cette période. Les personnes onboardé survolent la documentation et je trouve cela tout à fait justifié.

D'autre part, les informations détaillées contenues dans ces documents n'auront que peu de signification au début et ne deviendront pertinentes qu'après plusieurs semaines passées au sein de l'organisation. Et malheureusement, je constate que si les autres membres de l'équipe ne l'invitent pas, la personne onboardé retourne rarement elle-même consulter des détails bien utiles dans la documentation.

Solution humaine

Pour pallier ce problème, lors de ma dernière expérience, j'ai mis en place un système de parrain attribué à chaque nouvelle personne. Le parrain était là pour répondre à toutes les questions du nouvel arrivant et le rediriger vers les bonnes sections de la documentation.

Idée technique

En 2022, j'imaginais un système basé sur un chatbot (pour Slack ou autre) qui enverrait, de manière espacée dans le temps des liens vers des sections de la documentation à lire.
Ce chatbot pourrait aussi poser des questions, pour vérifier si la personne est au courant d'éléments contenus dans la documentation.

Cela ressemble au projet Timeful Texts 🤔.

[!Note au lecture] Pour bien comprendre le lien, je vous invite à lire l'intégralité de l'article et pas seulement l'extrait cité au début de cette note.