Skip to content

Atlaso Development Project

The public Atlaso Development Project is the ongoing planning record for repository issues and pull requests. GitHub automatically adds new items from mdaneri/Atlaso; maintainers then assign the appropriate milestone and planning metadata. Repository issues and pull requests remain the source of truth for assignees, labels, milestones, reviewers, and linked work.

Release tracking

The Release 1.0 milestone identifies work included in the first stable Atlaso release. The project continues after Release 1.0 so later milestones can use the same fields, views, and automation.

New items enter the project without an assumed priority, complexity, or milestone. A maintainer triages those values instead of treating an automated estimate as a delivery commitment.

Project fields

Field Source or allowed values Meaning
Owner mdaneri Project-only delivery owner
Item kind Issue, Pull request Repository item type
Work type Bug, Enhancement, Documentation Unambiguous type label or linked-issue type
Priority P0, P1, P2, P3 Maintainer-assigned delivery priority
Complexity XS, S, M, L, XL Reproducible change-size proxy
Opened GitHub creation date Calendar date when the item was created
Completed GitHub close or merge date Calendar date when completed
Cycle time (hours) Creation to close or merge Elapsed wall-clock time, not engineering time
Changed files Pull-request metadata Number of files changed
Changed lines Pull-request additions plus deletions Total changed-line count

Pull-request complexity uses the larger bucket produced by changed lines and changed files:

Complexity Changed lines Changed files
XS 0–200 0–5
S 201–500 6–10
M 501–1,500 11–25
L 1,501–4,000 26–50
XL >4,000 >50

An issue inherits the highest complexity of its linked pull requests. Complexity remains empty when no linked delivery evidence exists. Work type also remains empty when labels or linked issues do not identify exactly one type.

Views and maintenance

  • Overview is the complete issue and pull-request inventory.
  • Release 1.0 filters the current release milestone and groups work by status.
  • Open work is the active backlog and work in progress.
  • Pull requests focuses on delivery, reviewers, change size, and linked issues.
  • History retains completed and closed work for cycle-time and complexity analysis.

Project insights summarize item counts by status, work type, and complexity. GitHub's built-in workflows set closed issues and merged pull requests to Done. Maintainers should periodically filter for empty Owner, Work type, Priority, Complexity, or Milestone values and triage them.

Organization migration

GitHub does not transfer a user-owned project when its repository moves to an organization. When Atlaso moves to the atlaso-project organization, create an organization-owned Atlaso Development project and rebuild its fields, views, charts, collaborators, repository link, and workflows from this page. Re-import every transferred repository issue and pull request, reconcile the old and new projects by node ID, and update this page to the organization-owned project URL.

A project copy can provide a starting layout, but it does not include items, collaborators, repository links, or auto-add workflows. Keep the user-owned project available as a read-only migration record until the organization-owned project is complete and the inventory reconciliation passes.