Basecamp

Membres :

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 jeudi 10 octobre 2024 à 16:39 #JaiDécouvert

En étudiant Loomio, #JaiDécouvert une fonctionnalité que je trouve très bien implémentée : "Démarrer la démo - Jouez avec un groupe exemple".

Cela crée automatiquement un groupe avec du "contexte" :

Avant cela, j'ai beaucoup aimé les "workspace" de type "sample" de Basecamp mais là, je trouve l'User experience encore meilleur. Je trouve l'entrée du menu très bien placée et très explicite.

Journal du mercredi 02 octobre 2024 à 09:55 #http-proxy, #selfhosting, #DevOps, #JaiDécouvert

#JaiDécouvert Kamal Proxy (from) « A minimal HTTP proxy for zero-downtime deployments » codé en Golang. Un projet Basecamp qui fonctionne avec kamal.

Cela attire ma curiosité, parce que la semaine dernière, je réfléchissais comment implémenter la fonctionnalité Skew Protection en self hosted, voir aussi 2023-07-04_1735.

Journal du mardi 10 septembre 2024 à 17:24 #JaiDécouvert, #SaaS

J'avais bien vu passer la news de sortie de Writebook, mais j'étais passé totalement à côté de la sortie du concept de Once.com de Basecamp.

Pour le moment, Once.com propose deux services de type SaaS without the aaS :

J'aime bien le concept de Finished software, cela me fait penser à Hare. J'aimerais utiliser davantage de logiciels qui ne nécessitent jamais de mises à jour, sauf pour les corrections de bugs.

Dans l'article Campfire is SaaS without the aaS, je lis :

It hasn’t even been a week since we started selling Campfire under the new ONCE model, but we’ve already sold more than quarter of a million dollars worth of this beautifully simple installable chat system.

Si c’est exact, 250 000 $ représentent 836 ventes, ce qui est vraiment impressionnant en moins d'une semaine !

Ce que j'apprécie particulièrement chez DHH, c'est son franc-parler et surtout son courage à aller à contre-courant. Par exemple, il défend le self-hosting, n’utilise pas TypeScript, et prône le SaaS without the aaS...

Obsidian ne souhaite jamais croitre au-delà de 12 personnes #obsidian, #OnMaPartagé, #Jadore

#OnMaPartagé au sujet de Obsidian : https://x.com/kepano/status/1694731713686196526

The plan for Obsidian is to never grow beyond 10-12 people, never take VC funding, never collect personal data or analytics.

#Jadore cela me fait penser à Basecamp.

How did you pick 10-12 as the people target?

it's roughly the max number of people you can comfortable work with without having managers — everyone is a direct contributor

👍️👌

Though I don't get why you would never want to grow more than 10-12? If you could maintain everything else, wouldn't you want more people and ability to build things in parallel?

I have done it before and it's not as fun to me. For me the love is in the craft. I want to spend my time making things, not managing people. Obsidian has 0 meetings.

🙂