Migrate from Project Handbook to Trello

Project Handbook consists of static HTML and markdown pages published at handbook.gnome.org. There is no database, no API, no user accounts, and no structured records. No migration path exists from any handbook page to a Trello object. We confirm zero migratable records during discovery by probing the handbook's structure and verifying the absence of any data export endpoint.

We design Trello boards to represent the project areas previously documented in the handbook. Each board maps to a logical work area (e.g., a GNOME subsystem or team). Boards are the top-level container in Trello's hierarchy and inherit Workspace-level member permissions. We configure board visibility (public, workspace, private) during workspace design.

We design Trello lists to represent the workflow stages previously described in static handbook pages. A typical board uses lists such as Backlog, To Do, In Progress, In Review, Done. Each list is a column in the Kanban view and acts as the parent container for cards. We configure default list names during workspace setup based on the customer's existing process documentation.

Trello cards represent individual tasks, decisions, or deliverables that were previously documented as static handbook pages. We create a card for each discrete work item identified during the handbook audit. Card fields include a title (from the handbook section heading), description (converted from handbook markdown), assignee (mapped from team member list if available), due date (extracted from any dated references in handbook content), and checklist items (converted from bulleted task lists in the handbook).

Handbook markdown content is converted to Trello card descriptions. We preserve headings as bold text, code blocks as formatted code, links as hyperlinks, and embedded images as attachments or linked resources. We flag any handbook content that references GitLab issues, Bugzilla tickets, or mailing list threads as requiring manual linking because the handbook does not store those references as structured data.

Handbook category tags (e.g., GNOME subsystem names, document types, contributor roles) map to Trello labels. Labels are key-value color-coded tags applied to cards for filtering. We create a label set during workspace setup that mirrors the taxonomy used in the handbook's navigation structure.

Any bulleted task lists found in handbook content convert to Trello checklists within a card. A checklist can have multiple items with individual completion status. We map each bullet point to one checklist item, preserving the original ordering where determinable from the handbook source.

Trello's Custom Fields Power-Up (included in Standard and Premium) adds typed fields to cards — dropdown, date, number, checkbox, or text. We configure custom fields to capture metadata that was implicit in the handbook (e.g., GNOME subsystem, priority tier, owner role) as explicit card-level fields. Custom field types cannot be changed after creation, so we finalize the schema during workspace design before any cards are populated.

Trello Butler automation rules replace the static documentation workflow described in the handbook. We configure board-level or list-level rules that trigger on card movement (e.g., when a card moves to Done, post a comment and set a due date reminder). Butler rules do not migrate from any source; we design them based on the customer's described process and configure them during workspace setup.

Handbook reader access was public and anonymous. Trello requires explicit member management. We provision Trello workspace members to match the team that the handbook was serving. We configure member roles (admin, normal, guest) based on the team's organizational structure. We do not migrate any user records because none exist in the handbook.

Cards with due dates render in Trello's Calendar Power-Up view (included in Standard and Premium). We enable this Power-Up and ensure that any date references in handbook content are entered as card due dates to produce a calendar view of work items. This replaces the static date listings that appeared in handbook process pages.

Handbook pages may contain hyperlinks to external resources (GitLab issues, mailing list archives, specification documents). We convert these hyperlinks into Trello card attachments and links so that card context is preserved in one place. We do not extract file attachments from the handbook because it does not host file objects — all assets are external links only.