Cross Project Council is the OpenJS Foundation's governance repository, not code

A repository whose product is a governance record

The OpenJS Foundation Cross Project Council is described as the technical governing body of the OpenJS Foundation, and its own documentation points to CPC-CHARTER.md for the description. Its stated primary role is to create the conditions for collaboration, and the README is explicit that this environment extends within and between OpenJS Foundation projects, OpenJS Working Groups and the larger community. The authority model is worth noting because it is unusual in an open source repository: the CPC exercises autonomy in managing its responsibilities, and seeks agreement from the OpenJS Foundation Board on any change to the scope of those responsibilities. So the repository is a working document, not a mirror of a decision made elsewhere. The top level entries confirm the shape. There is no source directory, no build system for an application and no library API. Instead you find governance/, meetings/, mentorship/, community-fund/, collaboration-spaces/, conduct/ and project-resources/, plus a set of policy files such as CODEOWNERS, CODE_OF_CONDUCT.md, PROJECT_SECURITY_REPORTING.md and Dates-and-Reminders.md.

The project registry is a table with blank charter cells

The most substantive part of the README is a two-part registry. The first table lists Impact Projects, and the second lists At-Large Projects, and each row carries a link to the project, a link to its charter where one exists, and a link to its contributing guide. The distinction is visible in the data. Appium and jQuery are Impact Projects with a contributing guide but an empty charter cell, while Electron, Express, Node.js and webpack have charters in their own repositories, each pointing at a different location, from a governance folder in Electron to a CHARTER.md in Express and a GOVERNANCE.md in Node.js. In the At-Large table the same pattern continues. AMP, Cosmos and Jest have charters, while ESLint, Fastify, Grunt, Interledger.js, JerryScript and Lodash show none in this listing. That pattern is the single most useful thing a reader can take from the table. Charter links point outward into each project's own repository, so this repository is a directory, and a directory entry can lag or be left incomplete. Always follow the link rather than assuming the row describes the current state of a project's governance.

How a project joins: progression and application documents

The path for a new project is documented rather than implied. The README says that if you are interested in bringing your project to the OpenJS Foundation, you should read the Project Progression document, PROJECT_PROGRESSION.md, and the New Project Application document, NEW_PROJECT_APPLICATION.md, or contact any CPC member with questions. Two separate documents for one decision is the interesting detail, because it separates the route in from the paperwork of applying. The repository also ships PROJECT_CHARTER_TEMPLATE.md, which is the piece that actually shapes governance once a project is inside. It sits alongside the other governance files, and a template matters more than a description here: it is the concrete artefact a project can copy, fill in and point at from its own repository. For a maintainer of an established open source project, the realistic use of this repository is not joining the foundation but comparing your own setup against the template, since the template is the clearest public statement of what a chartered project is expected to publish.

The build is a markdown linter and nothing else

package.json is the only executable configuration in the repository, and it is small. The scripts section defines the entire toolchain:

  "scripts": {
    "lint-md": "remark . -f",
    "test": "npm run lint-md"
  },

So the test script runs the markdown linter and nothing else. There is no unit test suite, because there is no code. The linting stack is declared as devDependencies:

  "devDependencies": {
    "remark-cli": "^12.0.0",
    "remark-lint": "^9.1.2",
    "remark-preset-lint-markdown-style-guide": "^5.1.3",
    "remark-preset-lint-recommended": "^6.1.3"
  }

The presence of remark-preset-lint-markdown-style-guide alongside the recommended preset tells you that style is enforced, not just syntax, which is consistent with a repository where prose is the primary content. The .remarkrc file at the root holds the configuration, and package-lock.json is checked in, so a contributor gets the same linter version as everyone else. This is a sensible design for a documentation repository, and it also means that any inconsistency between the README tables and the linked project repositories has to be caught by a human.

Dates-and-Reminders and CODEOWNERS carry the operational detail

Two root files hint at how the council actually runs, which is more informative than the project tables. Dates-and-Reminders.md suggests a schedule of recurring obligations, such as review or reporting deadlines, that participants are expected to track. CODEOWNERS assigns review responsibility for paths to particular owners, which is how a multi-project governance repository routes changes to the right maintainers when a pull request touches, for example, the mentorship directory or a project charter template. The rest of the tree is organised by activity rather than by technology: meetings/ holds the council's own meeting records, mentorship/ points to the mentorship programs the foundation runs for maintainers, community-fund/ tracks the community fund that supports project work, collaboration-spaces/ holds space for cross-project collaboration, conduct/ holds code of conduct related files, and project-resources/ holds shared resources for projects. Together these directories are the answer to a question the README leaves open. The council does not only decide; it also runs programs, and the repository is where those programs keep their records.

The limitation: a registry is a snapshot, not a source of truth

There is a real failure mode here, and it is structural rather than accidental. Every governance fact in this repository is a pointer to a document maintained in someone else's repository, and the pointers are maintained by hand in a markdown table. Nothing in the linting or the test script checks that a charter link still resolves, that a contributing guide has moved, or that a project listed as Impact has actually met the criteria for that status. A stale link is indistinguishable from a deliberately empty cell, because both render as a blank or broken entry. The consequence for a reader is concrete: the table can be used to discover which projects have charters, but it cannot be used as proof that a given project is currently governed in a particular way, and it should not be cited in a compliance or due diligence context without opening the underlying document. The repository is also not versioned as a release, so there is no tagged moment you can point to as the state of the registry on a given date.

Foundation-level governance versus a charter inside one project

The realistic alternative for a project is to keep all of this in its own repository, which many projects already do, with a governance file, a code of conduct and a contributing guide living next to the source. The difference in approach is about where the coordination happens. A single project repository is self-contained and cheap to maintain, and it keeps decision making close to the people doing the work, but it also means there is no shared place for cross-project matters, no common template to align against and no shared program for maintainers. The foundation arrangement buys the second set of things. It gives a project a charter template to conform to, a path through PROJECT_PROGRESSION.md and NEW_PROJECT_APPLICATION.md, and access to the mentorship and community fund directories, and it places the project next to peers that are solving adjacent problems. The cost is the one described above. A project with a small maintainer base and no interest in shared programs gets little from the arrangement, while a project that wants to coordinate with peers, or that benefits from mentorship, gets something it cannot build alone.

Editorial conclusion

Use the cross-project-council repository as the reference for how OpenJS Foundation projects are governed, listed and onboarded, and as the place to find the CPC charter, the project progression rules and the meeting and mentorship records. It will not help you configure a tool or automate a workflow, and its project table is a pointer to each project's own governance files rather than a substitute for them. Before relying on the registry, open the charter of any specific project directly, because several entries list no charter at all.

Frequently asked questions

Official sources

1. Issues
2. License: MIT
3. openjs-foundation/cross-project-council on GitHub
4. Project website
5. README