nimmo/nixos-config
Watch
1
0
Fork
You've already forked nixos-config
 0
Code Issues 29 Pull requests Wiki Activity Actions
Page: 23 Project Tracking
Pages
01 Configuration Structure 02 Workflows 03 Host Configurations 04 Specialisations 05 Package Management 06 Secrets Management 07 Troubleshooting 08 Quick Reference 09 Nix Language 10 Declarative Configuration 11 Flakes 12 Modules 13 Specialargs 20 Disaster Recovery 21 Electra Secure Boot 22 Wrapper Repo Service Packaging 23 Project Tracking 24 Security Baseline Home
1 23 Project Tracking
Nimmo edited this page 2026-07-01 19:41:48 +01:00
Table of contents

Project Tracking

Active work is tracked in Forgejo. The wiki stores knowledge that remains useful after the work closes. The repository itself should not contain project plan files.

Forgejo Structure

Use one milestone for each project or workstream. Create one issue for each meaningful phase or deliverable, and apply prefixed labels so issues can be grouped without relying on Forgejo Projects automation.

Standard label shapes include:

  • project:<workstream> for the owning project
  • host:<name> or host:fleet for deployment scope
  • service:<name> where a service-specific grouping is useful
  • phase:<name> where a workstream benefits from explicit execution phases

An issue should be executable without a separate planning document. Include:

  • the context and intended outcome
  • scope and relevant repository paths
  • constraints, risks, and rollback requirements
  • concrete completion criteria
  • a checklist where ordering or handoff matters

Milestones define the project boundary. Labels support cross-project queries; they do not replace milestones.

Wiki Boundary

Issue bodies hold work state and project-specific execution detail. Move material into the wiki when it becomes a reusable:

  • operational or recovery procedure
  • architecture or security reference
  • host provisioning checklist
  • packaging or migration pattern
  • troubleshooting guide

Before deleting a planning document or closing its final issue, verify that all unfinished work is represented by open issues and all durable knowledge is in the wiki. Completed historical commentary that has no continuing operational value can be retired rather than copied.

Lifecycle

  1. Create the milestone and project label.
  2. Create scoped issues with completion criteria and host/service labels.
  3. Execute and update issues as the work advances.
  4. Add or revise wiki pages when the work produces reusable knowledge.
  5. Close completed issues and then close the milestone.

When asking for a list of current projects, query open Forgejo milestones and their issues. The wiki is reference material, not a second project tracker.