The CHIPS Alliance TAC will be responsible for all technical oversight of the open source project.
The CHIPS Alliance TAC is governed by tha CHIPS Alliance Charter, which establishes the Council and its basic principles and procedures. The charter is designed to provide the TAC the freedom to govern itself in an efficient manner. This document establishes TAC policies and procedures.
In addition, as provided under the Charter, CHIPS Alliance has adopted a Code of Conduct that applies to all CHIPS Alliance activities and spaces.
Per the Charter, the voting members of the TAC are composed of one representative appointed by each Platinum Member and one representative appointed by the technical oversight body (e.g., a technical steering committee) of each Graduated Project.
The current members of the CHIPS Alliance TAC are:
Name | GitHub | Affiliation | Role / Projec |
---|---|---|---|
Stephano Cetola (Chair) | cetola | Intel | Platinum Voting Rep |
Michael Gielda | mgielda | Antmicro | Platinum Voting Rep |
Danny Hua | Futurewei | Platinum Voting Rep | |
Prabhu Jayanna | AMD | Platinum Voting Rep | |
Bryan Kelly | bryankel | Microsoft | Platinum Voting Rep |
Mirjana Videnovic-Misic | Infineon | Platinum Voting Rep | |
Aaron Cunningham | Platinum Voting Rep |
In addition to Graduated projects which delegate one member each to the TAC (see the table above), there are also Sandbox projects which are on the path to joining although are not fully/formally incorporated into CHIPS Alliance yet.
See Sandbox projects for a list of projects currently in Sandbox.
Projects are organized into Workgroups for the purpose of e.g. organizing meetings which aggregate related projects and topical areas.
To see an up-to-date list, visit the Workgroups section of the CHIPS website.
This repo documents the day-to-day policies and procedures of the CHIPS Alliance TAC. It provides a framework for self-governance, and addresses topics too granular for the Charter.
This repository has the following structure:
- drafts - drafts of our internal documents
- meetings - our meeting agendas and minutes
- projects - list of projects in different lifecycle stages
- proposals - policy proposals under consideration
Here are some other links to help you find your way:
- An introduction to our collaboration tools
- Our policies and procedures
- The current voting members of the TAC (please note anyone can participate in our meetings as a non-voting attendee)
- Projects and Workgroups of the CHIPS Alliance
Finally, if you need help, please reach out and ask.
The CHIPS Alliance TAC can be reached at technical-discuss. This mailing list is open for anyone to join, and all are welcome to participate in general technical discussions about the project.
The CHIPS Alliance maintains a Slack Workspace for communication and collaboration, which is open for anyone to join. Once you join Slack, you can participate in any public channels.
The CHIPS Alliance maintains a public calendar for TAC meetings. These meetings are open for anyone to join.
CHIPS Alliance uses Zoom for meetings. Because we work in a highly distributed environment and will rarely meet in person, participants are encouraged to use video as appropriate.
The TAC is granted oversight over all CHIPS Alliance technical projects and workgroups. In CHIPS Alliance, similar technical projects are organized into workgroups. Each project is represented within the workgroup's internal governance structure.
Each project must have a mission statement (template) which describes its purpose and governance. Changes to mission statements must be reviewed and approved by the TAC.
Each project is categorized according to a project lifecycle process, managed by the TAC. Projects and workgroups will have different maturity levels, and the lifecycle process seeks to balance their needs and expectations with available resources.
- Sandbox: Optional pre-membership stage to help a project prepare for the TAC's consideration. Sandbox projects are not yet part of CHIPS Alliance, but may be allocated TAC resources to help with the process.
- Graduated: A project which has been accepted by the TAC, assigned to a workgroup, met the graduation requirements, and demonstrated sustainable momentum.
- Archived: A former Graduated project which has been archived for strategic or practical reasons.
- Active: Contains at least one Graduated project, or a majority of the TAC has voted to create the workgroup to collaborate on future projects.
- Archived: No longer contains any Graduated projects.
The TAC has sole authority over a project's lifecycle stage and workgroup, including the decision to accept or reject project proposals. It also may create or consolidate workgroups at its discretion.
Projects join CHIPS Alliance by following the Project Lifecycle Process.
All Graduated projects and Active workgroups can make use of the CHIPS Alliance collaboration resourcs, including:
- Access to the shared Zoom account
- Meetings listed on the public CHIPS Alliance calendar
- Mailing lists on lists.chipsalliance.org
- Credential storage and sharing through LastPass
- GitHub repos and teams in the
chipsalliance
GitHub org
The CHIPS Alliance exists within a rich ecosystem of interrelated projects. While the TAC's first objective is to support the success of CHIPS Alliance projects, it also acknowledges the critical strategic roles played by external open source projects. Collectively, we refer to these projects as "The CHIPS Alliance Commons".
Although these projects remain outside of the CHIPS Alliance organization and its policies, the TAC may recognize these projects in various ways. For example, the TAC can maintain a list of strategic open source projects, or make an effort to include their participants and maintainers in relevant TAC discussions.
The CHIPS Alliance TAC is grateful to the broader open source ecosystem, and is looking forward to healthy collaboration within and external to the Alliance.
The CHIPS Alliance TAC is governed by the Charter. The Charter provides a foundational structure for the TAC while granting the TAC a high degree of freedom when determining how to implement the policies of CHIPS Alliance.
The following policies and procedures have been adopted by the TAC.
All CHIPS Alliance projects must have a process for receiving security vulnerability reports. If a project does not have its own process, the default policy is to send a detailed disclosure to security@lists.chipsalliance.org. This is a confidential mailing list, and the TAC chair and a small group of trusted individuals will review and act upon the report as appropriate.
The TAC will use voting to make decisions when required by the charter, or when consensus cannot be reached.
Votes may be initiated by any TAC voting member or CHIPS Alliance staff. Except when required otherwise by the charter, votes are decided by a simple majority of all eligible voting members. Unless withdrawn, votes remain open until they meet their acceptance or rejection threshold.
Email votes are strongly preferred because they provide a clear history, although alternate voting systems may be used if they better serve the need of the situation (e.g., OpaVote, CIVS, etc.). Voting outcomes should be recorded in the minutes of the next TAC meeting. It is sufficient to publish the outcome; it is not necesssary to publish how each member voted unless there is unanimous agreement among voting members.
Template for initiating an email vote:
To: technical-internal@lists.chipsalliance.org
Subject: Please vote: [summary of vote]
[2-4 sentences describing the topic of the vote, concluding with the actual vote]
Voting members, please vote by replying "Approve", "Reject", or "Abstain".
When a vote is related to a PR or issue, apply the labels vote-required, vote-in-progress, vote-passed, or vote-rejected as appropriate.
Pull requests that do not change the charter or governance of the TAC can be merged into this repository provided the following conditions have been met:
- There are no outstanding objections
- There are two approvals by TAC members
- The PR has been open for at least 72 hours
Pull requests that change governance of the TAC (excluding the charter) must be open for at least 14 days, unless consensus is reached in a meeting with quorum of voting members, or an email vote has been passed in favor of the PR, as signified by the vote-passed label (see Voting procedures above).
Pull requests that change the charter of the TAC must meet any requirements in the charter.
If consensus cannot be reached, a pull request may still be landed after a vote by the Voting members to override outstanding objections.
Special exception is made for pull requests seeking to make any of the following changes to this repository:
- Meeting minutes.
- Doc fixes.
Charter changes cannot be fast-tracked.
To propose fast-tracking a pull request, apply the fast-track label. Then add a comment that TAC members may upvote. If someone disagrees with the fast-tracking request, remove the label. Do not fast-track the pull request in that case.
The pull request may be fast-tracked if two TAC members approve the fast-tracking request. To land, the pull request itself still needs two TAC member approvals.
TAC members may request fast-tracking of pull requests they did not author. In that case only, the request itself is also one fast-track approval. Upvote the comment anyway to avoid any doubt.
Trivial PRs that update factual situations can be merged immediately. When opening the PR, please note that the change is trivial and that it will be merged directly. Examples include:
- Errata fixes.
- Editorial changes.
- Updates to team lists.
If a TAC member does not believe the change was trivial, it can be reverted and proposed through the normal PR process.
The CHIPS Alliance IP policy is contained in the Charter, and it applies to all CHIPS Alliance projects unless an exception is explicitly approved by the TAC.
CHIPS Alliance follows the community best practice of not requiring contributors to add a notice to each file.
Projects are encouraged (but not required) to adopt the practice of including SPDX short form identifiers in their files.
CHIPS Alliance projects should use one of the following notices on their websites, as appropriate:
Copyright CHIPS Alliance Project a Series of LF Projects, LLC.<br>For web site terms of use, trademark policy and general project policies please see <a href="https://lfprojects.org">https://lfprojects.org</a>.
--- **Copyright CHIPS Alliance Project a Series of LF Projects, LLC.** For web site terms of use, trademark policy and general project policies please see [https://lfprojects.org](https://lfprojects.org).
CHIPS Alliance projects are welcomed and encouraged to host their repositories within the CHIPS Alliance organization.
Repositories may be transferred into or created under the CHIPS Alliance organization so long as:
- They adhere to the CHIPS Alliance IP policy.
- They are directly operated by a CHIPS Alliance project.
- The TAC achieves rough consensus about adding the repository.
Sometimes projects will rely upon other external repositories (e.g., tooling or dependencies). While it is a best practice to work upstream whenever possible, there may be situations where a downstream fork is required. In this situation, rough consensus on the TAC is sufficient to create a new fork.
Finally, non-technical repositories may be needed for admin purposes, and may be created by staff from time to time.
Because CHIPS Alliance contains multiple projects, please use a consistent and descriptive naming convention that will group all related repositories together when sorted alphabetically. For example:
- project1
- project1-website
- project1-admin
- project2
- project2-ci
- project2-mentorship
- project2-website
- ...
The best time to rename a repo is when it is transferred into the CHIPS Alliance organization. GitHub ensures that all links to the prior repository are automatically redirected to the new location, and links to the repository are preserved when a repository is renamed. This means that git clone
, git fetch
, git pull
, and git push
will function without requiring any changes from existing users.
All CHIPS Alliance repositories containing technical information must be set to public.
To help ensure effective repo management, each project should manage a GitHub team of its committers within the CHIPS Alliance org. That team should be added to any repository to which they should have commit rights.
The TAC may choose to move repositories to an archived state, at its own discretion. Most often this will occur if there are concerns about a repository being unmaintained, but may also happen if two efforts are consolidating and one codebase is being kept for archival purposes.
Membership in the CHIPS Alliance helps to fund collaborative infrastructure used by our projects.
For help with project infrastructure please contact operations@chipsalliance.org. Examples of ways the Linux Foundation can help include:
- Adding and removing members from GitHub teams
- Creating and archiving repositories
- Creating and managing mailing lists on the lists.chipsalliance.org domain
- Managing DNS (for projects which host their nameserver with the LF)
- Creating and managing email aliases (for projects which host their nameserver with the LF)
CHIPS Alliance welcomes new members, and we would be happy to help answer any questions you may have. To learn more about membership, please visit https://chipsalliance.org/join or email membership@chipsalliance.org.
CHIPS Alliance members can get help with anything related to their membership by emailing operations@chipsalliance.org.
For help with press and media inquiries, or to let the CHIPS Alliance marketing committee know about something exciting happening in your project (releases, major milestones, ecosystem events, etc.) please email pr@chipsalliance.org.
For any other topics which aren't covered above, please email operations@chipsalliance.org.
Copyright CHIPS Alliance Project a Series of LF Projects, LLC.
For web site terms of use, trademark policy and general project policies please see https://lfprojects.org.