Le modèle

Six noms, et lequel possède les autres.

Rien ici n'est un écran. C'est ce dont les écrans parlent, et le reste de cette documentation emploie ces mots sans les redéfinir.

Les équipes

L'équipe est l'unité de possession et l'unité de vocabulaire. Une équipe possède ses tickets — chaque ticket en a exactement une — et elle possède la liste des statuts que ces tickets peuvent prendre, les étiquettes qu'ils peuvent porter et les champs personnalisés qu'ils peuvent contenir. Deux équipes d'une même instance peuvent être en désaccord sur les trois, et aucune n'a tort.

Les équipes s'imbriquent : une équipe peut avoir un parent, récursivement, et une requête sur le travail d'une équipe peut porter sur tout son sous-arbre. La barre latérale dessine l'imbrication mais plafonne le retrait à deux niveaux ; une imbrication de quatre rend donc les niveaux deux, trois et quatre au même retrait.

Les projets

Un projet regroupe des tickets et porte un responsable, un statut, des dates et des points de santé. C'est l'unité à laquelle se lisent une feuille de route et un planning, et c'est là qu'on attache un document quand il explique un ensemble de travail plutôt qu'un ticket.

Le projet d'un ticket doit appartenir à l'équipe du ticket. La règle est vérifiée à l'identique à la création et à la modification, et c'est elle qui empêche le projet de devenir une seconde hiérarchie concurrente.

Une exception, délibérée : un projet qui n'appartient à aucune équipe est transverse et appartient partout. C'est la seule forme sous laquelle un projet porte des tickets de plusieurs équipes — et l'élargissement du planning, qui fait entrer les autres travaillant sur un projet partagé, n'est actif que pour un projet transverse et inerte pour tous les autres.

Déplacer un projet vers une autre équipe est refusé par un 409 tant que des tickets ailleurs pointent encore dessus, plutôt que de vider silencieusement leur projet. Un ticket archivé peut maintenir ce refus sans qu'on puisse l'atteindre depuis l'écran ; c'est une aspérité connue.

Les tickets

L'unité de travail. Un ticket appartient à une équipe, éventuellement à un projet, et porte les champs ci-dessous plus une description, un assigné et les champs personnalisés déclarés par son équipe.

KAN-142: Un identifiant court propre à l'équipe, attribué dans la transaction d'insertion depuis un compteur porté par la ligne de l'équipe. C'est le nom qu'on donne au ticket à l'oral, et ce que /t/KAN-142 résout.
statut: L'un des statuts propres à l'équipe — voir plus bas. Jamais une liste globale.
priorité: Aucune, basse, moyenne, haute ou urgente. Un vocabulaire fermé, le même partout.
début, échéance: L'une, les deux, ou aucune. Une borne seule est un jalon, et le planificateur la laisse telle quelle plutôt que de faire pousser l'autre.
estimation: Des points, sur une suite de Fibonacci tronquée — 1, 2, 3, 5, 8, 13 — et nullable. Non estimé et estimé à zéro sont deux états différents : toute somme exclut le non-estimé, et tout écran qui montre une somme dit aussi combien de tickets elle n'a pas pu représenter.

Les commentaires avec mentions, les étiquettes, les favoris et les saisies de temps s'accrochent au ticket. Son activité aussi : qui a changé quoi, quand, et par quelle porte — une modification faite par un agent porte le nom de la personne dont il a utilisé le jeton.

Les statuts sont les mots de l'équipe

Une nouvelle équipe démarre avec six statuts, et c'est la dernière chose que Kanso décide à leur sujet. Une équipe les renomme, les réordonne, en ajoute un septième et en retire un dont elle ne se sert pas. La liste, le tableau, les graphiques et chaque outil MCP lui répondent alors avec ses propres mots.

Backlog, Todo, In progress, In review, Done, Canceled — les six du départ, et les six couleurs que la palette livre.

Il n'existe donc aucun statut global sur lequel filtrer deux équipes qui ont divergé. Cela rendrait le tableau inutilisable au-dessus d'une seule équipe : chaque statut déclare aussi ce qu'il signifie.

Les cinq sens

Chaque statut, renommé ou non, appartient à l'une de cinq catégories. Elles sont figées, ne s'affichent jamais comme un statut, et c'est en elles que se pose une question qui traverse deux vocabulaires : meaning:started, c'est tout ce qui est en cours, dans toutes les équipes, quel que soit le mot de chacune.

backlog: Noté, pas encore mis en file.
unstarted: En file, personne n'a commencé.
started: En cours — In progress et In review tous les deux, par défaut.
completed: Terminé.
canceled: Abandonné, et non terminé.

C'est aussi ce qui fait survivre un ticket à un déplacement. Un ticket déplacé vers une équipe qui n'a jamais entendu parler de son statut arrive dans le premier statut de même sens de cette équipe, par position — et, seulement si la destination ne sait pas exprimer ce sens du tout, dans son premier statut. Il n'arrive jamais dans un mot que personne là-bas ne sait lire.

Les arêtes entre tickets

blocks est orientée et c'est la seule que le planificateur lit : une flèche fin-à-début disant que le successeur ne peut pas commencer avant la fin de son prédécesseur. Déplacer une date règle toute la composante connexe autour du changement, et pas les seuls successeurs directs.

Une dépendance qui fermerait un cycle est refusée avec le chemin qu'elle aurait fermé, plutôt qu'avec les mots « cycle détecté » — sur quoi personne ne peut agir.

Un ticket peut avoir un ticket parent. Les sous-tickets sont une hiérarchie de lecture, pas un second planificateur : rien n'est agrégé automatiquement.

relates est symétrique et ne porte aucun ordre ; duplicates est orientée et pointe vers le survivant. Les deux existent pour que « c'est la même chose que ça » se navigue au lieu de s'écrire dans une description où rien ne peut le suivre.

Les documents

Un document est une page Notion, référencée par Kanso et non recopiée dedans. La page qui explique une décision est rattachée au travail qu'elle a décidé : on la trouve depuis le ticket au lieu d'un dossier dans un second outil.

La référence est plusieurs-à-plusieurs des deux côtés : un document peut être attaché à plusieurs projets et plusieurs tickets, et un ticket peut porter plusieurs documents. Kanso met aussi son propre index de documents en miroir dans Notion, quatrième des quatre bases.

Les champs personnalisés

Une équipe déclare ses propres champs — text, number, boolean ou select — et chaque ticket de cette équipe peut en porter une valeur. Un champ est défini une fois et valué par ticket : l'écran de réglages peut lister ce qui existe, un renommage est un renommage, et une faute de frappe est une erreur plutôt qu'un nouveau champ.

Ils sont sur le fil dans chaque réponse de ticket, y compris celles des outils MCP, depuis avant qu'il y ait quoi que ce soit à y mettre : une forme qui gagne une clé plus tard est une forme que chaque intégration existante a déjà figée.

Qui a le droit de quoi

Trois rôles d'instance qui peuvent écrire — propriétaire, administrateur, membre — et un quatrième, viewer, qui lit et n'écrit jamais. Propriétaire et administrateur sont les deux qui peuvent configurer l'instance.

Les lectures sont ouvertes ; seules les écritures sont restreintes. Aucun GET de Kanso n'est cloisonné par équipe : tout utilisateur authentifié peut lire les tickets, les projets, le planning et les membres de n'importe quelle équipe. C'est délibéré et à sens unique — le planning inter-équipes existe pour montrer qui d'autre fait quoi, et masquer une partie de « qui d'autre » supprime la raison de l'avoir construit. Les écritures, elles, sont cloisonnées par équipe, partout.

Supprimer n'est pas archiver. Archivé est une décision sans horloge ; supprimé est un compte à rebours de trente jours, et les deux sont deux onglets aux compteurs distincts dans la corbeille.