Migrate from Project Handbook to monday Work Management

Project Handbook pages exist as static HTML and Markdown files in a published Git repository. They have no structured fields, no owner assignments, and no status properties. We document which handbook sections were being used to track work in practice, then map each topical section to a monday.com board with the appropriate workspace scope. The board's default group is named to match the handbook section heading. This is configuration, not data migration — no records transfer, but the destination structure mirrors the source organization.

Project Handbook pages contain unstructured markdown content with no machine-readable metadata. We extract any topical headers, checklists, or tables embedded in handbook pages that represent work items in practice, then translate them to monday.com columns. Status becomes a Status column, priority becomes a Priority column (dropdown or numbers 1-4), owner becomes an People column. Column types are chosen during configuration based on the handbook's implicit data rather than a field-to-field map.

The GNOME Project Handbook is publicly maintained by contributors who commit to the Git repository. No user accounts exist in the handbook. We extract contributor names from handbook page headers or version control history (if available), map them to monday.com user accounts provisioned during setup, and set Owner columns on items accordingly. Contributors who are not given monday.com seats are listed in a separate Owners Without Seats section of the playbook for the customer's admin to assign.

Handbook pages are organized into topical sections using markdown headings (H2, H3). These headings represent the closest thing to a category or project grouping that the handbook provides. We map each top-level section (H2) to a monday.com Group within the relevant board. Group color coding is set per the team's convention during configuration.

Handbook pages frequently link to other handbook pages, external resources, or GitLab issues using standard markdown URL syntax. We extract these cross-references during discovery and map them to monday.com item Link columns or the Related Items feature, preserving the reference context where the handbook showed a connection between two topics.

Project Handbook content is version-controlled in GitLab (gitlab.gnome.org), but the published site at handbook.gnome.org exposes no revision history. monday.com's Activity Log is the functional replacement: it records every item change, column update, and comment with a timestamp and the acting user. We configure Activity Log to capture the change types that handbook version history was used to track, providing an audit trail that static pages cannot offer.

GNOME handbook pages embed links to GitLab issues, Bugzilla, mailing list archives, and external specifications. We document every external system referenced in handbook sections used for work tracking, then configure monday.com integrations (or Zapier-based connectors) during the configuration pass so that GitLab issues, calendar events, and other live references surface within monday.com boards rather than requiring navigation to the handbook.

Some handbook sections document recurring procedures — release checklists, meeting schedules, contribution reviews. We extract these from handbook prose, then create monday.com recurring Automations (at the Standard tier or above) to handle the scheduling and notification logic. Each automation maps to a handbook procedure step, with a written automation inventory documenting the trigger, conditions, and actions for the customer's admin.

Handbook pages sometimes include informal status language in prose (a project is 'in progress', a release is 'blocked', a task is 'done') but this is natural language, not a structured field. We extract status language from handbook content during discovery, normalize it to monday.com Status column values (Not Started, In Progress, Stuck, Done, or custom values matching the team's vocabulary), and document the mapping in the playbook.

Handbook pages may reference GNOME contributors by name or username when describing ownership of a task or deliverable. We extract these mentions, resolve them to monday.com user accounts (by email or display name match), and populate the People column on the relevant items during configuration. Unresolved names are flagged in the playbook for admin confirmation.

GNOME handbook pages may include release dates, milestone timelines, or meeting dates in natural language. We extract date mentions from handbook prose using pattern matching, map them to monday.com Date columns, and for timeline-aware content, configure a Timeline column covering the start and end dates found. This gives monday.com the temporal visibility that handbook prose cannot surface as structured data.

Project Handbook has no sub-item or child-record concept. Any work breakdown documented across multiple handbook pages represents a gap in task granularity. monday.com's Subitems feature allows items to have nested child tasks with their own assignees, due dates, and status. We configure subitem structure on boards where handbook prose implies multi-level work breakdown, documenting the parent-child relationship hierarchy for the admin to populate after setup.