diff --git a/COMMITTERS.csv b/COMMITTERS.csv deleted file mode 100644 index 03bc0e1..0000000 --- a/COMMITTERS.csv +++ /dev/null @@ -1,4 +0,0 @@ -Name, Email, GitHub ID -Josh Bainbridge, josh.bainbridge@gmail.com, @joshbainbridge -Jose Esteve, jose.esteve@framestore.com, @joesfer -Chris Haldane, chris.haldane@framestore.com, @chaldane diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md index 874985d..6818188 100644 --- a/CONTRIBUTING.md +++ b/CONTRIBUTING.md @@ -11,6 +11,16 @@ For a description of the roles and responsibilities of the various members of th If you just need help or have a question, refer to [SUPPORT.md](SUPPORT.md). +## Project committers + +The current committers of the project are listed below. Committers review and approve contributions, and form the initial voting membership of the Technical Steering Committee as described in the [Technical Charter](tsc/charter.md). To request committer status, follow the process in [GOVERNANCE.md](GOVERNANCE.md#committer). + +| Name | GitHub | Email | +| --- | --- | --- | +| Josh Bainbridge | [@joshbainbridge](https://github.com/joshbainbridge) | josh.bainbridge@gmail.com | +| Jose Esteve | [@joesfer](https://github.com/joesfer) | jose.esteve@framestore.com | +| Chris Haldane | [@chaldane](https://github.com/chaldane) | chris.haldane@framestore.com | + ## How to contribute a bug fix or change diff --git a/GOVERNANCE.md b/GOVERNANCE.md index dc5e2ea..ac79a3b 100644 --- a/GOVERNANCE.md +++ b/GOVERNANCE.md @@ -21,7 +21,7 @@ The committer role enables the contributor to commit code directly to the reposi ### Process for becoming a committer * Show your experience with the codebase through contributions and engagement on the community channels. -* Request to become a committer. To do this, create a new pull request that adds your name and details to the COMMITTERS.csv file and request existing committers to approve. +* Request to become a committer. To do this, create a new pull request that adds your name and details to the [committers list](CONTRIBUTING.md#project-committers) and request existing committers to approve. * After the majority of committers approve you, merge in the PR. Be sure to tag the whomever is managing the GitHub permissions to update the committers team in GitHub. ### Committer responsibilities @@ -36,9 +36,20 @@ The committer role enables the contributor to commit code directly to the reposi If a committer is no longer interested or cannot perform the committer duties listed above, they should volunteer to be moved to emeritus status. In extreme cases this can also occur by a vote of the committers per the voting process below. -## Lead +## Technical Steering Committee (TSC) -The project committers will elect a lead (and optionally a co-lead) which will be the primary point of contact for the project and representative to the TAC upon becoming an Active stage project. The lead(s) will be responsible for the overall project health and direction, coordination of activities, and working with other projects and committees as needed for the continued growth of the project. +The Technical Steering Committee (TSC) is responsible for all technical oversight of the project. The full responsibilities and procedures of the TSC are defined in the project's [Technical Charter](tsc/charter.md), which is the binding governing document for the project. + +The current TSC members are: + +* Josh Bainbridge (Chair) +* Lorna Dumba +* Nathan Walster +* Mark Hills + +### TSC Chair + +The TSC may elect a TSC Chair (and optionally a co-chair) who will be the primary point of contact for the project and its representative to the Academy Software Foundation's Technical Advisory Council (TAC). The TSC Chair is responsible for the overall project health and direction, coordination of activities, presiding over TSC meetings, and working with other projects and committees as needed for the continued growth of the project. # Release process @@ -46,12 +57,11 @@ Project releases will occur on a scheduled basis as agreed to by the committers. # Conflict resolution and voting -In general, we prefer that technical issues and committer membership are amicably worked out between the persons involved. If a dispute cannot be decided independently, the committers can be called in to decide an issue. If the committers themselves cannot decide an issue, the issue will be resolved by voting. The voting process is a simple majority in which each committer receives one vote. +In general, we prefer that technical issues and committer membership are amicably worked out between the persons involved. If a dispute cannot be decided independently, the TSC can be called in to decide an issue. If the TSC itself cannot decide an issue, the issue will be resolved by voting. The voting process is a simple majority in which each TSC voting member receives one vote, as described in the [Technical Charter](tsc/charter.md). # Communication -This project, just like all of open source, is a global community. In addition -to the [Code of Conduct](CODE_OF_CONDUCT.md), this project will: +This project, just like all of open source, is a global community. In addition to the [Code of Conduct](CODE_OF_CONDUCT.md), this project will: * Keep all communication on open channels (mailing list, forums, chat). * Be respectful of time and language differences between community members (such as scheduling meetings, email/issue responsiveness, etc). diff --git a/README.md b/README.md index 29f8de7..9ccd62a 100644 --- a/README.md +++ b/README.md @@ -1150,7 +1150,7 @@ The directories are: - `scripts`: Utility scripts for command line and CI usage. - `src/tests`: Unit and statistical hypothesis testing. - `src/tools`: Project tooling for analysis and offline optimisation. -- `tsc`: Meeting notes and project process documentation. +- `tsc`: Project charter and process documentation. ### Dependencies @@ -1437,6 +1437,17 @@ OpenQMC doesn't solve your problem, one of these might be a better option: - [Pbrt](https://github.com/mmp/pbrt-v4) is a seminal resource on all things rendering, but is written for educational purposes. +## Leadership + +OpenQMC is an Academy Software Foundation project, governed by a Technical +Steering Committee (TSC). The leadership roster, project roles, and decision +making process are described in [GOVERNANCE.md](GOVERNANCE.md), with the binding +details set out in the project's [Technical Charter](tsc/charter.md). + +TSC meetings are open to the community. Meeting notes, minutes and the schedule +are maintained on the project's Confluence space: [OpenQMC on +Confluence](https://lf-aswf.atlassian.net/wiki/spaces/OpenQMC/overview). + ## Contributing All contributions to the project are welcome. For guidance on how to contribute diff --git a/SECURITY.md b/SECURITY.md index 24e1bf2..cf0145a 100644 --- a/SECURITY.md +++ b/SECURITY.md @@ -4,7 +4,7 @@ This file describes the project security policy. ## Reporting a Vulnerability -If you think you've found a potential vulnerability in OpenQMC, please report it by emailing josh.bainbridge@gmail.com. Only Technical Steering Committee members and Academy Software Foundation project management have access to these messages. Include detailed steps to reproduce the issue, and any other information that could aid an investigation. Our policy is to respond to vulnerability reports within 14 days, address critical security vulnerabilities rapidly and post patches as quickly as possible. +If you think you've found a potential vulnerability in OpenQMC, please report it by emailing openqmc-tsc-private@lists.aswf.io. Only Technical Steering Committee members and Academy Software Foundation project management have access to these messages. Include detailed steps to reproduce the issue, and any other information that could aid an investigation. Our policy is to respond to vulnerability reports within 14 days, address critical security vulnerabilities rapidly and post patches as quickly as possible. ## Known Vulnerabilities diff --git a/SUPPORT.md b/SUPPORT.md index e28010f..98af0a8 100644 --- a/SUPPORT.md +++ b/SUPPORT.md @@ -16,7 +16,7 @@ OpenQMC manages bug and enhancement using its [issue](https://github.com/Academy ## How to report a security vulnerability -If you think you've found a potential vulnerability in OpenQMC, please email josh.bainbridge@gmail.com to responsibly disclose it. +If you think you've found a potential vulnerability in OpenQMC, please email openqmc-tsc-private@lists.aswf.io to responsibly disclose it. ## Contributing a fix diff --git a/mkdocs.yml b/mkdocs.yml index 1f24662..e586e25 100644 --- a/mkdocs.yml +++ b/mkdocs.yml @@ -17,6 +17,7 @@ nav: - Increasing Sampling Rate: splitting.md - Releases: releases.md - Go to API Reference: https://academysoftwarefoundation.github.io/openqmc/api-reference + - Go to Confluence: https://lf-aswf.atlassian.net/wiki/spaces/OpenQMC/overview theme: name: material custom_dir: mkdocs diff --git a/tsc/meetings/2023-06-06.md b/tsc/meetings/2023-06-06.md deleted file mode 100644 index b307e0c..0000000 --- a/tsc/meetings/2023-06-06.md +++ /dev/null @@ -1,40 +0,0 @@ -## Voting member attendance - -* [ ] Josh Bainbridge Framestore -* [ ] Lorna Dumba Framestore - -# Agenda - -- General - -- Discuss the role of the TSC - -- Discussed the pitch plan - -# Action Items (AIs) - - 02 Jun 2023 Lorna Dumba to pass on note to John M (Linux Foundation) and ask for Git handle - 02 Jun 2023 Lorna Dumba to email TAC to request OpenQMC on Weds Jul 12th and get confirmation - 02 Jun 2023 Lorna Dumba to remind TAC pich date then pre-presentation, Thurs June 15th, to Michael and Manne - Note: Any work pre-marketing material such as render image, narrative and Josh profile, Nathan team story and further mediums will also happen post the pitch - 02 Jun 2023 Lorna Dumba to check the sequence of events post pitching with John M (Linux Foundation) - 09 Jun 2023 Lorna Dumba to create a hub that includes agenda item doc for sharing with others through Confluence - 02 Jun 2023 Lorna Dumba to share ASWF OS Beers of a Feather via email to Technology - -# Notes - -- General -This is a version of the TSC meeting note template and is only partly referencing the notes per kick off. -Future meetings will adjust as needed to meet the structure as is relevant. - -- Discuss the role of the TSC -Suggested to have an external representative to join the TSC. John M (Linux Foundation) or Mark Hills (ex Framestore / CleanFeed) -Note: This should only happen post pitch to ASWF/acceptance to sandbox. - - -- Discussed the pitch plan -Josh suggested part of the pitch to include achieveable outcomes to allow to progress to the next stage of the project level (e.g. project is adopted by a number of projects etc). Establish this at the beginning and dicussion in the session. - -# Chat - -Will add these notes to git. diff --git a/tsc/meetings/kickoff_meeting_agenda.md b/tsc/meetings/kickoff_meeting_agenda.md deleted file mode 100644 index 0a69048..0000000 --- a/tsc/meetings/kickoff_meeting_agenda.md +++ /dev/null @@ -1,26 +0,0 @@ -# OpenQMC TSC Meeting - Month DD, Year - -## Voting member attendance - -* [ ] Person A - Chairperson, Affiliation A -* [ ] Person B, Affiliation B -* [ ] Person C, Affiliation C -* [ ] Person D, Affiliation D - -# Agenda - -- Welcome/Introductions -- Discuss the role of the TSC -- TSC Chairperson - - Discuss role - - Nominations/election -- Infrastructure transition plan - - Review [Infrastructure Inventory Checklist](../intake_inventory.md) -- Determine TSC meeting cadence - -# Action Items (AIs) - -# Notes - -# Chat - diff --git a/tsc/meetings/yyyy-mm-dd.md b/tsc/meetings/yyyy-mm-dd.md deleted file mode 100644 index c419391..0000000 --- a/tsc/meetings/yyyy-mm-dd.md +++ /dev/null @@ -1,28 +0,0 @@ -# AWSF Project TSC Meeting - Month DD, Year - -## Voting member attendance - -* [ ] Person A - Chairperson, Affiliation A -* [ ] Person B, Affiliation B -* [ ] Person C, Affiliation C -* [ ] Person D, Affiliation D - -# Agenda - -- First Item - -- Second Item - - First Sub Item - - Second Sub Item - - Third Sub Item - -- Third Item - -- Next meeting - -# Action Items (AIs) - -# Notes - -# Chat - diff --git a/tsc/process/codereview.md b/tsc/process/codereview.md index 221bf19..8cd697b 100644 --- a/tsc/process/codereview.md +++ b/tsc/process/codereview.md @@ -12,16 +12,15 @@ The Technical Steering Committee have write-access to the OpenQMC repository and * No direct commits to the main (or any other protected) branch, every code change should be a pull request * Any member of the community can provide feedback on any pull request (and is encouraged to do so) * A CODEOWNERS file introduced to the root of the repo to configure ownership (global, per-directory and/or per-file) - this will automatically request pull request reviews from the relevant maintainers (https://help.github.com/articles/about-codeowners/) -* Minimum of one non-author TSC member approval on every pull request before merging +* Minimum of one TSC member or committer approval on every pull request before merging * Non fast-forward merges must be used (ie the merge must not be rebased onto main) -* Azure Pipelines CI and DCO status checks must strictly pass before merging, other (TBD) checks should loosely pass (https://help.github.com/articles/types-of-required-status-checks) +* CI and DCO status checks must strictly pass before merging (https://help.github.com/articles/types-of-required-status-checks) ## Best Practices * Prefer all requested reviewers to approve before merging * Merging a pull request should be the responsibility of the author if they are a TSC member * Any TSC member can merge a pull request authored by a non-TSC member, but with a preferred minimum of two approvals from TSC members (including themself) -* Re-writing the branch history by rebasing a pull request branch just before a merge is discouraged, unless it significantly improves the overall history (such as any broken commits on the review branch that might make reverting or bisecting more difficult) * Prefer pull requests to be open for a minimum of 72 hours before merging in order to gather any feedback * Aim for all pull requests to be responded to by one of the TSC members within a minimum of two weeks with either explanation of non-acceptance, request for changes or merge * TSC meetings should regularly review and discuss any outstanding pull requests diff --git a/tsc/process/deprecation.md b/tsc/process/deprecation.md deleted file mode 100644 index 7a58864..0000000 --- a/tsc/process/deprecation.md +++ /dev/null @@ -1,13 +0,0 @@ - - - -# Deprecation Strategy for OpenQMC - -This should discuss the following topics: - -- How many major versions of OpenQMC are supported -- How this interact with versions of the [VFX Reference Platform](http://www.vfxplatform.com/) -- How this interact with versions of commercial DCC applications that use OpenQMC -- How far back does API or ABI compatibility extend -- There should be an explicit policy on fixing severe security issues in versions that are no longer supported. -- Any other relevant information useful to OpenQMC users when making decision about the lifecycle of the project. diff --git a/tsc/process/release.md b/tsc/process/release.md deleted file mode 100644 index bf4e990..0000000 --- a/tsc/process/release.md +++ /dev/null @@ -1,20 +0,0 @@ - - - -# Release Process for OpenQMC - -_This release process is the one adopted by the [OpenVDB project](https://github.com/AcademySoftwareFoundation/openvdb), it is provided as an example of a well structured release process._ - -The following assumes that the current OpenQMC library version number is 6.0.0 and the new version number is 6.1.0. Adjust for the actual version numbers as appropriate. - -- [ ] Open a ticketing system ticket "Release OpenQMC 6.1.0" ticket with "OpenQMC_6.1.0" as the Fix Version. -- [ ] Update `CHANGES` with release notes. (A project may want to adopt automated tools for release notes management / generation). -- [ ] Open a pull request to merge the above changes into `OpenQMC/main`. Associate the pull request with the ticketing system ticket created earlier, and verify that the CI build runs successfully. -- [ ] Draft a new GitHub release. Title it "OpenQMC 6.1.0" and tag it as `v6.1.0`. -- [ ] Update front page of project web site with a news item announcing the release, and delete the oldest news item. Open that page in a browser and check that the website renders correctly and that there are no broken links. -- [ ] Build the auto-generated documentation with the appropriate build system targets and replace the contents of the project website documentation directory with the output. -- [ ] Open a pull request to merge the above changes into the website repository. Associate the pull request with the ticketing system ticket created earlier. -- [ ] Post a release announcement to the OpenQMC public announcement mailing list. -- [ ] In preparation for the next release, change the correct #define in the project's base version include file. Unless it is known that the next release will include API- or ABI-breaking changes, increment only the patch number to begin with (in this case, from 6.1.0 to 6.1.1). Update any references to the project version number in the documentation source files, and add a "Version 6.1.1 - In development" section to the `CHANGES` release notes file. Open a pull request to merge these changes into `OpenQMC/main`. -- [ ] Add a "OpenQMC_6.1.1" version to the ticketing system. - diff --git a/tsc/process/security.md b/tsc/process/security.md deleted file mode 100644 index aacecde..0000000 --- a/tsc/process/security.md +++ /dev/null @@ -1,35 +0,0 @@ - - - -# Security and OpenQMC - -General discussion of OpenQMC security posture. - -## Reporting - -_Document process for external parties to report security issues. A private mailing list reaching only the TSC members should be provided to allow confidential reporting when needed, such as to avoid public disclosure before a vulnerability can be addressed in a release._ - -## Vulnerabilty Handling - -_Document the process and timeframe that the project is committed to following to address security issues. There should be an explicit policy on fixing severe security issues in versions that are no longer supported._ - -## Outstanding Security Issues - -_A list of current, unaddressed security issues, with an assessment of severity and a timeframe for resolution. Publicly disclosed [CVEs](https://cve.mitre.org/) should be listed here._ - -## Addressed Security Issues - -_A historical list of addressed security vulnerabilities, in particular any public CVEs, with corresponding release information._ - -## File Format Expectations - -_Assuming OpenQMC defines a data file format, a discussion of what a user should expect happens when operating on a valid or invalid OpenQMC data file._ - -## Runtime Library Expectations - -_Assuming OpenQMC defines a callable API / library, a discussion of how the library is expected to behave, how it handles erroneous inputs / does input sanitization, how it returns errors._ - -## Data and Metadata Implications - -_A discussion of issues relating to the data model implemented by the project such as correctness, confidentiality, potential misuse..._ - diff --git a/tsc/project_intake.md b/tsc/project_intake.md index 19c97cc..89e2975 100644 --- a/tsc/project_intake.md +++ b/tsc/project_intake.md @@ -3,44 +3,44 @@ This is a checklist for TSC's to review as part of the intake process. The TSC should review this entire list during the kickoff meeting. For anything outstanding, create an [issue](../issues) to track and link to it in the list - Existing Project Governance - - [ ] A [LICENSE](../LICENSE) file in every code repository, with the license chosen an OSI-approved license. - - [ ] Any third-party components/dependencies included are listed along with thier licenses ( [THIRD_PARTY.md](../THIRD_PARTY.md) ) - - [ ] A [README.md](../README.md) file welcoming new community members to the project and explaining why the project is useful and how to get started. - - [ ] A [CONTRIBUTING.md](../CONTRIBUTING.md) file explaining to other developers and your community of users how to contribute to the project. The file should explain what types of contributions are needed and how the process works, along with how to disclose security issues responsibly ( may also point to a [SECURITY.md](../SECURITY.md) file ). - - [ ] A [CODEOWNERS](../CODEOWNERS) or [COMMITTERS](../COMMITERS.csv) file to define individuals or teams that are responsible for code in a repository; document current project owners and current and emeritus committers. - - [ ] A [CODE_OF_CONDUCT.md](../CODE_OF_CONDUCT.md) file that sets the ground rules for participants’ behavior associated and helps to facilitate a friendly, welcoming environment. By default, projects should leverage the Linux Foundation Code of Conduct unless an alternate Code of Conduct was previously approved. - - [ ] A [RELEASE.md](process/release.md) file that provides documentation on the release methodology, cadence, criteria, etc. - - [ ] A [GOVERNANCE.md](../GOVERNANCE.md) file that documents the project’s technical governance. - - [ ] A [SUPPORT.md](../SUPPORT.md) file to let users and developers know about ways to get help with your project. + - [x] A [LICENSE](../LICENSE) file in every code repository, with the license chosen an OSI-approved license. + - [x] Any third-party components/dependencies included are listed along with thier licenses ( [THIRD_PARTY.md](../THIRD_PARTY.md) ) + - [x] A [README.md](../README.md) file welcoming new community members to the project and explaining why the project is useful and how to get started. + - [x] A [CONTRIBUTING.md](../CONTRIBUTING.md) file explaining to other developers and your community of users how to contribute to the project. The file should explain what types of contributions are needed and how the process works, along with how to disclose security issues responsibly ( may also point to a [SECURITY.md](../SECURITY.md) file ). + - [x] A [CODEOWNERS](../CODEOWNERS) file and a [committers list](../CONTRIBUTING.md#project-committers) to define individuals or teams that are responsible for code in a repository; document current project owners and current and emeritus committers. + - [x] A [CODE_OF_CONDUCT.md](../CODE_OF_CONDUCT.md) file that sets the ground rules for participants’ behavior associated and helps to facilitate a friendly, welcoming environment. By default, projects should leverage the Linux Foundation Code of Conduct unless an alternate Code of Conduct was previously approved. + - [x] A [RELEASE.md](../RELEASE.md) file that provides documentation on the release methodology, cadence, criteria, etc. + - [x] A [GOVERNANCE.md](../GOVERNANCE.md) file that documents the project’s technical governance. + - [x] A [SUPPORT.md](../SUPPORT.md) file to let users and developers know about ways to get help with your project. - Infrastructure/Assets - - [ ] License scan completed and no issues found - - [ ] Code repository imported to ASWF GitHub organization or ownership of current GitHub organization given to `thelinuxfoundation` user - - [ ] Developer Certificate of Origin past commit signoff done and DCO Probot enabled. - - [ ] Issue/feature tracker established (JIRA, GitHub issues) - - [ ] Mailing lists ( one of ) - - [ ] Setup new lists ( -discuss@ and -tsc@ ) on [ASWF groups.io](https://lists.aswf.io) ( create [issue on foundation repo](https://github.com/AcademySoftwareFoundation/foundation/issues/new) to setup ) + - [x] License scan completed and no issues found + - [x] Code repository imported to ASWF GitHub organization or ownership of current GitHub organization given to `thelinuxfoundation` user + - [x] Developer Certificate of Origin past commit signoff done and DCO Probot enabled. + - [x] Issue/feature tracker established (JIRA, GitHub issues) + - [x] Mailing lists ( one of ) + - [x] Setup new lists ( -discuss@ and -tsc@ ) on [ASWF groups.io](https://lists.aswf.io) ( create [issue on foundation repo](https://github.com/AcademySoftwareFoundation/foundation/issues/new) to setup ) - [ ] Move to [ASWF groups.io](https://lists.aswf.io) ( create [issue on foundation repo](https://github.com/AcademySoftwareFoundation/foundation/issues/new) to transfer ) - - [ ] Slack ( create [issue on foundation repo](https://github.com/AcademySoftwareFoundation/foundation/issues/new) to setup project channel on [ASWF Slack](https://slack.aswf.io) - - [ ] Website - - [ ] CI/build environment - - [ ] Trademarks/mark ownership rights ( complete 'LF Projects - Form of Trademark and Account Assignment' - create [issue on foundation repo](https://github.com/AcademySoftwareFoundation/foundation/issues/new) - only needed if project using existing name ) - - [ ] Domain name ( create [issue with the LF IT staff](https://jira.linuxfoundation.org/plugins/servlet/theme/portal/2/group/19) to setup/transfer ) - - [ ] Zoom account access ( create [issue on foundation repo](https://github.com/AcademySoftwareFoundation/foundation/issues/new) to get access to credentials ) - - [ ] Social media accounts or other project accounts ( create [issue on foundation repo](https://github.com/AcademySoftwareFoundation/foundation/issues/new) to transfer ) - - [ ] Logo(s) ( create [issue on artwork repo](https://github.com/AcademySoftwareFoundation/artwork/issues/new) to add in SVG and PNG format and color/black/white ) + - [x] Slack ( create [issue on foundation repo](https://github.com/AcademySoftwareFoundation/foundation/issues/new) to setup project channel on [ASWF Slack](https://slack.aswf.io) + - [x] Website + - [x] CI/build environment + - [x] Trademarks/mark ownership rights ( complete 'LF Projects - Form of Trademark and Account Assignment' - create [issue on foundation repo](https://github.com/AcademySoftwareFoundation/foundation/issues/new) - only needed if project using existing name ) + - [x] Domain name ( create [issue with the LF IT staff](https://jira.linuxfoundation.org/plugins/servlet/theme/portal/2/group/19) to setup/transfer ) + - [x] Zoom account access ( create [issue on foundation repo](https://github.com/AcademySoftwareFoundation/foundation/issues/new) to get access to credentials ) + - [x] Social media accounts or other project accounts ( create [issue on foundation repo](https://github.com/AcademySoftwareFoundation/foundation/issues/new) to transfer ) + - [x] Logo(s) ( create [issue on artwork repo](https://github.com/AcademySoftwareFoundation/artwork/issues/new) to add in SVG and PNG format and color/black/white ) - New Project Goverance - - [ ] TSC members identified - - [ ] First TSC meeting held - - [ ] TSC meeting cadence set and added to project calendar - - [ ] CLA Approved ( if used ) ( [CCLA](ccla.md) and [ICLA](icla.md) ) + - [x] TSC members identified + - [x] First TSC meeting held + - [x] TSC meeting cadence set and added to project calendar + - [x] CLA Approved ( if used ) ( [CCLA](ccla.md) and [ICLA](icla.md) ) - Project charter ( [charter.md](charter.md) ) - - [ ] Approved by TSC + - [x] Approved by TSC - [ ] Filed ( create pull request against [foundation repo](https://github.com/AcademySoftwareFoundation/foundation) ) - [ ] [Core Infrastructure Initiative Best Practices Badge](https://bestpractices.coreinfrastructure.org/) achieved as the 'Passing' level. - - [ ] TAC representative appointed + - [x] TAC representative appointed - Outreach - - [ ] New project annoucement done ( create [issue on foundation repo](https://github.com/AcademySoftwareFoundation/foundation/issues/new) to trigger ) - - [ ] Project added to ASWF website and ASWF landscape + - [x] New project annoucement done ( create [issue on foundation repo](https://github.com/AcademySoftwareFoundation/foundation/issues/new) to trigger ) + - [x] Project added to ASWF website and ASWF landscape - Adopted Stage graduation requirements - [ ] CII Badge achieved - [ ] Demonstrate a substantial ongoing flow of commits and merged contributions, authored by a healthy number of diverse contributors*.