Skip to content

TWELVE_MONTH_MILESTONE_PLAN.md

Latest commit

 

History

History
118 lines (82 loc) · 5.01 KB

TWELVE_MONTH_MILESTONE_PLAN.md

File metadata and controls

118 lines (82 loc) · 5.01 KB
Raw

Twelve Month Milestone Plan

Purpose

This milestone plan gives reviewers a public view of how the Agentic Enterprise Readiness Profile should mature over the next 12 months.

It is not a commitment from AAIF, the Linux Foundation, or any external maintainer. It is a planning artifact for an independent OSS profile that wants to earn ecosystem trust through evidence.

Planning Principles

  • External feedback is more important than adding new checklist items.
  • Merged upstream contributions matter more than open PR count.
  • External adoption should be opt-in and public.
  • Profile stability should increase before 1.0.0.
  • Formal AAIF or Linux Foundation routes should wait until governance and adoption evidence exist.

Milestones

Window Milestone Evidence required Recognition posture
Month 1 External trial readiness Adoption trial protocol, issue template, public trial issue, release checklist, dependency inventory, security posture plan, docs portal, community engagement plan, external reviewer program Independent review request only
Months 2-3 First external feedback At least two external comments, issues, or trial responses Feedback received, not adoption
Months 3-4 Portfolio evidence expansion Four more portfolio repositories with boundary models or readiness JSON Testbed expansion, not production proof
Months 4-6 Spec stabilization pass Spec-change process used for at least one profile or schema change Process maturity, not standardization
Months 6-8 External trial conversion At least one external repository branch, PR, or issue using the profile artifacts Trial evidence if public and opt-in
Months 8-10 Maintainer/reviewer growth At least two recurring external reviewers or one external maintainer candidate discussion Governance maturity, not foundation status
Months 10-12 1.0 candidate decision Stable schema, compatibility notes, release checklist evidence, public adoption evidence, unresolved-gap list Candidate readiness only if evidence supports it

Month 1 Operating Focus

Current focus:

  • keep AAIF PRs reviewable and conflict-free
  • keep the contribution ledger current
  • ask for external trials through issue #5
  • keep security posture, secret-safety, and release-gate evidence current
  • keep the docs portal current with release and review links
  • use the community engagement plan before any AAIF/LF-style forum post
  • invite external reviewers through the public reviewer program before claiming reviewer-group maturity
  • avoid cold-tagging maintainers
  • convert feedback into profile changes

Months 2-3 Operating Focus

Target:

  • two public external feedback signals
  • one issue or discussion summarizing where the profile is too heavy
  • one update to the adopter guide based on feedback
  • no formal proposal submission

Months 3-4 Operating Focus

Target:

  • expand beyond the first four flagship examples
  • add boundary model examples for four more repositories from the 16-repo testbed
  • include validation evidence for every promoted example
  • keep paid-provider alternatives and secret-safety posture explicit

Months 4-6 Operating Focus

Target:

  • use docs/SPEC_CHANGE_PROCESS.md for any profile, schema, scoring, or validator change
  • distinguish breaking, non-breaking, and documentation-only changes
  • add deprecation notes before enforcing stricter validator behavior
  • record compatibility decisions in release notes

Months 6-8 Operating Focus

Target:

  • one external repository tries a read-only or branch trial
  • adoption registry records only public opt-in evidence
  • reviewer feedback is linked from the registry or contribution ledger
  • false endorsement language is corrected quickly if it appears

Months 8-10 Operating Focus

Target:

  • identify recurring reviewers
  • apply the maintainer growth policy
  • document reviewer domains such as AGENTS.md, MCP, observability, identity, or governance
  • keep maintainership invitation public and consent-based

Months 10-12 Operating Focus

Target:

  • decide whether 1.0.0 is realistic
  • publish unresolved gaps instead of hiding them
  • keep formal AAIF or Linux Foundation proposal language out unless external evidence supports it
  • prepare a proposal draft only if adoption, governance, and sponsor-route evidence exists

Stop Conditions

Pause formalization if:

  • no external feedback arrives
  • upstream PRs remain unreviewed and there is no maintainer signal
  • the profile starts reading like promotion instead of evidence
  • adoption trial feedback says the profile is too heavy or duplicative

In that case, continue as an independent repository-readiness project and focus on smaller examples.

Success Definition

The 12-month plan succeeds if the project has:

  • public feedback from maintainers or external reviewers
  • one or more public adoption trials
  • a stable compatibility story
  • a documented maintainer/reviewer path
  • clear evidence of what the profile helps reviewers see

It does not require AAIF or Linux Foundation acceptance to be useful.