diff --git a/CHARTER.md b/CHARTER.md index 972d7589..2fab407d 100644 --- a/CHARTER.md +++ b/CHARTER.md @@ -1,130 +1,91 @@ -# darnit Technical Charter +# Technical Charter (the "Charter") for Darnit a Series of LF Projects, LLC -This Technical Charter (the "Charter") sets forth the responsibilities and procedures for technical contribution to, and oversight of, the darnit Project (the "Project"). +Adopted July 29, 2026 -## 1. Mission and Scope of the Project +This Charter sets forth the responsibilities and procedures for technical contribution to, and oversight of, the Darnit open source project, which has been established as Darnit a Series of LF Projects, LLC (the "Project"). LF Projects, LLC ("LF Projects") is a Delaware series limited liability company. All contributors (including committers, maintainers, and other technical positions) and other participants in the Project (collectively, "Collaborators") must comply with the terms of this Charter. -The mission of the darnit Project is to provide an extensible, AI-assisted compliance auditing framework that separates a vendor-neutral core from pluggable compliance implementations, so that open source projects can be audited against multiple security and governance baselines (e.g., the OpenSSF Baseline) without re-implementing the auditing engine. +## 1. Mission and Scope of the Project -The scope of the Project includes the framework, its first-party compliance implementations maintained in the same repository, and the tooling required to author, validate, and ship those implementations. +- **a.** The mission of the Project is to develop a framework for auditing software repositories against compliance and security baselines, collecting the project context those audits need, remediating gaps, and producing signed attestations of the result. +- **b.** The scope of the Project includes collaborative development under the Project License (as defined herein) supporting the mission, including documentation, testing, integration and the creation of other artifacts that aid the development, deployment, operation or adoption of the open source project. ## 2. Technical Steering Committee -### 2.1 Composition - -The Project is governed by a Technical Steering Committee (the "TSC"). The TSC operates as a single-tier body: there is one TSC for the entire Project, regardless of the number of packages or implementations the Project ships. - -The current voting members of the TSC are listed in [TECHNICAL-STEERING-COMMITTEE.md](./TECHNICAL-STEERING-COMMITTEE.md), with affiliation and industry-or-academia category disclosed for each member. - -The TSC has no fixed maximum size. Membership is not time-bounded -- members serve until resignation or removal under Section 2.5. - -### 2.2 Responsibilities - -The TSC is responsible for oversight of the Project, including: - -- Setting the Project's overall technical direction; -- Approving Project releases and security policy; -- Organizing, creating, and removing sub-projects or working groups; -- Appointing representatives to other communities and foundations on the Project's behalf; -- Establishing community norms, contribution workflows, and review processes; -- Voting on cross-Project technical matters; and -- Amending this Charter under Section 8. - -The TSC MAY delegate operational responsibilities -- such as day-to-day Pull Request review and release execution -- to maintainers under separate community documentation. Such delegation does not transfer the TSC's authority; the TSC remains the source of policy. - -### 2.3 Chair - -The TSC MAY elect a Chair from among its members. The Chair, if elected, presides over TSC discussions and serves as the Project's primary point of contact for foundation liaisons. The Chair serves until resignation or replacement by a subsequent TSC vote. The Project does not require a Chair to function; in the absence of a Chair, foundation liaison MAY be designated ad hoc by simple majority of the TSC for the matter at hand. - -### 2.4 Adding a Member - -A candidate for TSC membership is nominated by an existing TSC member. The nomination is recorded as a Pull Request that adds a row to [TECHNICAL-STEERING-COMMITTEE.md](./TECHNICAL-STEERING-COMMITTEE.md) populated with the candidate's name, affiliation, category, and GitHub handle. - -Existing TSC members vote on the nomination by approving or declining the Pull Request. The candidate is added to the TSC when a majority of the entire current TSC has approved the Pull Request, in accordance with Section 3 (TSC Voting). The merge commit is the canonical record of the decision. - -### 2.5 Removing a Member - -A TSC member MAY resign at any time by opening a Pull Request that removes their row from [TECHNICAL-STEERING-COMMITTEE.md](./TECHNICAL-STEERING-COMMITTEE.md). A resignation Pull Request does not require a vote; acknowledgment by another TSC member who merges the Pull Request suffices. - -A TSC member MAY be removed for cause -- including, but not limited to, inactivity or a serious violation of the Project's Code of Conduct -- by a vote of the *other* current TSC members. The member under review MUST NOT vote on their own removal. Removal for cause requires the approval of a majority of the other current TSC members, at the same level as ordinary TSC decisions. - -For the purposes of this Section, "inactivity" is not defined by a fixed numeric threshold (such as a specific number of months without contribution). Inactivity is a discretionary judgment by the remaining TSC members, initiated by a public GitHub Issue or Pull Request describing the basis for the proposed removal and resolved by the removal-for-cause threshold above. +- **a.** The Technical Steering Committee (the "TSC") will be responsible for all technical oversight of the open source Project. +- **b.** The TSC voting members are initially the Project's Maintainers. At the inception of the project, the Maintainers of the Project will be as set forth within the "CONTRIBUTING" file within the Project's code repository. The TSC may choose an alternative approach for determining the voting members of the TSC, and any such alternative approach will be documented in the CONTRIBUTING file. Any meetings of the Technical Steering Committee are intended to be open to the public, and can be conducted electronically, via teleconference, or in person. +- **c.** TSC projects generally will involve Contributors and Maintainers. The TSC may adopt or modify roles so long as the roles are documented in the CONTRIBUTING file. Unless otherwise documented: + - **i.** Contributors include anyone in the technical community that contributes code, documentation, or other technical artifacts to the Project; + - **ii.** Maintainers are Contributors who have earned the ability to modify ("commit") source code, documentation or other technical artifacts in a project's repository; and + - **iii.** A Contributor may become a Maintainer by a majority approval of the TSC. A Maintainer may be removed by a majority approval of the TSCs. +- **d.** Participation in the Project through becoming a Contributor and Maintainer is open to anyone so long as they abide by the terms of this Charter. +- **e.** The TSC may (1) establish work flow procedures for the submission, approval, and closure/archiving of projects, (2) set requirements for the promotion of Contributors to Maintainer status, as applicable, and (3) amend, adjust, refine and/or eliminate the roles of Contributors, and Maintainer, and create new roles, and publicly document any TSC roles, as it sees fit. +- **f.** The TSC may elect a TSC Chair, who will preside over meetings of the TSC and will serve until their resignation or replacement by the TSC. The TSC Chair, or any other TSC member so designated by the TSC, will serve as the primary communication contact between the Project and Open Source Security Foundation (OpenSSF), a directed fund of The Linux Foundation. +- **g.** Responsibilities: The TSC will be responsible for all aspects of oversight relating to the Project, which may include: + - **i.** coordinating the technical direction of the Project; + - **ii.** approving project or system proposals (including, but not limited to, incubation, deprecation, and changes to a sub-project's scope); + - **iii.** organizing sub-projects and removing sub-projects; + - **iv.** creating sub-committees or working groups to focus on cross-project technical issues and requirements; + - **v.** appointing representatives to work with other open source or open standards communities; + - **vi.** establishing community norms, workflows, issuing releases, and security issue reporting policies; + - **vii.** approving and implementing policies and processes for contributing (to be published in the CONTRIBUTING file) and coordinating with the series manager of the Project (as provided for in the Series Agreement, the "Series Manager") to resolve matters or concerns that may arise as set forth in Section 7 of this Charter; + - **viii.** discussions, seeking consensus, and where necessary, voting on technical matters relating to the code base that affect multiple projects; and + - **ix.** coordinating any marketing, events, or communications regarding the Project. ## 3. TSC Voting -The TSC's goal is to operate as a consensus-based community. When a decision cannot be reached by consensus, the TSC MAY decide the matter by a vote conducted in accordance with this Section. - -### 3.1 General Voting Rules - -- Each TSC member has one vote. -- Quorum for a vote is fifty percent (50%) of the current voting members of the TSC. -- For a meeting or synchronous vote in which a quorum is present, a decision is approved by a simple majority of the members voting in favor versus against; abstentions do not count toward the total. Ties fail. -- For decisions conducted electronically (e.g., on a Pull Request or GitHub Issue rather than in a meeting), a decision is approved when a majority of the entire TSC has voted in favor. -- Amendments to this Charter (Section 8) and exceptions to the Project's stated license policy (Section 7) require the approval of at least two-thirds (2/3) of the entire TSC, not merely of those voting. - -### 3.2 Recording Votes - -Votes on decisions that modify a tracked file -- the roster, this Charter, or any other policy file in the repository -- are recorded by GitHub Pull Request approvals on the affected file. The Pull Request review state and the resulting merge commit constitute the canonical vote record. - -Votes on decisions that do not modify a file (for example, approving a representative to an external community, or endorsing an external statement on the Project's behalf) are recorded in a GitHub Issue or Discussion thread. Each TSC member casts a vote as an explicit comment of `+1`, `-1`, or `+0` on a single comment line, so that the tally is unambiguous to a casual reader and parseable by tooling. Subsequent artifacts that depend on the decision MUST link to the recording Issue or Discussion. - -### 3.3 Deadlocks - -If the TSC is unable to reach quorum, or to resolve a deadlock through ordinary voting under Section 3.1, the matter MAY be escalated to the LF Projects Series Manager once the Project is hosted under The Linux Foundation. Until such time as the Project is formally hosted, deadlocks are resolved by good-faith re-discussion among the TSC members. +- **a.** While the Project aims to operate as a consensus-based community, if any TSC decision requires a vote to move the Project forward, the voting members of the TSC will vote on a one vote per voting member basis. +- **b.** Quorum for TSC meetings requires at least fifty percent of all voting members of the TSC to be present. The TSC may continue to meet if quorum is not met but will be prevented from making any decisions at the meeting. +- **c.** Except as provided in Section 7.c. and 8.a, decisions by vote at a meeting require a majority vote of those in attendance, provided quorum is met. Decisions made by electronic vote without a meeting require a majority vote of all voting members of the TSC. +- **d.** In the event a vote cannot be resolved by the TSC, any voting member of the TSC may refer the matter to the Series Manager for assistance in reaching a resolution. ## 4. Compliance with Policies -### 4.1 Code of Conduct - -The TSC and all Project contributors are subject to the Project's Code of Conduct, when adopted. Until the Project adopts a Code of Conduct of its own, the [LF Projects Code of Conduct](https://lfprojects.org/policies/code-of-conduct/) applies by default. - -### 4.2 Trademark and Antitrust - -The Project's name and any associated trademarks are the property of their respective holders. The TSC operates in compliance with applicable antitrust laws and avoids any discussion or action that would constitute unlawful coordination among competing organizations. - -### 4.3 Developer Certificate of Origin - -All contributions to the Project, including contributions to this Charter, MUST be signed off under the [Developer Certificate of Origin (DCO) version 1.1](https://developercertificate.org/). +- **a.** This Charter is subject to the Series Agreement for the Project and the Operating Agreement of LF Projects. Contributors will comply with the policies of LF Projects as may be adopted and amended by LF Projects, including, without limitation the policies listed at . +- **b.** The TSC may adopt a code of conduct ("CoC") for the Project, which is subject to approval by the Series Manager. In the event that a Project-specific CoC has not been approved, the LF Projects Code of Conduct listed at will apply for all Collaborators in the Project. +- **c.** When amending or adopting any policy applicable to the Project, LF Projects will publish such policy, as to be amended or adopted, on its web site at least 30 days prior to such policy taking effect; provided, however, that in the case of any amendment of the Trademark Policy or Terms of Use of LF Projects, any such amendment is effective upon publication on LF Project's web site. +- **d.** All Collaborators must allow open participation from any individual or organization meeting the requirements for contributing under this Charter and any policies adopted for all Collaborators by the TSC, regardless of competitive interests. Put another way, the Project community must not seek to exclude any participant based on any criteria, requirement, or reason other than those that are reasonable and applied on a non-discriminatory basis to all Collaborators in the Project community. +- **e.** The Project will operate in a transparent, open, collaborative, and ethical manner at all times. The output of all Project discussions, proposals, timelines, decisions, and status should be made open and easily visible to all. Any potential violations of this requirement should be reported immediately to the Series Manager. ## 5. Community Assets -The Project maintains the following community assets: - -- **Source repository**: -- **Issues**: -- **Discussions**: -- **Security reports**: see [SECURITY.md](./SECURITY.md) - -Additional assets -- for example, mailing lists, chat channels, or meeting venues -- MAY be added by TSC decision and announced through the Project's existing channels. +- **a.** LF Projects (or an associated hosting entity) will hold title to all trade or service marks used by the Project ("Project Trademarks"), whether based on common law or registered rights. Project Trademarks will be transferred and assigned to LF Projects (or, where applicable, the associated hosting entity) to hold on behalf of the Project. Any use of any Project Trademarks by Collaborators in the Project will (a) either be (i) in a way that constitutes fair use or (ii) in accordance with the license from LF Projects to the Project and the applicable trademark usage guidelines and (b) inure to the benefit of LF Projects (or the associated hosting entity). +- **b.** The Project will, as permitted and in accordance with such license from LF Projects, develop and own all Project GitHub and social media accounts, and domain name registrations created by the Project community. +- **c.** Under no circumstances will LF Projects be expected or required to undertake any action on behalf of the Project that is inconsistent with the tax-exempt status or purpose, as applicable, of the Joint Development Foundation or LF Projects, LLC. ## 6. General Rules and Operations -The TSC will operate in a transparent, open, collaborative, and ethical manner at all times. The TSC will not seek to exclude any participant on any criteria other than those that are reasonable and applied on a non-discriminatory basis. - -All TSC meetings, when held, are open to the public. Decisions reached outside of meetings (for example, on Pull Requests or in Issues per Section 3.2) are public by virtue of the venue. - -TSC members are expected to disclose any conflicts of interest material to a decision before the TSC and to recuse themselves from decisions where their impartiality would be reasonably questioned. +- **a.** The Project will: + - **i.** engage in the work of the Project in a professional manner consistent with maintaining a cohesive community, while also maintaining the goodwill and esteem of LF Projects, Joint Development Foundation and other partner organizations in the open source community; and + - **ii.** respect the rights of all trademark owners, including any branding and trademark usage guidelines. ## 7. Intellectual Property Policy -The Project ships the following classes of work under the following licenses: +- **a.** Collaborators acknowledge that the copyright in all new contributions will be retained by the copyright holder as independent works of authorship and that no contributor or copyright holder will be required to assign copyrights to the Project. +- **b.** Except as described in Section 7.c., all contributions to the Project are subject to the following: + - **i.** All new inbound code contributions to the Project must be made using Apache License, Version 2.0 available at (the "Project License"). + - **ii.** All new inbound code contributions must also be accompanied by a Developer Certificate of Origin () sign-off in the source code system that is submitted through a TSC-approved contribution process which will bind the authorized contributor and, if not self-employed, their employer to the applicable license; + - **iii.** All outbound code will be made available under the Project License. + - **iv.** Documentation will be received and made available by the Project under the Creative Commons Attribution 4.0 International License (available at ). + - **v.** The Project may seek to integrate and contribute back to other open source projects ("Upstream Projects"). In such cases, the Project will conform to all license requirements of the Upstream Projects, including dependencies, leveraged by the Project. Upstream Project code contributions not stored within the Project's main code repository will comply with the contribution process and license terms for the applicable Upstream Project. +- **c.** The TSC may approve the use of an alternative license or licenses for inbound or outbound contributions on an exception basis. To request an exception, please describe the contribution, the alternative open source license(s), and the justification for using an alternative open source license for the Project. License exceptions must be approved by a two-thirds vote of the entire TSC. +- **d.** Contributed files should contain license information, such as SPDX short form identifiers, indicating the open source license or licenses pertaining to the file. -- **Source code** is licensed under the Apache License, version 2.0. -- **Documentation**, including this Charter, is licensed under the Creative Commons Attribution 4.0 International License (CC-BY-4.0). -- **Data** distributed by the Project is licensed under the Community Data License Agreement -- Permissive, version 2.0 (CDLA-Permissive-2.0). +## 8. Amendments -Contributions to the Project MUST be made under terms compatible with these licenses. Exceptions to the license stack require a vote of the TSC under Section 3.1 with the two-thirds threshold. +- **a.** This charter may be amended by a two-thirds vote of the entire TSC and is subject to approval by LF Projects. -## 8. Amendments +--- -This Charter MAY be amended by a Pull Request modifying this document, approved by at least two-thirds (2/3) of the entire TSC in accordance with Section 3. + -A proposed amendment SHOULD be announced through the Project's existing communication channels and allow a reasonable comment window before merge, so that the community has the opportunity to weigh in. +## Note (non-normative) ---- +This file is a Markdown transcription of the Darnit Technical Charter as executed on July 29, 2026 (signed via DocuSign, envelope ID `9A390556-A200-8F31-81E5-734CBD4312D5`). The executed document controls in the event of any discrepancy with this transcription. -**Adopted**: 2026-06-17 +The Charter delegates certain items to other files in this repository: -**Provenance**: Adapted from the LF Projects Technical Charter, also used by the [GUAC](https://github.com/guacsec/governance) and [gittuf](https://github.com/gittuf/community) projects. +- **Roles, and the approach for determining the TSC's voting members** (Sections 2.b and 2.c) are documented in [GOVERNANCE.md](./GOVERNANCE.md#roles-and-responsibilities), linked from [CONTRIBUTING.md](./CONTRIBUTING.md#project-governance). The current voting members are listed in [TECHNICAL-STEERING-COMMITTEE.md](./TECHNICAL-STEERING-COMMITTEE.md). +- **Contribution policies and processes** (Section 2.g.vii) are documented in [CONTRIBUTING.md](./CONTRIBUTING.md). +- **Day-to-day operational practice** — how votes are recorded, PR review thresholds, the release process — is documented in [GOVERNANCE.md](./GOVERNANCE.md). That document is operational guidance, not governance authority; where it and this Charter differ, this Charter controls. -**License**: This document is licensed under the Creative Commons Attribution 4.0 International License (CC-BY-4.0). +This transcription supersedes the project-authored charter adopted 2026-06-17, which predated the Project's establishment as a series of LF Projects, LLC. diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md index 00487384..9d8ad83a 100644 --- a/CONTRIBUTING.md +++ b/CONTRIBUTING.md @@ -2,9 +2,37 @@ Thank you for your interest in contributing! This document provides our contribution policy. For detailed setup and workflow instructions, see the [Getting Started Guide](GETTING_STARTED.md). +## Project Governance + +The Project is governed under the [Technical Charter](CHARTER.md) for Darnit a Series of LF Projects, LLC, which is the binding authority. Where any other document differs from the Charter, the Charter controls. + +[GOVERNANCE.md](GOVERNANCE.md) documents the Project's [roles](GOVERNANCE.md#roles-and-responsibilities) and the approach for [determining the TSC's voting members](GOVERNANCE.md#technical-steering-committee-membership), along with day-to-day practice: PR review thresholds, the release process, and how TSC decisions are recorded. + +The current voting members of the TSC are listed in [TECHNICAL-STEERING-COMMITTEE.md](TECHNICAL-STEERING-COMMITTEE.md). + +## Developer Certificate of Origin + +All new inbound code contributions must be accompanied by a [Developer Certificate of Origin](https://developercertificate.org) sign-off (Charter 7.b.ii). Sign off by committing with: + +```bash +git commit -s +``` + +This appends a `Signed-off-by:` line to the commit message. Pull requests without a sign-off on every commit will not be merged. + +## Licensing of Contributions + +- **Code**, inbound and outbound, is licensed under the Apache License, Version 2.0 — the Project License (Charter 7.b.i, 7.b.iii). +- **Documentation** is made available under the Creative Commons Attribution 4.0 International License (Charter 7.b.iv). +- **Copyright** in each contribution is retained by its copyright holder. No contributor is required to assign copyright to the Project, and there is no CLA (Charter 7.a). +- Contributed files should carry license information, such as an SPDX short-form identifier (Charter 7.d). +- Any other license, inbound or outbound, requires a TSC exception approved by a two-thirds vote of the entire TSC (Charter 7.c). + +When the Project integrates with or contributes back to upstream projects, it conforms to those projects' license requirements and contribution processes (Charter 7.b.v). + ## Code of Conduct -Please read and follow our Code of Conduct to maintain a welcoming environment for all contributors. +All Collaborators are expected to uphold a welcoming, harassment-free environment. The TSC may adopt a Project-specific Code of Conduct, which is subject to approval by the LF Projects Series Manager. Until such a Code of Conduct is approved, the [LF Projects Code of Conduct](https://lfprojects.org/policies) applies to all Collaborators in the Project (Charter 4.b). ## Getting Started diff --git a/GOVERNANCE.md b/GOVERNANCE.md index c00524ba..9aa03c46 100644 --- a/GOVERNANCE.md +++ b/GOVERNANCE.md @@ -1,17 +1,17 @@ # Governance -The darnit Project is governed by a Technical Steering Committee (TSC). The binding rules for membership, voting, and amendments live in the Project's [Charter](./CHARTER.md); the current voting members of the TSC are listed in [TECHNICAL-STEERING-COMMITTEE.md](./TECHNICAL-STEERING-COMMITTEE.md). +The darnit Project has been established as Darnit a Series of LF Projects, LLC, and is governed by a Technical Steering Committee (TSC) under the Project's [Technical Charter](./CHARTER.md). The Charter is the binding authority on oversight, voting, and amendments. The current voting members of the TSC are listed in [TECHNICAL-STEERING-COMMITTEE.md](./TECHNICAL-STEERING-COMMITTEE.md). -This document describes the operational layer below the Charter: how the Project is organized, what roles contributors fill, and how routine activities (PR review, releases) are run on a day-to-day basis. The Charter is the authority on governance decisions; this document is operational guidance and may be revised by maintainer consensus without a TSC vote. +This document describes the Project's roles, how the TSC's voting membership is determined, and the operational layer below the Charter: how the Project is organized and how routine activities (PR review, releases, recording decisions) are run day to day. Operational practice may be revised by maintainer consensus without a TSC vote. Nothing here overrides the Charter — where this document and the Charter differ, the Charter controls. ## Project Structure Darnit is organized as a monorepo using `uv` workspace: -| Package | Purpose | Maintainer | -|---------|---------|------------| -| `darnit` | Core framework (models, plugin system, sieve) | Core team | -| `darnit-baseline` | OpenSSF Baseline implementation | Core team | +| Package | Purpose | Maintainer | +|-------------------|-----------------------------------------------|------------| +| `darnit` | Core framework (models, plugin system, sieve) | Core team | +| `darnit-baseline` | OpenSSF Baseline implementation | Core team | Future plugins can be developed as external packages following the plugin architecture. @@ -19,36 +19,42 @@ Future plugins can be developed as external packages following the plugin archit The TSC sets policy. The roles below operate under that policy and are responsible for day-to-day execution. TSC members are typically also maintainers, but the two roles are distinct: TSC authority comes from the [Charter](./CHARTER.md); maintainer authority comes from commit access granted by the TSC. -### Maintainers +- **Contributor** — anyone in the technical community who contributes code, documentation, or other technical artifacts to the Project. Participation is open to anyone who abides by the terms of the Charter (Charter 2.d). +- **Maintainer** — a Contributor who has earned the ability to commit to the Project's repository. Maintainers review and merge pull requests, manage releases and versioning, respond to security vulnerabilities, enforce the Code of Conduct, and set day-to-day technical direction within the policy set by the TSC. A Contributor becomes a Maintainer by a majority approval of the TSC, and a Maintainer may be removed by a majority approval of the TSC (Charter 2.c.iii). +- **Baseline Implementer** — a specialization of the Contributor role for those who add or modify OSPS controls, implement sieve verification passes, or write remediation functions. The role is descriptive and carries no additional commit rights. -Maintainers have write access to the repository and are responsible for: +## Technical Steering Committee Membership -- Reviewing and merging pull requests -- Managing releases and versioning -- Responding to security vulnerabilities -- Day-to-day technical direction within policy set by the TSC -- Enforcing the Code of Conduct +Charter 2.b makes the TSC's voting members the Project's Maintainers by default and permits the TSC to adopt an alternative approach. The Project uses the following approach. -### Contributors +TSC voting membership is a standing roster, maintained in [TECHNICAL-STEERING-COMMITTEE.md](./TECHNICAL-STEERING-COMMITTEE.md), and is distinct from commit access: a person may be a Maintainer without being a TSC voting member, and vice versa. Each roster row records the member's name, affiliation, industry-or-academia category, and GitHub handle. Membership is not time-bounded and the TSC has no fixed maximum size — members serve until resignation or removal. -Contributors are community members who: +**Adding a member.** A candidate is nominated by an existing TSC voting member, as a pull request that adds a row to the roster. Existing voting members vote by approving or declining that pull request. Because this is an electronic vote taken without a meeting, approval requires a majority of all voting members of the TSC (Charter 3.c). The merge commit is the canonical record of the decision. -- Submit pull requests with bug fixes or features -- Report issues and bugs -- Improve documentation -- Participate in discussions +**Resignation.** A voting member may resign at any time by opening a pull request that removes their own row from the roster. A resignation does not require a vote; acknowledgment by another TSC member who merges the pull request is sufficient. -### Baseline Implementers +**Removal for cause.** Removal for cause — including, but not limited to, inactivity or a serious violation of the Code of Conduct — is initiated by a public GitHub Issue or pull request describing the basis for the proposed removal, and is decided by a vote of the *other* voting members. The member under review does not vote on their own removal and is not counted toward the total; approval requires a majority of the remaining voting members. For this purpose, "inactivity" is not defined by a fixed numeric threshold such as a number of months without contribution; it is a discretionary judgment of the remaining voting members. -A specialized contributor role for those who: +## Recording TSC Decisions -- Add or modify OSPS controls -- Implement sieve verification adapters -- Write remediation functions +The Charter sets the voting thresholds (Section 3). It does not prescribe a recording mechanism; the Project uses the following convention so that any decision can be audited after the fact. + +- **Decisions that modify a tracked file** — the roster, the Charter, or any other policy file in the repository — are recorded as GitHub pull request approvals on the affected file. The pull request review state and the resulting merge commit constitute the canonical vote record. +- **Decisions that do not modify a file** — for example, appointing a representative to an external community, or endorsing an external statement on the Project's behalf — are recorded in a GitHub Issue or Discussion thread. Each TSC member casts a vote as an explicit comment of `+1`, `-1`, or `+0` on a single comment line, so that the tally is unambiguous to a casual reader and parseable by tooling. Subsequent artifacts that depend on the decision should link to the recording Issue or Discussion. + +Decisions reached outside of meetings are public by virtue of the venue. Any meetings of the TSC are intended to be open to the public and may be held electronically, by teleconference, or in person (Charter 2.b). + +## Conflicts of Interest + +TSC members are expected to disclose any conflict of interest material to a decision before the TSC, and to recuse themselves from decisions where their impartiality would reasonably be questioned. This is a community norm rather than a Charter requirement; the Charter's transparency obligations (Section 4.e) and the LF Projects policies at — including those governing antitrust compliance — apply in all cases. + +## Deadlocks + +If the TSC cannot reach quorum or resolve a deadlock through ordinary voting, any voting member may refer the matter to the LF Projects Series Manager for assistance in reaching a resolution (Charter 3.d). Good-faith re-discussion among TSC members is the expected first step, but it is not a precondition for referral. ## Day-to-Day PR Process -The following thresholds apply to routine PR activity. Changes to *governance itself* -- this document, the [Charter](./CHARTER.md), or the [TSC roster](./TECHNICAL-STEERING-COMMITTEE.md) -- follow the TSC voting rules in the Charter instead. +The following thresholds apply to routine PR activity. Changes to *governance itself* — this document, the [Charter](./CHARTER.md), or the [TSC roster](./TECHNICAL-STEERING-COMMITTEE.md) — follow the TSC voting rules in the Charter instead. ### Minor Changes @@ -80,12 +86,19 @@ Releases follow [Semantic Versioning](https://semver.org/): - MINOR: New features (backwards compatible) - PATCH: Bug fixes (backwards compatible) +## Licensing + +The Project's license stack is set by the Charter, Section 7, and is summarized for contributors in [CONTRIBUTING.md](./CONTRIBUTING.md#licensing-of-contributions): code under Apache-2.0, documentation under CC-BY-4.0. The Charter does not establish a license for distributed data sets; should the Project ship data, the TSC would need to approve a data license (for example, CDLA-Permissive-2.0) as a license exception under Charter 7.c, by a two-thirds vote of the entire TSC. + ## Code of Conduct -All participants are expected to uphold a welcoming, harassment-free environment. Be respectful, constructive, and inclusive in all interactions. The Project intends to adopt a project-specific Code of Conduct; until then, the LF Projects Code of Conduct applies per the [Charter](./CHARTER.md), Section 4.1. +All participants are expected to uphold a welcoming, harassment-free environment. Be respectful, constructive, and inclusive in all interactions. The TSC may adopt a Project-specific Code of Conduct, subject to approval by the LF Projects Series Manager; until then the [LF Projects Code of Conduct](https://lfprojects.org/policies) applies to all Collaborators, per the [Charter](./CHARTER.md), Section 4.b. -## Contact +## Community Assets +- **Source repository**: - **Issues**: [GitHub Issues](https://github.com/kusari-oss/darnit/issues) - **Discussions**: [GitHub Discussions](https://github.com/kusari-oss/darnit/discussions) - **Security**: See [SECURITY.md](SECURITY.md) for vulnerability reporting + +The Project develops and owns its GitHub and social media accounts and domain registrations under license from LF Projects. Trade and service marks used by the Project are held by LF Projects (or an associated hosting entity) on the Project's behalf, per Charter Section 5. Additional assets — mailing lists, chat channels, meeting venues — may be added by TSC decision and announced through the Project's existing channels. diff --git a/README.md b/README.md index 67667715..3b9edb6a 100644 --- a/README.md +++ b/README.md @@ -438,7 +438,7 @@ For contributor setup and development workflow, see the [Getting Started Guide]( ## Governance -The darnit Project is governed by a Technical Steering Committee (TSC). See the [Charter](CHARTER.md) for the binding governance rules, the [TSC roster](TECHNICAL-STEERING-COMMITTEE.md) for current voting members, and [GOVERNANCE.md](GOVERNANCE.md) for operational guidance (roles, release process, contact). +The darnit Project has been established as Darnit a Series of LF Projects, LLC, and is governed by a Technical Steering Committee (TSC). See the [Charter](CHARTER.md) for the binding governance rules, the [TSC roster](TECHNICAL-STEERING-COMMITTEE.md) for current voting members, and [GOVERNANCE.md](GOVERNANCE.md) for roles, TSC membership process, and operational guidance (PR process, releases, contact). ## License diff --git a/TECHNICAL-STEERING-COMMITTEE.md b/TECHNICAL-STEERING-COMMITTEE.md index 93c5f827..741ad260 100644 --- a/TECHNICAL-STEERING-COMMITTEE.md +++ b/TECHNICAL-STEERING-COMMITTEE.md @@ -1,6 +1,6 @@ # Technical Steering Committee - + The current voting members of the darnit Technical Steering Committee are: @@ -11,4 +11,4 @@ The current voting members of the darnit Technical Steering Committee are: | Stephen Augustus | Bloomberg | industry | @justaugustus | member | | Adolfo Garcia Veytia | Carabiner | industry | @puerco | member | -For the rules that govern membership, voting, and amendments, see [CHARTER.md](./CHARTER.md). +Voting, oversight, and amendment rules are set by the Project's [Charter](./CHARTER.md). The process for adding and removing voting members of this roster is documented in [GOVERNANCE.md](./GOVERNANCE.md#technical-steering-committee-membership).