Summary

  • OpenJS's Cross Project Council Charter says the Fall 2026 cycle will replace separate non-Impact-project and Regular-Member voting representatives with up to five elected Community Voting Members.
  • The Charter makes eligibility and electorate concrete: Community Voting Members must already be Regular Members and not Impact-project voting representatives; the electorate consists of Impact Project Voting Members and Regular Members.
  • A transition receipt should record the old seat, the new seat class, eligibility, voter roll basis, result, term state, affiliation check and unchanged Board/CPC/project authority boundaries — without claiming a completed election or a general community mandate where the public record has not established one.

A planned election is not a completed composition

Open source governance often makes a change look finished before its operative record exists. A Charter amendment is visible. A new label appears on a roster. A meeting is public. These are useful facts. None alone answers the question that matters when a voting structure changes: who, on what date, acquired which decision right through which defined process?

The OpenJS Foundation’s Cross Project Council, or CPC, offers a timely case. Its Charter describes the CPC as the Foundation’s technical leadership and distinguishes it from the Foundation Board’s business leadership. The Board sets overall CPC policy; the CPC governs technical implementation, individual project scope and direction within that policy. The same Charter says that, beginning with the Fall 2026 election cycle, separate non-Impact-project and Regular-Member voting representative paths will become a unified Community Voting Member class.

That is a real declared change. It is not evidence that the election has already opened, that nominations have closed, that a ballot has been issued, that an electorate has been validated, or that a particular person has taken a seat. As of the evidence cutoff for this article, the public Charter describes a future-effective cycle. It should be read as a rule for transition, not as a substitute for the transition's result.

The distinction is practical. A contributor looking at the CPC after the cycle needs to be able to answer several different questions without relying on oral history. Did a former At Large or Regular-Member representative finish a term, resign, become ineligible, move into the new class, or become a Regular Member without a vote? Which new Community Voting Member seats were actually filled, and for what term? Which people were eligible to vote? Was the employer-affiliation limit checked against the resulting whole voting roster? And which decisions remain with the Board, with the CPC Voting Members, or with a self-governing project?

Those questions do not accuse anyone of error. They are the minimum data needed to prevent a future roster from being mistaken for an unexplained transfer of authority.

Four kinds of participation are not one mandate

The CPC Charter names three participant classes: Observers, Regular Members and Voting Members. Its repository overview says non-members may join CPC meetings as observers, while its governance document supplies a route for an active OpenJS collaborator to become a Regular Member. The new Community Voting Member election then has a more specific electorate: Impact Project Voting Members and Regular Members.

These are connected categories, but they are not synonyms.

An observer may attend a public meeting and participate in consensus-seeking work. That makes observation and contribution real. It does not make the observer a member of the election electorate or a holder of a voting CPC seat.

A Regular Member has a narrower institutional standing. CPC governance says the person must first qualify as an Active OpenJS Collaborator, using recent and sustained activity in a project, community, collaboration space or CPC work. Requests are reviewed through a defined process. Regular Members are relevant to the new election both as eligible candidates and as part of its electorate. But Regular-Member standing still does not by itself establish that a person has been elected to the new voting class.

An Impact Project Voting Member has a different route: an Impact project may nominate up to two members through its own process. Under the new structure, those representatives continue as a distinct class, and their appointment is announced in a CPC issue and completed through the stated repository process. Their participation in the Community Voting Member electorate does not dissolve their distinct seat source.

Finally, a Community Voting Member is a future-defined voting class. The Charter says there may be up to five. A candidate must be a Regular Member and must not currently be an Impact-project voting representative. These boundaries matter because a phrase such as “the community voted” compresses at least four claims: who could participate publicly, who counted as a Regular Member, who could cast a ballot, and who actually received a voting seat. The Charter supports some of those claims in advance. The final result must support the rest.

Heng Lu’s governance note supplies a useful discipline here. Participation can contribute evidence, expertise and warning. It does not automatically create principal authority over everyone affected by an institution’s decisions. In the OpenJS case, that means a public CPC meeting, an active contributor and even an internal election are not evidence of a general mandate over the JavaScript ecosystem. They are evidence of defined roles inside a Foundation’s documented technical-governance process.

The authority boundary remains after the ballot

The new class does not alter every authority around the CPC. Voting Members hold the final CPC duties the Charter assigns, while the CPC uses lazy consensus and a defined voting route when objections cannot be resolved. The Foundation Board still sets overall policy, retains particular legal rights and remains part of Charter-change approval. Projects retain their own documented technical decision processes within CPC guidelines.

Those layers connect without becoming one another. A CPC Director may represent Foundation projects and related communities to the Board; a project charter may need CPC approval; a technical proposal may need Board escalation. A Community Voting Member therefore does not automatically become a Board director, a delegate for all maintainers, or the decision maker for a project’s internal technical choice. The record should identify the capacity that actually applies.

CPC governance already supplies several record surfaces: a public election-nomination issue, a README-update pull request after an election, a private result note, agendas and meeting material. It also acknowledges legitimate private membership, personnel, legal and Board-information matters. The receipt does not demand that every internal file be published. It joins the decisive public facts while keeping the private boundary honest.

That join matters because a new README name does not identify an end state, a term or an electorate denominator. The governance document says former Voting Members whose terms have just ended automatically become Regular Members unless they say otherwise; that is a useful default, not an individual exit record. Likewise, “up to five” does not prove how many seats were filled, and the one-quarter employer rule cannot be reproduced from a roster without a dated whole-roster denominator and affiliation basis.

The Community Voting Member transition receipt

Daniel Kade proposes a compact Community Voting Member transition receipt. It does not rewrite the Charter or demand disclosure of private candidate material. It joins the public facts that a future reader otherwise has to reconstruct from several repositories and meeting records.

The first field is the effective-cycle statement: Fall 2026, with a link to the controlling Charter wording and the old and new class names. It should state plainly whether the record concerns a planned change, nominations, a ballot, a certified result or a later correction. That one status field prevents a future-tense policy from being misread as a completed appointment.

The second field is the seat map. For every affected old path, it records the seat source, incumbent if publicly named, ordinary term boundary and end state: completed, resigned, replaced, converted only to Regular Member, standing for the new class, or not publicly specified. For every new seat, it records whether it is one of the at-most-five Community Voting Member seats, its term, and whether it is filled or vacant. The receipt must not infer a vacancy merely because a new name has not yet appeared.

The third field is eligibility and electorate. It records the candidate requirement — Regular Member and not an Impact-project voting representative — and names the voter categories from the Charter: Impact Project Voting Members and Regular Members. It should provide a dated electorate total and a method or retained internal audit for verifying that total. It does not need to publish a private eligibility explanation for every person. It does need to say what universe the result denominator came from.

The fourth field is the result and roster link: nomination issue, ballot method where disclosed, result notice, README-update pull request, effective date and resulting Voting Member roster. The Charter’s election section leaves choice of multiple-candidate method open, naming examples such as Condorcet and Single Transferable Vote. The receipt should record the method actually used rather than assuming one from a generic policy.

The fifth field is the composition constraint check. It gives the total number of Voting Members at the effective time, the public affiliation basis where one is available, the calculated one-quarter ceiling and the conclusion: satisfied, remediated, pending or not publicly specified. This is not a conflict allegation. It is the condition the Charter itself makes relevant to the validity of the resulting composition.

The sixth is the authority boundary. It points separately to Board policy and legal authority, CPC Voting Member authority, the limited function of CPC Directors, and project self-governance. It says that observer access and a Community Voting Member election are evidence of participation in a defined process, not a transfer of project or Board powers.

The final field is a non-claim and correction log. It records what has not been established publicly: a private eligibility reason, a later resignation, an unannounced ballot count, an affiliation calculation, or a Board decision. A correction is then an amendment to a dated receipt, not an invisible overwrite of a roster.

Open governance does not mean that every participant has every power. It means that each actual power has a visible source, scope and end state. The receipt lets a contributor see the Regular-Member route, a voter see the election class, a project retain self-governance and a future reader test whether an announced transition actually became a valid roster.

Sources

  1. OpenJS Cross Project Council Charter
  2. OpenJS Cross Project Council Governance
  3. OpenJS Foundation Cross Project Council repository and current roster
  4. OpenJS Foundation Governance archive
  5. Lu Heng — The Multi-Stakeholder Mirage