Passer de Linear à GitHub & Feuille de route LIVE 2.0

De Linear à GitHub

TLDR; Nous quittons Linear et nous n'utilisons que GitHub à partir de maintenant. Nous ne communiquons plus les délais de fonctionnalités, seulement sur quoi nous travaillons et ce qui est prévu ensuite.

Si vous nous suivez, vous savez que nous sommes en plein mode construction. Nous construisons, la communauté construit, c'est génial. Construire est notre quotidien, donc nous réfléchissons beaucoup à améliorer notre approche pour le faire.

Notre approche la plus récente consiste à réduire le nombre d'outils et de plateformes que nous utilisons. Chaque outil que nous utilisons

• Réduit le temps moyen que vous passez sur l'outil

• Réduit votre concentration

• Augmente la charge mentale pour garder tous les points d'intérêt à l'esprit

Nous avons réfléchi à l'endroit où nous passons le plus de temps, et pas vraiment une surprise : c'est GitHub. Non seulement nous y passons beaucoup de temps, mais nous voulons aussi y passer beaucoup de temps parce que :

• C'est là que la communauté contribue, et nous sommes entièrement axés sur la communauté

• C'est là que nous montrons au monde ce sur quoi nous travaillons

La vieille structure

Jusqu'à présent, nous avons utilisé Linear pour notre gestion des tâches et nos tâches synchronisées que nous souhaitons mettre en avant ou sur lesquelles nous voulons travailler avec la communauté via synclinear.com. Non seulement nous avions nos problèmes de développement là-bas, mais comme nous avons notre propre designer résident, nous avons créé un véritable backlog de conception pour structurer nos flux de travail de conception.

La nouvelle structure

Nous avons tout déplacé sur GitHub une fois que nous avons réalisé que notre concentration y était déjà. Cela a quelques avantages clés :

• Réduire la dilution de l'attention et du temps : Vous pouvez passer du temps sur GitHub sans risquer de manquer grand-chose

• Mettre différents aspects de Documenso près les uns des autres : Développement, Conception, Communauté

• Garder les problèmes à long terme, de niche, et très abstraits hors du dépôt principal pour ne pas nous désensibiliser par des chiffres de problèmes importants

Pour y parvenir, nous avons créé quelques dépôts GitHub pour héberger des problèmes, le dépôt principal restant le point d'intérêt central, en particulier pour la communauté.

1. Dépôt principal - Problèmes quotidiens et la feuille de route à court terme (Feuille de route EN DIRECT 2.0)

github.com/documenso/documenso

Apart du code source de l'application et du site web Documenso, le dépôt principal abrite les problèmes soulevés par la communauté et les problèmes pour lesquels nous invitons la communauté à participer.

Avec la restructuration de notre gestion des problèmes, nous mettons également à jour notre communication sur les progrès. Bien que le processus de développement logiciel et de produit soit très complexe,

nous essayons de donner autant d'informations que possible sur ce que nous faisons. À cette fin, nous avons traversé 3 phases, la troisième étant ce que nous faisons maintenant.

1. Une feuille de route extensive : Au départ, nous avions une feuille de route et cochions (très) lentement des cases là-bas (via une étape de "Feuille de route"). Bien que cela soit facile, c'est aussi assez imprécis et peu pratique à mesure que le projet avance

2. Sorties estimées par trimestre : Pour donner de meilleures indications, nous avons essayé de communiquer nos objectifs pour le trimestre ; une fenêtre assez large que nous pensions pouvoir à peu près "atteindre". Bien que l'idée de ne pas être trop détaillé soit bonne, il est difficile d'estimer quand certaines choses significatives sont terminées si vous faites beaucoup de petites/autres choses en parallèle, comme travailler avec la communauté et ajuster les choses au fur et à mesure. Atteindre des objectifs temporels est délicat car il peut y avoir de meilleures choses à faire que de respecter cet objectif temporel. C'est toujours beaucoup plus facile à comprendre pour les personnes directement impliquées. La fausse idée est de supposer que la chose pour laquelle vous planifiez existe dans le vide.

3. Comme nous ne voulons pas nous limiter à choisir la voie la plus efficace mais que nous souhaitons tout de même donner un aperçu de ce qui se passe et de ce qui arrive, nous avons mis à jour la feuille de route en direct https://documen.so/live. Elle montre désormais ce sur quoi nous travaillons actuellement et ce que nous prévoyons de faire ensuite. Nous ne fournissons plus de chronologie spécifique car nous ne pourrions même pas, même si nous le voulions. Bien sûr, nous fixons nos objectifs à court terme en fonction de ce qui est le mieux pour la communauté. Nous donnons des mises à jour sur les problèmes en cours de traitement autant que possible.

2. Backlog public - La feuille de route à plus long terme

github.com/documenso/backlog

Le backlog public abrite tout ce que nous souhaitons construire finalement. Nous ne fournissons pas de calendrier spécifique pour savoir quand cela pourrait se produire. Si nous décidons de ne pas faire quelque chose, cela sera retiré du backlog public, car nous considérons cela comme notre vision à long terme pour Documenso. Si vous êtes intéressé par quelque chose sur la feuille de route, commentez sur le problème ou postez sur Discord. Cela nous aide à évaluer l'intérêt pour des fonctionnalités spécifiques.

Les problèmes dans le backlog public ne sont pas disponibles pour y travailler. Pour les problèmes sur lesquels travailler, veuillez consulter les problèmes du dépôt principal. Les problèmes trouvés ici sont plus larges car ils ne sont pas destinés à une exécution immédiate, mais plutôt à donner une idée de l'orientation de Documenso et de ce que nous considérons comme faisant partie de notre domaine.

3. Backlog interne

github.com/documenso/backlog-internal

Cela sert de remplacement direct à notre backlog Linear. Ici, nous gérons des problèmes qui sont soit trop petits ou à court terme pour être inclus dans la feuille de route à long terme, soit trop spécialisés ou fondamentaux pour être intégrés dans le dépôt principal. Notre tableau Kanban de développement est mis en œuvre à l'aide d'un projet GitHub.

4. Backlog de conception interne

github.com/documenso/design-internal

Ceci est l'équivalent de la conception du backlog interne. Le backlog de conception interne abrite nos projets de conception qui incluent l'exploration de nouvelles fonctionnalités, des conceptions UI détaillées et l'amélioration globale de la plateforme.

C'est similaire au tableau Kanban pour le backlog de développement.

5. Dépôt de design public

github.com/documenso/backlog-design

Bien que le backlog de conception interne ait également existé dans Linear, le dépôt de design public est nouveau. Comme concevoir en open est compliqué, nous avons choisi de publier les artefacts de conception détaillés avec les fonctionnalités correspondantes.

Nous avons déjà design.documenso.com qui abrite notre système de design général. Ici, nous publierons les spécificités de la manière dont nous avons appliqué cela à chaque fonctionnalité. Nous publierons bientôt les premiers artefacts ici, ce qui pourrait être prévu se trouve sur la Feuille de route EN DIRECT.

N'hésitez pas à nous contacter sur Twitter / X (DM ouvert) ou Discord si vous avez des questions ou des commentaires ! Nous sommes toujours là pour aider et nous aimerions avoir de vos nouvelles :)

Meilleurs vœux de Hamburg

Timur