APM is maintainer-led. Anyone may propose improvements and participate in discussion; maintainers decide which work the project can support. This document covers project responsibilities, not APM's enterprise policy engine. The contribution process lives in CONTRIBUTING.md.
| Maintainer | Role | Responsibility | Approval remit |
|---|---|---|---|
| Daniel Meppiel | Lead and core maintainer | Project-wide scope approval, roadmap coordination, and resolution of unresolved direction disagreements. | project |
| Sergio | Core maintainer | Project-wide scope approval and technical maintenance, without requiring the lead to approve routine work again. | project |
| Nadav | Registry public API maintainer | Primary scope and technical owner for the APM registry public API. Core maintainers provide backup. | registry-public-api |
Core maintainers have overlapping project-wide responsibility; the project does not require an artificial split of every file into exclusive domains. For registry public API work, involve Nadav first. His area does not automatically include unrelated registry internals, broader CLI behavior, or project-wide authentication policy.
For cross-area work, name one coordinating maintainer and consult affected owners. When an owner is unavailable, a core maintainer may arrange qualified backup and record the handoff on the issue. Ownership routes decisions; it does not create a veto through absence or waive relevant expertise and review.
These are individual project responsibilities, not employer seats. Affiliation or sponsorship does not buy roadmap priority or approval rights. CODEOWNERS routes code review; it is not the scope-approval roster. GitHub access is managed separately under repository and organization controls. This document does not itself grant access.
Routine work within the project's direction may be approved by the responsible maintainer, with bounded scope, acceptance criteria, and a review contact recorded on the issue. The lead is not an extra approval gate for every contribution.
New product directions, significant compatibility changes, and governance changes need discussion among the affected maintainers. Seek agreement; if a direction disagreement remains unresolved, the lead records a decision and rationale. Contributors may request reconsideration with new evidence. A disagreement with an area decision can be raised with a core maintainer.
Keep proposals and decisions public on issues or PRs. Summarize decisions made in private meetings on the relevant issue, except confidential security, conduct, or organizational matters. Follow SECURITY.md and the Code of Conduct for those reports.
Human scope approval, code-review approval, and release targeting are separate decisions. Automated recommendations, labels alone, and silence do not authorize implementation or commit a release. An accepted issue does not need a release milestone. The same contribution rules apply to maintainers and automated submissions.
The table above is the only approval roster. The advisory reader uses its
Approval remit column from the trusted default branch; neither CODEOWNERS
nor a contributor's branch supplies authority. registry-public-api means
exactly the public API, not all registry, MCP, OCI, or authentication work.
Humans still judge whether a proposal fits that remit.
GitHub Triage access can change labels; no protected per-label approval ACL
is implied, and this policy does not change GitHub access grants.
New approval comments use the contribution record. The September 12 acceptance reset is not undone by labels, silence, edits, or removal of an old comment. Earlier approvals require fresh evidence.
The deterministic PR eligibility report is always neutral and advisory. It distinguishes a present record, withdrawal, missing evidence, and read errors, but never grants implementation permission. GitHub's current comment snapshot cannot prove that a withdrawal was not deleted. Fresh human confirmation of the bounded issue scope is therefore still required before an automation run implements changes. No persistent authorization ledger, required check, or automatic closing/acceptance policy is introduced.
The public APM Roadmap is the active planning surface, with actual issues as its records. Keep scope, evidence, and human approval on the issue; Horizon and priority order on the Project; release targeting in the issue's milestone. Link PRs to their issues rather than adding duplicate PR rows or draft cards. Larger outcomes use parent issues with bounded implementation sub-issues; a parent's priority does not approve every child.
Anyone may propose an outcome in an issue with the problem, evidence, and alternatives. Area maintainers assess scope, risk, and maintenance cost; core maintainers shape the shortlist, and the lead coordinates final priority order. Use the existing responsibilities, not a separate planning committee.
| Horizon | Meaning |
|---|---|
| Now | Active, reviewer-backed priorities. Start with at most three strategic outcomes alongside necessary maintenance; this is a focus guideline, not an automated cap. |
| Next | A ranked shortlist, not permission to implement. |
| Later | Deferred consideration, not a delivery promise. |
Leave Horizon empty for unselected intake. Roadmap placement, ordering, and reactions neither authorize implementation nor guarantee delivery. Moving or removing an issue from a Horizon does not revoke its human approval. Record any change to approved scope or review support explicitly on the issue. Accepted, unclaimed work still needs no second permission request: follow the contribution process, regardless of Horizon.
Aim for a weekly asynchronous triage pass to review incoming evidence, decisions, and contributor availability, and a monthly roadmap refresh to reconsider the shortlist and order against capacity. These are operating cadences, not response SLAs or mandatory meetings. Handle urgent changes between reviews with an explicit issue decision and update the Project; do not wait for the calendar.
Milestones hold plausible release cohorts, not every accepted proposal. Acceptance alone implies neither a milestone nor a release date. At each release, explicitly reconsider unfinished issues: retain the target, move to another plausible cohort, or remove the target with a reason on the issue. Never silently roll all unfinished work forward. Retain completed issues and their milestone history, including completed work in the active release.
Project 2304 has public visibility, Horizon columns, Milestone grouping, the saved views below, and native issue-only auto-add. Maintainers keep the existing-issue intake current and preserve completed issue history.
In Project settings, use public visibility and one single-select field,
Horizon, with Now, Next, and Later in that order. Leave it unset by
default. Display the native Assignees, Labels, and Milestone fields; do not
add a duplicate target-release or scope-approval field.
Save these views with repo:microsoft/apm is:issue plus the filters below:
| View | Layout and additional filter |
|---|---|
| Roadmap | Board: is:open horizon:Now,Next,Later. Group by Horizon in Now / Next / Later order and manually rank issues within each group, highest first. Unselected intake stays out. |
| Intake | Table: is:open. All open issues are visible, not implicitly approved. |
| Ready to contribute | Table: is:open label:"status/accepted" label:"help wanted" no:assignee. A discovery shortlist, not an approval check. |
| Release | Table: has:milestone, grouped by Milestone. Narrow to an existing milestone when needed; do not filter out closed issues. |
For Ready to contribute, maintainers keep labels and assignments current; contributors check the human approval, review contact, comments, and linked PRs for an existing claim. An unassigned issue can still be claimed. Neither a label nor this view substitutes for the issue record.
Under Workflows > Auto-add to project, select microsoft/apm and use
is:issue is:open. This adds visibility through Intake, without setting
Horizon, approval, invitations, or milestones. Native auto-add handles
matching issues as they are created or updated; enabling it does not backfill
existing issues. Keep automatic archival off so closing an issue does not
silently remove release history. See GitHub's
auto-add
and view-filter
instructions.
The initial rollout and its operator decisions are recorded in #2960. Keep other native workflows off; planning and release decisions remain human-owned.
| Role | How to contribute | Additional responsibility |
|---|---|---|
| Contributor | Report or reproduce problems; improve docs or code; review and help others. | No appointment is needed to participate. |
| Triager / reviewer | Consistently classify issues, give useful reviews, and help contributors navigate the process. | A trusted triager may manage issue metadata under the agreed policy, without merge access or automatic scope-approval authority. |
| Maintainer | Demonstrate sound judgment, collaboration, follow-through, and stewardship of an area or the whole project. | Approve scope within the recorded remit, support review, and maintain accepted changes. Merge authority depends on separately granted access. |
These are paths to responsibility, not a compulsory sequence or a contest for the most commits. Documentation, review, triage, and contributor support count alongside code. A contributor can remain in any role without pressure to take on more work.
To seek a role, open an issue or ask a maintainer to sponsor a nomination. Describe the proposed scope, relevant contributions, and realistic availability. An existing maintainer sponsors and mentors the transition; the core maintainers discuss it and the lead records the appointment and rationale. Obtain the nominee's agreement and update this roster for maintainer appointments. Access changes follow organization policy separately.
Maintainers should only invite implementation when a reviewing maintainer can support it. Defer openly when capacity is missing rather than leaving contributors with an indefinite promise. Review assistance and onboarding new maintainers are part of maintenance, not work reserved for the lead.
Maintainers may reduce their scope or step down by notifying the others. Arrange a handoff for active issues and update the roster. Review inactive access with the individual where possible and remove permissions no longer needed through the organization's process; stepping down is not a punishment.
Before a planned lead absence, agree who will coordinate roadmap and release decisions and record that delegation. Routine decisions remain with the responsible maintainers. If the lead cannot arrange a handoff, the remaining core maintainer or maintainers choose an interim coordinator; a permanent successor is discussed with the maintainer group and recorded publicly.
Release and infrastructure continuity also require verified backup access under Microsoft organization controls. Naming a coordinator does not prove that access exists; verify it before relying on the handoff.
Propose governance changes in an issue before a PR. Describe the problem, the affected responsibilities, and the transition for existing contributors. Record the human decision publicly and update this file and the contribution guide together where necessary. Agent personas may advise; they do not hold project offices or ratify governance decisions.