From e3016bf4e2421882ad75e8141fabf35c25a97b68 Mon Sep 17 00:00:00 2001 From: Michael O'Boyle Date: Wed, 17 Jun 2026 11:58:08 -0400 Subject: [PATCH 1/2] Establish OSS Committee Charter (closes #9) Add the Open Source Committee Charter as version-controlled markdown at docs/operating-guidelines/committee-charter.md, per issue #9. Charter codifies mission, scope, membership/roster, scoring rubric, two-vote decision model, retraction authority, security posture, CLA/DCO posture, and amendment process. Amended via pull request. Roster handles match data/committee-config.json (authoritative). Legal Counsel (Kenneth Carter) referenced as plain text; no verified GitHub handle. Co-Authored-By: Claude Opus 4.8 (1M context) --- .../operating-guidelines/committee-charter.md | 270 ++++++++++++++++++ 1 file changed, 270 insertions(+) create mode 100644 docs/operating-guidelines/committee-charter.md diff --git a/docs/operating-guidelines/committee-charter.md b/docs/operating-guidelines/committee-charter.md new file mode 100644 index 0000000..f2b36f5 --- /dev/null +++ b/docs/operating-guidelines/committee-charter.md @@ -0,0 +1,270 @@ +# Agentics Foundation Open Source Committee Charter + +> This charter is container #5 (Committee Operating Guidelines) in the +> 2026-05-13 five-container scope model. Per issue #9, it lives in the repo as +> version-controlled markdown at `docs/operating-guidelines/committee-charter.md`, +> amended via pull request, not as a Google Doc. +> +> Authority chain: this charter flows from the Agentics Foundation mission and +> vision (agenticsorg/.github profile/README.md) above it, and sits above the +> mechanical OSS Intake Process (the intake state machine) and the day-to-day +> Operating Principles (issue #25) below it. Where this charter and the canonical +> governance document differ, the governance document and the Board govern; this +> charter codifies current rules rather than changing them. + +## 1. Establishment and Authority + +The Open Source Committee is a standing committee of the Agentics Foundation, +established by and accountable to the Board of Directors. The Board or its +delegate appoints committee members and the Chair, and may modify, delegate, or +revoke the committee's authority (Bylaws Article X, Sections 10.1 and 10.7). + +This charter is the durable statement of the committee's mission, scope, +membership, voting model, and Chair responsibilities. It is the committee's +operating constitution; mechanical workflow detail lives in the intake process, +and day-to-day working rules live in the operating principles. + +## 2. Mission + +The Open Source Committee supports, coordinates, and stewards high-quality open +source projects that advance the agentic AI ecosystem. It operates a controlled, +member-only intake process so the Foundation can review projects for support, +collaboration, endorsement, or long-term stewardship in a way that is +transparent, auditable, and fair to submitters. + +This mission flows directly from the Foundation's own mission to "foster +innovation, promote collaboration, and build a dynamic community around +transformative agentic technologies" and its commitment to community-driven +innovation, ethical AI development, accessible technology, and practical +applications (agenticsorg/.github profile/README.md). The committee is the +Foundation's governance and signal-filtering body for the open source surface of +that mission. It is not an execution or development team. + +## 3. Scope + +### In scope + +- Member-only intake of open source projects across the five request categories: + Project Donation, Website Listing, Co-Founder Search, Problem Support, and + Contributor Engagement (Bylaws Section 10.3). +- Review and scoring of submissions against the committee's 25-point rubric + (five criteria, 0 to 5 each; see Section 6). +- Classification of projects under the adoption tiers (see Section 5). +- Retraction review of previously approved projects when grounds exist. +- Maintaining quality, integrity, and mission alignment across supported + projects. + +### Out of scope + +- Submissions from non-members or members not in good standing. +- Decisions reserved to the Board or senior Foundation leadership (escalated + matters). +- Projects with unclear licensing, IP infringement, or code-of-conduct + violations (declined without scoring). +- Assuming ownership of, or liability for, member projects, except Foundation-Owned + (T1) repositories the Foundation already holds. +- Binding the Foundation to legal, financial, or IP obligations. The committee + recommends; the Board commits. + +## 4. Membership and the Chair + +### Membership + +- Members are appointed by the Board or its delegate and must be active Agentics + Foundation members in good standing. +- The committee may include technical, governance, and community + representatives. +- Membership and roles are maintained in the committee's records, not inferred + from repository access. (Repository permissions are an operational reality, not + a grant of committee membership; see the permissions note in Section 9.) +- The authoritative membership roster is the committee configuration committed to + the repository (`data/committee-config.json`). Current voting members: + @michaeloboyle (Chair), @nicholas-ruest, @mrjcleaver, @shaal, @inde5media, and + @rcraw (Robert Ranson). Roster changes are made by PR with Chair approval. +- Foundation leadership (for example the Treasurer, Secretary, and Board Chair) + and Legal Counsel (Kenneth Carter, on CLA, DCO, and IP matters) may participate + in an advisory capacity without being voting committee members. + +### The Chair + +- The Chair (@michaeloboyle, pending Board ratification of the 2026-05-05 + appointment) facilitates meetings, sets agendas, and maintains the committee's + records and artifacts. +- The Chair's role is to find, retain, and reactivate volunteers and to make the + committee's judgment efficient, not to perform all the committee's work + (Nick Ruest's role-shift framing, 2026-05-06). +- The Chair does not hold a tie-breaking or super vote. The Chair votes as one + member. Ties resolve as "no decision" and carry to the next meeting unless the + committee agrees otherwise. + +## 5. Adoption Tiers + +Every intake decision categorizes a project into one of three adoption tiers +(2026-04-23 Tier Model; tracked in issue #10, names still open for confirmation). + +| Tier | Name | Definition | Examples | +|------|------|------------|----------| +| T1 | Foundation-Owned | Repository under `agenticsorg`; Foundation controls merge, CI, and CLA. | `community-projects`, `OIA-Model` | +| T2 | Foundation-Endorsed | Repository stays with its author; Foundation certifies CI, CLA, and a review SLA; listed on the website. | approved-through-intake projects | +| T3 | Community-Associated | Listed in the ecosystem with no guarantees; the default state. | member projects, no formal endorsement | + +Tier placement and promotion criteria are maintained in issue #10 and applied at +review. The committee does not choose winners among competing projects; multiple +projects may be approved (governance doc, Edge Case B). + +## 6. Scoring Rubric + +Submissions are scored against five criteria, each 0 to 5, for a 25-point total. +The rubric is a specification: it is changed only by committee process, never to +make a particular project pass. + +1. **Mission and Values Alignment** (0-5): relevance to agentic AI, + infrastructure, governance, or ecosystem enablement; alignment with open + source values; absence of harmful, deceptive, or exploitative intent. +2. **Project Quality and Maturity** (0-5): repository structure, documentation, + license clarity, evidence of working code, issue hygiene. +3. **Clarity of Request** (0-5): specificity and feasibility of the request; + alignment between the selected category and the description. +4. **Community Impact and Engagement Potential** (0-5): opportunity for + collaboration or learning; relevance to multiple members; likelihood of + attracting contributors. +5. **Risk and Governance Considerations** (0-5, inverted): IP or licensing + ambiguity, security or safety concerns, dependency risks, governance + complexity. Lower risk scores higher. + +Score interpretation (guidance only; the committee may override with rationale): +21-25 strong candidate for approval or escalation; 16-20 approve or approve with +conditions; 11-15 defer or request clarification; 0-10 decline. + +## 7. Decision and Voting Model + +All submissions are reviewed during scheduled committee meetings. Two sequential +votes govern each submission, each decided by a simple majority (50% + 1) of +voting members present (governance doc Sections 6 and 7). + +**Step 1: Intake validation.** Is the submitter a registered member in good +standing? Is the repository public and licensed? Is the submission complete? +If no, the submission is declined without scoring. + +**Step 2: Scoring.** Eligible members score the submission against the rubric. + +**Vote 1: Escalation Determination.** "Does this submission require escalation to +senior leadership of the Foundation?" A simple majority triggers escalation. +Automatic escalation triggers, independent of score: project donations; legal, +licensing, or IP concerns; potential core Foundation assets; reputational risk +despite a high score. If escalated, the matter is referred to senior leadership +and the committee does not hold Vote 2. + +**Vote 2: Validation Decision** (only if not escalated). "Should this request be +approved and supported by the Foundation?" Outcomes: Approved, Approved with +Conditions, Declined, or Deferred (more information required). + +**Quorum.** A simple majority of active committee members. Meetings may be +conducted virtually. + +**Conflict of interest.** A member who is a contributor, maintainer, co-founder, +or financially involved in a submission must declare the conflict and recuse from +discussion and voting. Recusals and abstentions are recorded but do not affect +quorum. Two mechanisms apply: submitter exclusion is mechanical (the intake +system bars the submitter from voting on their own submission and its retraction), +and `/coi` is voluntary (non-submitting members declare their own conflicts; the +committee never auto-recuses a non-submitter). + +## 8. Retraction Authority + +- Any member may propose retraction of a previously approved project. +- Grounds: conduct violations, licensing or IP changes, misrepresentation, + reputational, legal, or governance risk, or loss of membership standing. + Inactivity alone is not grounds; inactivity plus community confusion or risk may + trigger a retraction review. +- The project is re-scored against the rubric (emphasis on Risk and Governance, + Mission Alignment, and ongoing Quality), and the committee votes (50% + 1). + High-risk cases may be escalated. The submitter does not vote on the retraction + of their own project. +- Retraction removes the project from the website and withdraws Foundation support. + It does not constitute a claim against the project. + +## 9. Records, Transparency, and Decision Recording + +- Decisions, action items, and working artifacts live as tracked GitHub issues + with named owners, not as prose in meeting notes (operating principle: issues + over documents). If it matters, it has an issue number. +- Every status change, score, and vote leaves a durable trail in the issue and + the attestation log. Substantive proposals are not actioned on Discord alone; + Discord is the discovery layer, GitHub is the governance layer. +- Scores and deliberations are confidential unless the committee determines + otherwise. The confidentiality model is itself an open decision (issue #27). + Submitters are notified of outcomes. +- **Decision-recording convention.** A decision is recorded as: (a) an **AF-GOV + document** when it is a durable Foundation-level governance rule; (b) an **ADR** + in `docs/ADRs/` when it is an architectural decision about the intake system or + committee tooling; (c) a **tracking issue** for everything else (most decisions, + per the issues-over-documents principle). When in doubt, open an issue. +- **Permissions note.** Committee membership is recorded in + `data/committee-config.json`, independent of GitHub repository access. As of + this draft, most members including the Chair hold pull-only access; obtaining + maintain or admin access from @ruvnet is a standing operational item and does + not affect who is a committee member. + +## 10. Security and Vulnerability Handling + +The committee treats supply-chain risk and malicious-code insertion as +first-order concerns, given how rapidly code is now generated (June 3 2026 +framing). + +- **Private vulnerability reporting channel.** Security issues in Foundation-Owned + (T1) or Foundation-Endorsed (T2) projects are reported through a private channel + (GitHub private vulnerability reporting / security advisories), never as a public + issue (June 3 2026 decision; tracked as issue #13, Zero Day Protocols). +- **Coordinated disclosure.** The committee acknowledges a report, assesses + severity, coordinates a fix with the maintainer, and publishes an advisory only + after a fix or an agreed disclosure window. Zero-day handling is escalated to the + Chair and, where reputational or legal risk exists, to senior leadership. +- **Pre-review risk screening.** Submissions are screened for package and + dependency risk (for example via Snyk) as part of the Risk and Governance + criterion before approval. +- The concrete zero-day protocol (severity tiers, response times, disclosure + windows) is to be specified in issue #13 with @shaal; this charter establishes + the posture, not the runbook. + +## 11. Contribution, License, CLA, and DCO Posture + +- Submitted and supported projects must be open source under a clear, declared + license (Bylaws Section 10.2). +- **DCO over CLA for ordinary contributions.** Contributions to Foundation-Owned + repositories use the Developer Certificate of Origin (a `Signed-off-by` trailer), + which is lightweight and does not assign copyright. This is the committee's + preferred default; final selection is subject to Legal Counsel (Kenneth Carter). +- **Project donations require a separate instrument.** Accepting a project as a + donation (transfer of a repository, trademark, or maintainer obligations to the + Foundation) requires a CLA or IP-transfer agreement that does not yet exist + (AF-GOV-003 deferred it). Until that instrument is drafted and reviewed by Legal + Counsel, the committee may accept, score, and route a donation submission but a + donation cannot complete. This gates the SummaryBot pilot (issue #33) and any + future donation. This is a known blocker, not a settled policy. + +## 12. Meetings and Cadence + +- The committee meets weekly on Wednesdays at 13:00 ET (the Agentics Open Source + Meeting), conducted virtually. +- The Chair publishes an agenda before each meeting and records outcomes as + GitHub issues and meeting summaries. +- Regular cadence is determined by the committee and may change by committee + decision. + +## 13. Operating Principle + +**Humans judge, agents execute** (AF-GOV-002). Automation handles analysis, +logistics, triage, case preparation, and infrastructure. Committee members cast +every vote and make every escalation, approval, and retraction decision. Agents +never cast votes, decide escalation, or propose retraction. The committee's human +judgment is the point; tooling exists to make that judgment efficient and +well-informed. + +## 14. Amendments + +This charter is amended by pull request against +`docs/operating-guidelines/committee-charter.md`, reviewed by the committee, and +ratified by merge. Amendments that change Foundation-level governance, or that the +Board has reserved to itself, additionally require Board ratification (Bylaws +Section 10.7). From d000d524a0cd14ba7be5c001a4db9a5c1ea0c127 Mon Sep 17 00:00:00 2001 From: Michael O'Boyle Date: Wed, 17 Jun 2026 12:12:17 -0400 Subject: [PATCH 2/2] Address Copilot review on charter (#9 frontmatter, ADR path) Restore minimal author/maintainer frontmatter required by issue #9 acceptance criteria (lean block: author, author_github, maintainer, maintainer_github, status, target). Reword the decision-recording convention so the docs/ADRs/ reference no longer points at a non-existent path (now "to be created when the first ADR is written"). Co-Authored-By: Claude Opus 4.8 (1M context) --- docs/operating-guidelines/committee-charter.md | 14 ++++++++++++-- 1 file changed, 12 insertions(+), 2 deletions(-) diff --git a/docs/operating-guidelines/committee-charter.md b/docs/operating-guidelines/committee-charter.md index f2b36f5..8ce3f7f 100644 --- a/docs/operating-guidelines/committee-charter.md +++ b/docs/operating-guidelines/committee-charter.md @@ -1,3 +1,12 @@ +--- +author: Michael O'Boyle +author_github: "@michaeloboyle" +maintainer: Michael O'Boyle +maintainer_github: "@michaeloboyle" +status: draft +target: agenticsorg/community-projects#9 +--- + # Agentics Foundation Open Source Committee Charter > This charter is container #5 (Committee Operating Guidelines) in the @@ -197,8 +206,9 @@ committee never auto-recuses a non-submitter). Submitters are notified of outcomes. - **Decision-recording convention.** A decision is recorded as: (a) an **AF-GOV document** when it is a durable Foundation-level governance rule; (b) an **ADR** - in `docs/ADRs/` when it is an architectural decision about the intake system or - committee tooling; (c) a **tracking issue** for everything else (most decisions, + (in a `docs/ADRs/` directory, to be created when the first ADR is written) when + it is an architectural decision about the intake system or committee tooling; + (c) a **tracking issue** for everything else (most decisions, per the issues-over-documents principle). When in doubt, open an issue. - **Permissions note.** Committee membership is recorded in `data/committee-config.json`, independent of GitHub repository access. As of