Skip to content

Commit

Permalink
Initial revisions of project lifecycle (#159)
Browse files Browse the repository at this point in the history 
* Initial revisions of project lifecycle

* updated check project syntax to only check one template

* Moved project.yml files into their own directory, added new yml fields into all project files.
  • Loading branch information
@bensternthal
bensternthal authored Apr 26, 2024
1 parent 55a62d4 commit 09ed44f
Show file tree
Hide file tree
Showing 20 changed files with 158 additions and 148 deletions.
22 changes: 6 additions & 16 deletions .github/check_projects_syntax.py
View file
Original file line number Diff line number Diff line change
Expand Up @@ -3,17 +3,12 @@
import yaml
import sys

sandbox = {}
graduated = {}
application_template = {}

with open("projects/templates/sandbox.yml") as f:
sandbox = yaml.safe_load(f)

with open("projects/templates/graduated.yml") as f:
graduated = yaml.safe_load(f)

# first try to load as sandbox and check status
with open("projects/templates/project-application-template.yml") as f:
application_template = yaml.safe_load(f)

# try to load check status
def fail(msg):
print(msg)
sys.exit(1)
Expand Down Expand Up @@ -41,10 +36,5 @@ def check(filename, data, template):
# status needs to be either sandbox, graduated or archived
if data["status"] not in ["sandbox", "graduated", "archived"]:
fail(f"{filename}: invalid status")



if data["status"] == "sandbox":
check(filename, data, sandbox)
elif data["status"] == "graduated":
check(filename, data, graduated)
else:
check(filename, data, application_template)
2 changes: 1 addition & 1 deletion .github/workflows/projects-check.yml
View file
Original file line number Diff line number Diff line change
Expand Up @@ -12,4 +12,4 @@ jobs:
- uses: actions/setup-python@v4
- name: Check
run: |
.github/check_projects_syntax.py projects/*yml
.github/check_projects_syntax.py projects/project-data-files/*yml
46 changes: 2 additions & 44 deletions projects/PROJECT_APPLICATION_TEMPLATE.md
View file
Original file line number Diff line number Diff line change
@@ -1,48 +1,6 @@
# Project application: (your project name here)

To apply to become a CHIPS Alliance project, copy this template to the relevant subfolder of [this directory](https://github.com/chipsalliance/tsc/tree/main/projects) and open a PR against the TSC repo and add the `tsc-meeting` label. Projects applying for Sandbox status should add the `sandbox-application` label. Projects applying for Graduated status should add the `graduated-application` label.

For simplicity, the CHIPS Alliance TSC uses a progressive application for Sandbox and Graduated status. The Graduated application includes all of the Sandbox questions. Project candidate should complete as much of the application as possible, as this will help determine which level is most appropriate.

When applying to move from Sandbox » Graduated, please modify the existing application and update relevant fields (such as number of committers) so that the file's history is preserved.
To apply to become a CHIPS Alliance project, copy this template to the relevant subfolder of [this directory](./templates/project-application-template.yml) and open a PR against the TAC repo and add the `tac-meeting` label.

If a specific field is not applicable to your project (e.g. your project does not have dedicated social media accounts), please use N/A to signify this.

## Application

### Sandbox application

* Project name:
* Project repo(s):
* Brief summary of the project:
* Project's open source license:
* Link to issue tracker:
* Link to website:
* Links to social media accounts:
* Who uses this project, and at what scale:
* Why does the project want to join CHIPS Alliance:
* Primary contact from the project during the Sandbox application process:
* Name:
* Email:
* GitHub handle:
* Role within the project:

*Projects applying for Sandbox status may stop here.*

### Graduation application

* Total number of active committers:
* Brief description of release methodology and mechanics:
* Link to draft mission statement:
* Link to logo in .svg format
* Confirmation that the project adopts the [CHIPS Alliance Code of Conduct](https://lfprojects.org/policies/code-of-conduct/) upon acceptance:
* Confirmation that the project will adopt the [CHIPS Alliance IP policy](https://technical-charter.chipsalliance.org) upon acceptance:
* Confirmation that the project will add CHIPS Alliance header or footer text and links to its websites upon acceptance:
* Confirmation that the contributor will assign or transfer any common law or registered trademark rights, project accounts (e.g. GitHub), and project domain names to the Linux Foundation upon acceptance:
* Link to documented process for reporting security vulnerabilities:
* **For specifications** Confirmation there is at least one public reference implementation:
* Primary contact from the project during the Graduation process:
* Name:
* Email:
* GitHub handle:
* Role within the project:
For any questions or comments on this process please email operations@chipsalliance.org
149 changes: 90 additions & 59 deletions projects/README.md
View file
Original file line number Diff line number Diff line change
Expand Up @@ -2,89 +2,142 @@

## Introduction

This governance policy sets forth the proposal process for projects to be accepted into CHIPS Alliance. The process is the same for existing projects which seek to move into CHIPS Alliance and new projects being formed within CHIPS Alliance.
This governance policy describes how an open source project can formally join the CHIPS Alliance. The process is the same for existing projects which seek to move into CHIPS Alliance and new projects being formed within CHIPS Alliance.

There are three project categories:

* [Sandbox](#sandbox): Optional pre-membership stage to help a project prepare for the TSC's consideration.
* [Graduated](#graduated): A project which has met the graduation requirements and demonstrated sustainable momentum.
* [Archived](#archived): A former Graduated project which has been archived for strategic or practical reasons.

## Project Proposal Process

## Sandbox
The acceptance process is a three-stage process: a technical review with the Technical Advisory Committee (TAC), legal submission to LF, and a vote by the Governing Board.

Sandbox projects are projects which plan to join the CHIPS Alliance, but have not yet met the prerequisites to formally join. Projects may optionally make use of the Sandbox stage in order to request TSC time and attention in preparing for their application to become a part of CHIPS Alliance.
```mermaid
flowchart TD
A(Technical Review) -->
C{TAC Vote}
C -->|Approved| D[Project is\n'Sandbox']
C -->|Declined| A
D --> E(Complete Legal Review)
D --> F(Complete Onboarding Checklist)
E --> G
F --> G{Board Vote}
G -->|Approved| H[Project is\n 'Graduated']
```

The Sandbox stage is optional, and Sandbox projects are not yet considered part of CHIPS Alliance.
### Project Acceptance Process

### Benefits of becoming a Sandbox project:
#### Technical Review

* The TSC will prioritize requests for help meeting the requirements of Graduated projects.
* The TSC will monitor the project to ensure progress is being made.
Projects are required to present their proposal at a TAC meeting. This proposal should cover all the items in the [Project Application Template](./templates/project-application-template.yml).

### Expectations of Sandbox projects:
The TAC may ask for changes to bring the project into better alignment with the CHIPS Alliance (adding a governance document to a repository or adopting a Code of Conduct, for example). The project will need to make these changes in order to progress further.

Projects are accepted or progress from category to category via a two-thirds majority vote of TAC representatives.

The TAC will determine the appropriate initial stage for the project. The project can apply for a different stage via the review process.

Once a project passes Technical Review, the TAC will inform the Governing Board of the submission proposal.

#### Legal Submission

After a successful TAC vote, the project is ready for a legal review. The legal review is initiated by the project filling out [this form](https://docs.google.com/forms/d/e/1FAIpQLSeO1bDGHUP-ZpCo1uynm94YOxZlek6RhCH7o3FnX1lZSXXfSQ/viewform?fbzx=4351560609072672295) and working with the CHIPS operations team. The LF project onboarding team will create a draft Technical Charter, a draft Project Contribution Agreement (if needed), and a draft Series Agreement.

As noted in clause 10 of the CHIPS Alliance Charter, CHIPS requires that any trademarks be transferred to, or be available for use by, LF Projects, LLC. Even if no trademarks exist, the current CP policy is that projects be submitted to LF Projects, LLC.

#### Governing Board Vote

Once the Technical Review and Legal Submission steps are complete, the Governing Board will review the project proposal and the proposed Technical Charter. If there are legal questions raised, the Governing Board may refer the matter to the Legal Committee for review. This review may occur in parallel with Technical Review in some cases.

Once any such legal questions have been addressed, the Governing Board will vote at its next available meeting.

Upon acceptance by the board, the project's approved Technical Charter must be included in the project's main repository. This document can be in whatever format is most appropriate for the project, as long as the content is the same.


## Project Category Definitions & Expectations

### Sandbox

Sandbox projects are projects which plan to join the CHIPS Alliance, but have not yet met the prerequisites to formally join.

#### Benefits of becoming a Sandbox project:

* The TAC will prioritize requests for help meeting the requirements of Graduated projects.
* The TAC will monitor the project to ensure progress is being made.


#### Expectations of Sandbox projects:

* Because Sandbox projects are not yet a part of CHIPS Alliance, it is their responsibility to manage the Graduation application process.
* Projects may remain in the Sandbox stage so long as they are making reasonable progress toward applying for Graduated status.
* Projects which cease to make progress or are on a trajectory which would lead to rejection may be removed by majority vote of the TSC.
* Projects which cease to make progress or are on a trajectory which would lead to rejection may be removed by majority vote of the TAC.
* Projects may reapply for Sandbox status if previously removed for any reason.

### Requirements to become a Sandbox project:

1. The project must complete an application in the form of a `.yml` file in this directory, and open a PR against the TSC repo with the `tsc-meeting` and `sandbox-application` labels.
1. The project must join a TSC meeting to present its proposal.
1. TSC must approve the application as a Sandbox project by majority vote.
#### Requirements to become a Sandbox project:

1. The project must complete an application in the form of a `.yml` file in this directory, and open a PR against the TAC repo with the `tac-meeting` and `sandbox-application` labels.
1. The project must join a TAC meeting to present its proposal.
1. TAC must approve the application as a Sandbox project by majority vote.

When a Sandbox proposal is accepted, the PR may be landed.

## Graduated
### Graduated

Graduated projects are projects which have applied and been formally accepted as CHIPS Alliance projects by the TSC. Graduated projects are assigned to a Workgroup, and are officially a part of CHIPS Alliance.
Graduated projects are projects which have applied and been formally accepted as CHIPS Alliance projects by the TAC. Graduated projects are officially a part of CHIPS Alliance.

However, achieving Graduated status requires more than maturity and adoption. The TSC is run by and for the technical community, and it can only function with involvement from project leaders. Representatives from Graduated projects are expected to take an active role in TSC and CHIPS Alliance processes. For example, participating in TSC meetings, volunteering as a program committee member for events, participating in mentoring initiatives, and helping Sandbox projects prepare for their Graduated status application.
However, achieving Graduated status requires more than maturity and adoption. The TAC is run by and for the technical community, and it can only function with involvement from project leaders. Representatives from Graduated projects are expected to take an active role in TAC and CHIPS Alliance processes. For example, participating in TAC meetings, volunteering as a program committee member for events,chairing a CHIPS workgroup, participating in mentoring initiatives, and helping Sandbox projects prepare for their Graduated status application.

### Benefits of becoming a Graduated project

#### Benefits of becoming a Graduated project

* Project can put forward a voting representative to the CHIPS TAC
* Project may claim a formal association with CHIPS Alliance
* Project is placed within a workgroup, and project members can be considered for workgroup leadership and TSC voting member status.
* Project gains access to CHIPS Alliance resources, including events, the ability to request financial resources, and mentorship.

### Expectations of Graduated projects

#### Expectations of Graduated projects

* Projects must adhere to open source best practices.
* Project must proactively and positively promote CHIPS Alliance.
* Project must participate actively in its workgroup meetings and governance, and any other positions held within CHIPS Alliance. At least one member from the Project should join TSC meetings, whether a voting member or non-voting attendee.
* Project will participate in reviews by the TSC to ensure it remains a fit for CHIPS Alliance.
* Project must participate actively in its workgroup meetings and governance, and any other positions held within CHIPS Alliance. At least one member from the Project should join TAC meetings, whether a voting member or non-voting attendee.
* Project will participate in reviews by the TAC to ensure it remains a fit for CHIPS Alliance.
* Project must actively work to ensure a healthy number of committers.
* Project must demonstrate ongoing and sustained involvement from contributors.
* The project must ensure that committers are diversified across organizations.
* The project must avoid actions that will lead to an unsustainable development community.
* The project must lead by example on adherence to core project policies, such as the Code of Conduct.
* The project must exemplify the values of CHIPS Alliance and be committed to diversity and inclusion.

### Requirements to become a Graduated project

1. The project must actively work with the TSC as it does due diligence to determine fit.
#### Requirements to become a Graduated project

1. The project must actively work with the TAC as it does due diligence to determine fit.
1. The project must have a substantial ongoing flow of commits and merged contributions.
1. The project must use a clear versioning scheme.
1. The project must have a [draft mission statement](./MISSION_STATEMENT_TEMPLATE.md) prepared for TSC approval.
1. The project must internally pre-approve the Code of Conduct, IP Policy, and [header/footer for websites](https://github.com/chipsalliance/tsc/blob/main/README.md#website-footers) so that they are in effect upon project acceptance by the TSC.
1. The project must be prepared to transfer any registered trademarks and domain names to the Linux Foundation upon acceptance.
1. The project must complete an `.yml` application in this directory (perhaps by just extending its existing Sandbox application), set the status in the `.yml` file to "graduated" and open a PR against the TSC repo with the `tsc-meeting` and `graduation-application` labels.
1. The project must join a TSC meeting to present its proposal.
1. The TSC must approve the Graduated status application and the project's mission statement by majority vote.
1. The project must have a [draft mission statement](./MISSION_STATEMENT_TEMPLATE.md) prepared for TAC approval.
1. The project must internally pre-approve the Code of Conduct, IP Policy, and [header/footer for websites](https://github.com/chipsalliance/tsc/blob/main/README.md#website-footers) so that they are in effect upon project acceptance by the TAC.
1. The project must complete an `.yml` application in this directory, set the status in the `.yml` file to "graduated" and open a PR against the TAC repo with the `tac-meeting` and `graduation-application` labels.
1. The project must join a TAC meeting to present its proposal.
1. The TAC must approve the Graduated status application and the project's mission statement by majority vote.
1. The project must have a documented process for reporting security vulnerabilities, or accept the [default CHIPS Alliance security reporting process](https://github.com/chipsalliance/tsc/blob/main/README.md#reporting-security-vulnerabilities).
1. The project must receive a supermajority vote from TSC voting members.
1. The project must receive a supermajority vote from TAC voting members.
1. The project must work with CHIPs To Sign Technical Charter / Participation Agreement / Assign Trademark
1. The project must adopt and enforce the CLA
2. The project must be approved by a vote of the CHIPS Alliance Governing Board
3. The project must add ‘thelinuxfoundation’ GitHub user as an owner to all repositories

When a Graduated proposal is accepted, the PR may be landed.

## Archived
### Archived

Archived projects are projects which no longer have sufficient momentum to justify an active state in CHIPS Alliance. By archiving a project, CHIPS Alliance is indicating that downstream users should not expect any updates, including security fixes or backports.

The decision to move a project to Archived is not taken lightly by the TSC, and each situation will be unique. However, reasons which could lead to an Archived state may include:
The decision to move a project to Archived is not taken lightly by the TAC, and each situation will be unique. However, reasons which could lead to an Archived state may include:

* The project has requested the TSC move it to Archived state.
* The project has requested the TAC move it to Archived state.
* There are no more active committers.
* There are no more active contributors.
* Another project has encompassed its functionality.
Expand All @@ -98,30 +151,8 @@ The decision to move a project to Archived is not taken lightly by the TSC, and

### Requirements to become an Archived project

1. A representative from the project or a TSC voting member should change their projects' `.yml` status to "archived" and open a PR against the TSC repo with the `tsc-meeting` and `archival-application` labels.
1. A representative from the project or a TSC voting member must join a TSC meeting to present the proposal.
1. The archival proposal must receive a supermajority vote from TSC voting members.

When an Archival proposal is accepted, the PR may be landed.

## FAQs

#### Is the Sandbox a required stage?

No, but it can help a project get organized and make the Graduation proposal more straightforward.

#### Can a project skip Sandbox?

Some mature projects may seek to enter CHIPS Alliance and already meet all of the criteria for a Graduated project. Because the Graduated application is a superset of the Sandbox application, a project which applies for Graduated status is effectively applying for both. If for any reason the TSC does not confirm Graduated status, it can vote on Sandbox status with the same application.

#### Does the TSC have final discretion over a project's status?

Yes, the TSC always makes the final decision whether a project's application is accepted, deferred, or rejected.

#### Can a project be removed from any stage?

Yes, any project may be converted to Archived state or removed from CHIPS Alliance through a supermajority vote by disinterested voting members.

#### Can a project move from Archived to an active state?
1. A representative from the project or a TAC voting member should change their projects' `.yml` status to "archived" and open a PR against the TACs repo with the `tac-meeting` and `archival-application` labels.
1. A representative from the project or a TAC voting member must join a TAC meeting to present the proposal.
1. The archival proposal must receive a supermajority vote from TAC voting members.

Yes, an Archived project can be reactivated if a contributors and maintainers are willing to commit to ongoing development. In this case, the project may reapply for consideration as a Sandbox project.
When an Archival proposal is accepted, the PR may be landed.
Loading

0 comments on commit 09ed44f

Please sign in to comment.