Skip to content

Commit f7d1695

Browse files
imran-siddiqueCopilot
imran-siddique
and
Copilot
authored
docs: add CHARTER.md, RELEASE.md, and DCO enforcement for AAIF readiness (#1787)
- CHARTER.md: LF Projects Technical Charter (TSC structure, IP policy, voting, amendments) adapted from agentgateway template with AGT-specific mission statement and MIT license reference - RELEASE.md: documents versioning policy, release cadence, registry coverage (PyPI, npm, NuGet, crates.io, GHCR), automated publishing, hotfix process, and supply chain security measures - dco.yml: GitHub Actions workflow that checks all PR commits for Signed-off-by trailer (Developer Certificate of Origin) - CONTRIBUTING.md: added DCO section with sign-off instructions - GOVERNANCE.md: references RELEASE.md and CHARTER.md Signed-off-by: Imran Siddique <imran.siddique@microsoft.com> Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
1 parent fa0e9df commit f7d1695

5 files changed

Lines changed: 358 additions & 1 deletion

File tree

‎.github/workflows/dco.yml‎

Lines changed: 54 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,54 @@
1+
name: DCO Check
2+
3+
on:
4+
pull_request:
5+
types: [opened, synchronize, reopened]
6+
7+
permissions:
8+
contents: read
9+
10+
jobs:
11+
dco:
12+
name: Developer Certificate of Origin
13+
runs-on: ubuntu-latest
14+
steps:
15+
- uses: actions/checkout@11bd71901bbe5b1630ceea73d27597364c9af683 # v4.2.2
16+
with:
17+
fetch-depth: 0
18+
19+
- name: Check DCO sign-off on commits
20+
run: |
21+
BASE="${{ github.event.pull_request.base.sha }}"
22+
HEAD="${{ github.event.pull_request.head.sha }}"
23+
MISSING=()
24+
25+
for SHA in $(git rev-list "$BASE".."$HEAD"); do
26+
# Skip merge commits
27+
PARENTS=$(git rev-parse --verify "$SHA^2" 2>/dev/null && echo "merge" || echo "normal")
28+
if [ "$PARENTS" = "merge" ]; then
29+
continue
30+
fi
31+
32+
# Check for Signed-off-by trailer
33+
if ! git log -1 --format='%B' "$SHA" | grep -qiE '^Signed-off-by: .+ <.+>'; then
34+
AUTHOR=$(git log -1 --format='%an <%ae>' "$SHA")
35+
SHORT=$(git log -1 --format='%h' "$SHA")
36+
MISSING+=("$SHORT by $AUTHOR")
37+
fi
38+
done
39+
40+
if [ ${#MISSING[@]} -gt 0 ]; then
41+
echo "::error::The following commits are missing a DCO sign-off (Signed-off-by trailer):"
42+
for M in "${MISSING[@]}"; do
43+
echo " - $M"
44+
done
45+
echo ""
46+
echo "To fix, amend your commits with: git commit --amend --signoff"
47+
echo "Or for all commits: git rebase --signoff HEAD~N"
48+
echo ""
49+
echo "See https://developercertificate.org for details."
50+
exit 1
51+
fi
52+
53+
echo "All commits have valid DCO sign-off."
54+

‎CHARTER.md‎

Lines changed: 200 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,200 @@
1+
## Technical Charter (the "Charter") for Agent Governance Toolkit, a Series of LF Projects, LLC
2+
3+
This Charter sets forth the responsibilities and procedures for technical contribution to, and
4+
oversight of, the Agent Governance Toolkit open source project, which has been established as
5+
Agent Governance Toolkit a Series of LF Projects, LLC (the "Project"). LF Projects, LLC
6+
("LF Projects") is a Delaware series limited liability company. All contributors (including
7+
committers, maintainers, and other technical positions) and other participants in the Project
8+
(collectively, "Collaborators") must comply with the terms of this Charter.
9+
10+
### 1. Mission and Scope of the Project
11+
12+
a. The mission of the Project is to provide open source libraries, tools, and
13+
reference implementations that help developers build, deploy, and operate
14+
AI agent systems with built-in governance, safety, and compliance controls,
15+
covering identity, policy enforcement, capability sandboxing, auditability,
16+
and human oversight.
17+
18+
b. The scope of the Project includes collaborative development under the Project
19+
License (as defined herein) supporting the mission, including documentation,
20+
testing, integration and the creation of other artifacts that aid the development,
21+
deployment, operation or adoption of the open source project.
22+
23+
### 2. Technical Steering Committee
24+
25+
a. The Technical Steering Committee (the "TSC") will be responsible for all
26+
technical oversight of the open source Project.
27+
28+
b. The TSC voting members are initially the Project's Maintainers. At the inception
29+
of the project, the Maintainers of the Project will be as set forth within the
30+
"MAINTAINERS.md" file within the Project's code repository. The TSC may
31+
choose an alternative approach for determining the voting members of the TSC,
32+
and any such alternative approach will be documented in the CONTRIBUTING
33+
file. Any meetings of the Technical Steering Committee are intended to be open
34+
to the public, and can be conducted electronically, via teleconference, or in
35+
person.
36+
37+
c. TSC projects generally will involve Contributors and Maintainers. The TSC may
38+
adopt or modify roles so long as the roles are documented in the
39+
CONTRIBUTING file. Unless otherwise documented:
40+
- Contributors include anyone in the technical community that contributes
41+
code, documentation, or other technical artifacts to the Project;
42+
- Maintainers are Contributors who have earned the ability to modify
43+
("commit") source code, documentation or other technical artifacts in a
44+
project's repository; and
45+
- A Contributor may become a Maintainer by a majority approval of the
46+
TSC. A Maintainer may be removed by a majority approval of the TSC.
47+
48+
d. Participation in the Project through becoming a Contributor and Maintainer is
49+
open to anyone so long as they abide by the terms of this Charter.
50+
51+
e. The TSC may (1) establish work flow procedures for the submission, approval,
52+
and closure/archiving of projects, (2) set requirements for the promotion of
53+
Contributors to Maintainer status, as applicable, and (3) amend, adjust, refine
54+
and/or eliminate the roles of Contributors, and Maintainer, and create new roles,
55+
and publicly document any TSC roles, as it sees fit.
56+
57+
f. The TSC may elect a TSC Chair, who will preside over meetings of the TSC and
58+
will serve until their resignation or replacement by the TSC.
59+
60+
g. Responsibilities: The TSC will be responsible for all aspects of oversight relating
61+
to the Project, which may include:
62+
- coordinating the technical direction of the Project;
63+
- approving project or system proposals (including, but not limited to,
64+
incubation, deprecation, and changes to a sub-project's scope);
65+
- organizing sub-projects and removing sub-projects;
66+
- creating sub-committees or working groups to focus on cross-project
67+
technical issues and requirements;
68+
- appointing representatives to work with other open source or open
69+
standards communities;
70+
- establishing community norms, workflows, issuing releases, and security
71+
issue reporting policies;
72+
- approving and implementing policies and processes for contributing (to be
73+
published in the CONTRIBUTING file) and coordinating with the series
74+
manager of the Project (as provided for in the Series Agreement, the
75+
"Series Manager") to resolve matters or concerns that may arise as set
76+
forth in Section 7 of this Charter;
77+
- discussions, seeking consensus, and where necessary, voting on technical
78+
matters relating to the code base that affect multiple projects; and
79+
- coordinating any marketing, events, or communications regarding the
80+
Project.
81+
82+
### 3. TSC Voting
83+
84+
a. While the Project aims to operate as a consensus-based community, if any TSC
85+
decision requires a vote to move the Project forward, the voting members of the
86+
TSC will vote on a one vote per voting member basis.
87+
88+
b. Quorum for TSC meetings requires at least fifty percent of all voting members of
89+
the TSC to be present. The TSC may continue to meet if quorum is not met but
90+
will be prevented from making any decisions at the meeting.
91+
92+
c. Except as provided in Section 7.c. and 8.a, decisions by vote at a meeting require
93+
a majority vote of those in attendance, provided quorum is met. Decisions made
94+
by electronic vote without a meeting require a majority vote of all voting
95+
members of the TSC.
96+
97+
d. In the event a vote cannot be resolved by the TSC, any voting member of the TSC
98+
may refer the matter to the Series Manager for assistance in reaching a resolution.
99+
100+
### 4. Compliance with Policies
101+
102+
a. This Charter is subject to the Series Agreement for the Project and the Operating
103+
Agreement of LF Projects. Contributors will comply with the policies of LF
104+
Projects as may be adopted and amended by LF Projects, including, without
105+
limitation the policies listed at https://lfprojects.org/policies/.
106+
107+
b. The TSC may adopt a code of conduct ("CoC") for the Project, which is subject to
108+
approval by the Series Manager. In the event that a Project-specific CoC has not
109+
been approved, the LF Projects Code of Conduct listed at
110+
https://lfprojects.org/policies will apply for all Collaborators in the Project.
111+
112+
c. When amending or adopting any policy applicable to the Project, LF Projects will
113+
publish such policy, as to be amended or adopted, on its web site at least 30 days
114+
prior to such policy taking effect; provided, however, that in the case of any
115+
amendment of the Trademark Policy or Terms of Use of LF Projects, any such
116+
amendment is effective upon publication on LF Project's web site.
117+
118+
d. All Collaborators must allow open participation from any individual or
119+
organization meeting the requirements for contributing under this Charter and any
120+
policies adopted for all Collaborators by the TSC, regardless of competitive
121+
interests. Put another way, the Project community must not seek to exclude any
122+
participant based on any criteria, requirement, or reason other than those that are
123+
reasonable and applied on a non-discriminatory basis to all Collaborators in the
124+
Project community.
125+
126+
e. The Project will operate in a transparent, open, collaborative, and ethical manner
127+
at all times. The output of all Project discussions, proposals, timelines, decisions,
128+
and status should be made open and easily visible to all. Any potential violations
129+
of this requirement should be reported immediately to the Series Manager.
130+
131+
### 5. Community Assets
132+
133+
a. LF Projects (or an associated hosting entity) will hold title to all trade or service
134+
marks used by the Project ("Project Trademarks"), whether based on common law
135+
or registered rights. Project Trademarks will be transferred and assigned to LF
136+
Projects (or, where applicable, the associated hosting entity) to hold on behalf of
137+
the Project. Any use of any Project Trademarks by Collaborators in the Project
138+
will (a) either be (i) in a way that constitutes fair use or (ii) in accordance with the
139+
license from LF Projects to the Project and the applicable trademark usage
140+
guidelines and (b) inure to the benefit of LF Projects (or the associated hosting
141+
entity).
142+
143+
b. The Project will, as permitted and in accordance with such license from LF
144+
Projects, develop and own all Project GitHub and social media accounts, and
145+
domain name registrations created by the Project community.
146+
147+
c. Under no circumstances will LF Projects be expected or required to undertake any
148+
action on behalf of the Project that is inconsistent with the tax-exempt status or
149+
purpose, as applicable, of the Joint Development Foundation or LF Projects, LLC.
150+
151+
### 6. General Rules and Operations
152+
153+
a. The Project will:
154+
- engage in the work of the Project in a professional manner consistent with
155+
maintaining a cohesive community, while also maintaining the goodwill
156+
and esteem of LF Projects, Joint Development Foundation and other
157+
partner organizations in the open source community; and
158+
- respect the rights of all trademark owners, including any branding and
159+
trademark usage guidelines.
160+
161+
### 7. Intellectual Property Policy
162+
163+
a. Collaborators acknowledge that the copyright in all new contributions will be
164+
retained by the copyright holder as independent works of authorship and that no
165+
contributor or copyright holder will be required to assign copyrights to the
166+
Project.
167+
168+
b. Except as described in Section 7.c., all contributions to the Project are subject to
169+
the following:
170+
- All new inbound code contributions to the Project must be made using the
171+
MIT License (the "Project License").
172+
- All new inbound code contributions must also be accompanied by a
173+
Developer Certificate of Origin (http://developercertificate.org) sign-off in
174+
the source code system that is submitted through a TSC-approved
175+
contribution process which will bind the authorized contributor and, if not
176+
self-employed, their employer to the applicable license.
177+
- All outbound code will be made available under the Project License.
178+
- Documentation will be received and made available by the Project under
179+
the Project License.
180+
- The Project may seek to integrate and contribute back to other open source
181+
projects ("Upstream Projects"). In such cases, the Project will conform to
182+
all license requirements of the Upstream Projects, including dependencies,
183+
leveraged by the Project. Upstream Project code contributions not stored
184+
within the Project's main code repository will comply with the
185+
contribution process and license terms for the applicable Upstream
186+
Project.
187+
188+
c. The TSC may approve the use of an alternative license or licenses for inbound or
189+
outbound contributions on an exception basis. To request an exception, please
190+
describe the contribution, the alternative open source license(s), and the
191+
justification for using an alternative open source license for the Project. License
192+
exceptions must be approved by a two-thirds vote of the entire TSC.
193+
194+
d. Contributed files should contain license information, such as SPDX short form
195+
identifiers, indicating the open source license or licenses pertaining to the file.
196+
197+
### 8. Amendments
198+
199+
a. This charter may be amended by a two-thirds vote of the entire TSC and is subject
200+
to approval by LF Projects.

‎CONTRIBUTING.md‎

Lines changed: 15 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -8,6 +8,21 @@ When you submit a pull request, a CLA bot will automatically determine whether y
88
CLA and decorate the PR appropriately (e.g., status check, comment). Simply follow the instructions
99
provided by the bot. You will only need to do this once across all repos using our CLA.
1010

11+
### Developer Certificate of Origin (DCO)
12+
13+
In addition to the CLA, all commits must include a `Signed-off-by` trailer certifying that you
14+
wrote the code or have the right to submit it under the project's license. This is the
15+
[Developer Certificate of Origin](https://developercertificate.org) (DCO).
16+
17+
To sign off on a commit, use the `-s` flag:
18+
19+
```bash
20+
git commit -s -m "feat: add new policy engine"
21+
```
22+
23+
This adds a line like `Signed-off-by: Your Name <your.email@example.com>` to the commit message.
24+
A CI check will verify that all commits in a pull request include this trailer.
25+
1126
This project has adopted the [Microsoft Open Source Code of Conduct](https://opensource.microsoft.com/codeofconduct/).
1227
For more information see the [Code of Conduct FAQ](https://opensource.microsoft.com/codeofconduct/faq/) or
1328
contact [opencode@microsoft.com](mailto:opencode@microsoft.com) with any additional questions or comments.

‎GOVERNANCE.md‎

Lines changed: 5 additions & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -53,7 +53,11 @@ If maintainers cannot reach consensus, the project lead makes the final decision
5353

5454
## Releases
5555

56-
Releases follow [Semantic Versioning](https://semver.org/). Any maintainer can propose a release. The release process is automated via GitHub Actions with trusted publishing and SLSA build provenance.
56+
Releases follow [Semantic Versioning](https://semver.org/). Any maintainer can propose a release. The release process is documented in [RELEASE.md](RELEASE.md) and automated via GitHub Actions with trusted publishing and SLSA build provenance.
57+
58+
## Project Charter
59+
60+
The project operates under the [Technical Charter](CHARTER.md), which defines the TSC structure, IP policy, and amendment process for foundation governance.
5761

5862
## Code of Conduct
5963

‎RELEASE.md‎

Lines changed: 84 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,84 @@
1+
# Release Process
2+
3+
This document describes how the Agent Governance Toolkit ships releases across its multi-language SDK ecosystem.
4+
5+
## Versioning
6+
7+
All packages follow [Semantic Versioning 2.0.0](https://semver.org/):
8+
9+
- **MAJOR**: Breaking API changes (removed public classes, changed method signatures, incompatible config format changes)
10+
- **MINOR**: New features, new packages, new CLI commands (backward-compatible)
11+
- **PATCH**: Bug fixes, documentation corrections, dependency updates (backward-compatible)
12+
13+
Each SDK package is versioned independently. There is no monorepo-wide version number.
14+
15+
## Release Cadence
16+
17+
- **Regular releases**: As needed, typically 1-2 times per month
18+
- **Security patches**: Released within 48 hours of confirmed vulnerability
19+
- **Dependabot updates**: Merged continuously and included in the next release
20+
21+
## Supported Registries
22+
23+
| Ecosystem | Registry | Packages |
24+
|-----------|----------|----------|
25+
| Python | [PyPI](https://pypi.org/) | agent-os, agent-mesh, agent-compliance, agent-sre, agent-hypervisor, agent-runtime, agent-lightning, framework integrations (40+ packages) |
26+
| TypeScript | [npm](https://www.npmjs.com/) | @agent-governance/\* |
27+
| .NET | [NuGet](https://www.nuget.org/) | AgentGovernance.\* |
28+
| Rust | [crates.io](https://crates.io/) | agent-governance-\* |
29+
| Go | Go modules | github.com/microsoft/agent-governance-toolkit/agent-governance-go/\* |
30+
| Containers | [GitHub Container Registry](https://ghcr.io) | trust-engine, policy-server, audit-collector, api-gateway, registry, relay, governance-sidecar |
31+
32+
## How to Create a Release
33+
34+
### 1. Pre-release Checklist
35+
36+
- [ ] All CI checks pass on `main` (CI, CodeQL, Secret Scanning, Scorecard)
37+
- [ ] CHANGELOG.md is updated with notable changes
38+
- [ ] No open security advisories or critical bugs
39+
- [ ] Version numbers bumped in affected package manifests (`pyproject.toml`, `package.json`, `*.csproj`, `Cargo.toml`)
40+
41+
### 2. Create a GitHub Release
42+
43+
1. Go to [Releases](https://github.com/microsoft/agent-governance-toolkit/releases)
44+
2. Click "Draft a new release"
45+
3. Create a new tag following the pattern `v<MAJOR>.<MINOR>.<PATCH>` (e.g., `v0.8.0`)
46+
4. Use the auto-generated release notes as a starting point, then edit for clarity
47+
5. Mark as pre-release if appropriate (e.g., `v0.8.0-rc.1`)
48+
6. Publish the release
49+
50+
### 3. Automated Publishing
51+
52+
Publishing is triggered automatically when a GitHub Release is published:
53+
54+
- **Python packages**: The `publish.yml` workflow builds wheels with provenance attestation, then publishes to PyPI
55+
- **Container images**: The `publish-containers.yml` workflow builds and pushes multi-arch images to GHCR
56+
- **.NET packages**: Built and published to NuGet via the CI pipeline
57+
- **npm packages**: Built and published to npm via the CI pipeline
58+
59+
The `workflow_dispatch` trigger on `publish.yml` also allows publishing individual packages on demand.
60+
61+
### 4. Post-release
62+
63+
- Verify packages appear on their respective registries
64+
- Verify container images are pullable: `docker pull ghcr.io/microsoft/agent-governance-toolkit/<component>:<tag>`
65+
- Monitor for any regression reports in the first 24 hours
66+
67+
## Hotfix Process
68+
69+
For critical bugs or security issues in a released version:
70+
71+
1. Create a branch from the release tag: `git checkout -b hotfix/v0.8.1 v0.8.0`
72+
2. Apply the minimal fix with tests
73+
3. Follow the standard release process with a PATCH version bump
74+
4. Cherry-pick the fix back to `main` if not already there
75+
76+
## Supply Chain Security
77+
78+
Every release includes:
79+
80+
- **SBOM generation**: Software Bill of Materials for all packages (`sbom.yml`)
81+
- **Provenance attestation**: Build provenance via GitHub Attestations (Sigstore-based)
82+
- **Dependency review**: Automated review of dependency changes on every PR
83+
- **Secret scanning**: Pre-commit and CI scanning for leaked credentials
84+
- **OpenSSF Scorecard**: Weekly scoring with SARIF upload to GitHub Security tab

0 commit comments

Comments
 (0)