Wechsel von Linear zu GitHub & LIVE Roadmap 2.0

Von Linear zu GitHub

TLDR; Wir verlassen Linear und verwenden ab jetzt nur noch GitHub. Wir kommunizieren keine Zeitpläne für Funktionen mehr, sondern nur, woran wir arbeiten und was als Nächstes kommt.

Wenn Sie uns folgen, wissen Sie, dass wir im Vollaufbaubetrieb sind. Wir bauen, die Community baut, es ist großartig. Der Aufbau ist unser tägliches Geschäft, daher denken wir viel darüber nach, wie wir unseren Ansatz zur Umsetzung verbessern können.

Unser jüngster Ansatz besteht darin, die Anzahl der Tools und Plattformen, die wir verwenden, zu reduzieren. Jedes Tool, das wir verwenden,

• reduziert die durchschnittliche Zeit, die Sie mit dem Tool verbringen

• reduziert Ihre Konzentration

• erhöht die geistige Belastung, um alle interessanten Punkte im Kopf zu behalten

Wir haben darüber nachgedacht, wo wir die meiste Zeit verbringen, und kaum überraschend: es ist GitHub. Nicht nur, dass wir dort viel Zeit verbringen, wir WOLLEN auch viel Zeit dort verbringen, weil:

• Es ist der Ort, an dem die Community beiträgt, und wir sind ganz auf die Community fokussiert

• Es ist der Ort, an dem wir der Welt zeigen, woran wir arbeiten

Die alte Struktur

Bisher haben wir Linear für unser Backlog / Task Management genutzt und synchronisierte Probleme, die wir der Community über synclinear.com präsentieren oder an denen wir arbeiten wollten. Nicht nur hatten wir unsere Entwicklungsprobleme dort, sondern da wir unseren eigenen Design-Designer haben, haben wir ein ordentliches Design-Backlog erstellt, um unsere Design-Workflows zu strukturieren.

Die neue Struktur

Wir haben alles zu GitHub verschoben, als wir bemerkten, dass unser Fokus bereits dort lag. Das hat einige wichtige Vorteile:

• Verdünnung von Aufmerksamkeit und Zeit reduzieren: Sie können sich auf GitHub aufhalten, ohne das Risiko, viel zu verpassen

• Verschiedene Aspekte von Documenso eng beieinander bringen: Entwicklung, Design, Community

• Langfristige, Nischen- und sehr abstrakte Probleme aus dem Haupt-Repository heraushalten, damit wir nicht durch große Zahlen an Problemen abgestumpft werden

Um dies zu erreichen, haben wir einige GitHub-Repositories erstellt, um Probleme zu hosten, wobei das Hauptrepository der zentrale Interessenspunkt bleibt, insbesondere für die Community.

1. Haupt-Repository - Tägliche Probleme und der kurzfristige Fahrplan (LIVE Fahrplan 2.0)

github.com/documenso/documenso

Abgesehen vom Quellcode der Documenso-App und der Website enthält das Haupt-Repo von der Community aufgeworfene Probleme und Probleme, bei denen wir die Community zur Teilnahme einladen.

Mit der Überarbeitung unseres Problemanagements aktualisieren wir auch unsere Fortschrittskommunikation. Während der Software- und Produktentwicklungsprozess hochkomplex ist,

versuchen wir, so viel Einblick wie möglich in das, was wir tun, zu geben. Zu diesem Zweck haben wir drei Phasen durchlaufen, wobei die dritte das ist, was wir jetzt tun.

1. Ein umfangreicher Fahrplan: Zunächst hatten wir einen Fahrplan und haben (sehr) langsam Kästchen dort abgehakt (über einen "Fahrplan" Meilenstein). Während dies einfach ist, ist es auch ziemlich ungenau und unpraktisch, da das Projekt wächst.

2. Geschätzte Veröffentlichungen pro Quartal: Um bessere Hinweise zu geben, haben wir versucht, unsere Ziele für das Quartal zu kommunizieren; ein ziemlich großes Fenster, das wir grob "treffen" konnten. Während die Idee, nicht zu detailliert zu sein, gut war, ist es schwierig abzuschätzen, wann einige wichtige Dinge erledigt sind, wenn man viele kleinere/ andere Dinge parallel macht, wie die Zusammenarbeit mit der Community und das Abstimmen von Dingen, die man macht. Zeitziele zu treffen ist knifflig, weil es möglicherweise bessere Dinge gibt, die zu tun sind, als sich an dieses Zeitziel zu halten. Dies ist immer viel leichter für die nahe verwandten Menschen zu verstehen. Die Fehlannahme besteht darin, zu glauben, dass das, was man plant, in einem Vakuum existiert.

3. Da wir uns in der Wahl des effektivsten Kurs nicht einschränken wollen, aber trotzdem einen Einblick geben wollen, was vor sich geht und was als Nächstes kommt, haben wir den Live-Fahrplan https://documen.so/live aktualisiert. Er zeigt jetzt, woran wir gerade arbeiten und was wir als Nächstes planen. Wir geben keinen spezifischen Zeitrahmen mehr an, da wir selbst nicht einmal wollten. Natürlich setzen wir unsere kurzfristigen Ziele basierend auf dem, was für die Community am besten ist. Wir geben so oft wie möglich Updates zu den bearbeiteten Problemen.

2. Öffentliches Backlog - Der längerfristige Fahrplan

github.com/documenso/backlog

Das öffentliche Backlog enthält alles, was wir letztendlich bauen möchten. Wir geben keinen spezifischen Zeitrahmen an, wann das passieren könnte. Wenn wir uns gegen etwas entscheiden, wird es aus dem öffentlichen Backlog entfernt, da wir dies als unsere langfristige Vision für Documenso betrachten. Wenn Sie an etwas auf dem Fahrplan interessiert sind, kommentieren Sie das Problem oder posten Sie auf Discord. Dies hilft uns, das Interesse an bestimmten Funktionen einzuschätzen.

Probleme im öffentlichen Backlog sind nicht verfügbar, um daran zu arbeiten. Für Probleme, an denen gearbeitet werden kann, prüfen Sie bitte die Probleme im Hauptrepository. Die hier gefundenen Probleme sind breiter gefasst, da sie nicht für die sofortige Ausführung gedacht sind, sondern eher ein Gefühl vermitteln, wohin Documenso geht und was wir als Teil unseres Bereichs betrachten.

3. Internes Backlog

github.com/documenso/backlog-internal

Dies dient als direkter Ersatz für unser Linear-Backlog. Hier verwalten wir Probleme, die entweder zu klein oder kurzzeitig sind, um in den langfristigen Fahrplan aufgenommen zu werden, jedoch zu speziell oder grundlegend, um in das Hauptrepository integriert zu werden. Unser Entwicklung-Kanban-Board wird mit einem GitHub-Projekt implementiert.

4. Internes Design-Backlog

github.com/documenso/design-internal

Dies ist das Designäquivalent des internen Backlogs. Das interne Design-Backlog umfasst unsere Designprojekte, die die Erkundung neuer Funktionen, detaillierte UI-Designs und die Verbesserung der Plattform insgesamt beinhalten.

Es ist ähnlich wie das Kanban-Board für das Entwicklungs-Backlog.

5. Öffentliches Design-Repository

github.com/documenso/backlog-design

Während das interne Design-Backlog auch in Linear existierte, ist das öffentliche Design-Repository neu. Da das Designen in der Öffentlichkeit schwierig ist, haben wir uns entschieden, die detaillierten Designartefakte mit der entsprechenden Funktion zu veröffentlichen.

Wir haben bereits design.documenso.com, auf dem unser allgemeines Designsystem gehostet wird. Hier werden wir die Einzelheiten veröffentlichen, wie wir dies auf jede Funktion angewendet haben. Wir werden bald die ersten Artefakte hier veröffentlichen; was möglicherweise ansteht, kann auf dem LIVE Fahrplan gefunden werden.

Bitte zögern Sie nicht, uns auf Twitter / X (DM geöffnet) oder Discord zu kontaktieren, wenn Sie Fragen oder Kommentare haben! Wir sind immer hier, um zu helfen, und würden uns freuen, von Ihnen zu hören :)

Beste Grüße aus Hamburg

Timur