Table of Contents generated with DocToc

• Organizations
  • Membership — what can belong to an organization
  • Why this exists
  • Resolution order
  • What ships here
  • Curated skill sources
  • Authoring a new organization

An organization in Magpie groups everything a governing body — a foundation, a company, or an informal maintainer collective — makes default for the projects that belong to it:

• its identity (organization_identity: id, full name, url, and logo) — the brand the website renders for projects under it;
• its governance vocabulary (what the governing body is called, how contributors are admitted, the project-lifecycle stages); and
• its default backend selections + infrastructure values — which tool adapter fulfils each capability (CVE authority, mail archive, project metadata, …) and the concrete URLs / addresses those backends use.

It is the layer between a single project's <project-config>/ and the framework defaults. A project names its organization once (organization: <org> in <project-config>/project.md) and inherits the rest.

Beyond a project, four framework entities can declare that they belong to an organization (and so assume its stack); the value names a directory here, and absence means organization-agnostic:

For example the ASF release-management and contributor-growth families, their skills, and the cve-tool-vulnogram / ponymail / apache-projects tools all declare organization: ASF. The validator rejects a declared organization that has no directory here.

Skills are vendor- and project-agnostic: they target capabilities and resolve concrete values from configuration (see docs/vendor-neutrality.md and PRINCIPLES.md §12). Most of those concrete values are the same for every project under one organization — every ASF project allocates CVEs through the same Vulnogram instance, reads the same lists.apache.org archive, and gates on PMC membership. Without this layer each project would re-declare the identical "ASF defaults". The organization holds them once.

Every placeholder and dotted config key resolves in this order (first hit wins):

<project-config>/project.md
  →  organizations/<org>/organization.md     (org named by project.md → organization:)
    →  framework default

A project overrides only what differs from its organization; an organization overrides only what differs from the framework baseline. The contract is stated once in AGENTS.md — skills do not branch on the organization.

An organization may also vouch for external skill sources — repos other than apache/magpie that ship Magpie-shaped skills its projects may adopt. These are listed in organizations/<org>/skill-sources.md (see _template/skill-sources.md). Curation is not installation: a project under the organization still opts each source in by committing its pin to <project-config>/skill-sources.md, the install gate. The full mechanism — descriptor format, pointer files, and the pinned + verified fetch — lives in docs/skill-sources/ (PRINCIPLES.md §13, RFC-AI-0006).

Copy _template/ to fill in the governance vocabulary, the capability→adapter bundle, and the identity (incl. logo), then point a project at it with organization: <org>.

An organization can live in any of three homes (see docs/extending.md for the full model):

• In-tree — organizations/<org>/ here, contributed to apache/magpie under Apache-2.0 so every project under the organization (and others) reuses it.
• In your adopter repo — <project-config>/.apache-magpie-overrides/organizations/<org>/, committed in the adopter repo when the organization is not (yet) in-tree.
• In the organization's own repo — maintained externally and vendored into the adopter's override location; discovery, never auto-fetch (PRINCIPLES.md §13).

organization: <org> resolves in-tree first, then the adopter-local copy. See docs/adapters/authoring.md for the authoring how-to.