CNCF Sandbox onboarding

[rootfs]

Discussed in https://github.com/sustainable-computing-io/kepler/discussions/695

^{Originally posted by **rootfs** May 18, 2023} If you are in any of these teams, you are a Kepler maintainer. @sustainable-computing-io/community-manager @sustainable-computing-io/community-manager @sustainable-computing-io/maintainer @sustainable-computing-io/reviewer @sustainable-computing-io/kepler-helm-maintainer @sustainable-computing-io/kepler-deployment - Please review the onboarding process [here](https://github.com/cncf/sandbox/issues/199) - Please provide your info in this format: Name, Company, Github ID, Email. - Please volunteer the required tasks Please do it with urgency. Let's finish the onboarding process in two weeks by June 2nd. # Tasks: From the project side, please ensure that you: - [x] Understand the project proposal process and reqs: https://github.com/cncf/toc/blob/main/process/project_proposals.md#introduction - [x] Understand the services available for your project at CNCF https://www.cncf.io/services-for-projects/ - [x] Ensure your project meets the CNCF IP Policy: https://github.com/cncf/foundation/blob/master/charter.md#11-ip-policy - [x] Review the online programs guidelines: https://github.com/cncf/foundation/blob/master/online-programs-guidelines.md - [x] Understand the trademark guidelines: https://www.linuxfoundation.org/en/trademark-usage/ - [x] Understand the license allowlist: https://github.com/cncf/foundation/blob/master/allowed-third-party-license-policy.md#approved-licenses-for-allowlist - [x] Is your project working on written, open governance? see https://contribute.cncf.io/maintainers/governance/ - [x] Slack: Are your slack channels migrated to the Kubernetes or CNCF Slack? (see https://slack.com/help/articles/217872578-Import-data-from-one-Slack-workspace-to-another for more details) - [x] Is your project in its own separate neutral github organization? - [x] Submitted a Pull request to add your project as a sandbox project to https://landscape.cncf.io/ - [x] Create maintainer list + add to aggregated https://maintainers.cncf.io/ list by submitting a PR to it - [x] Artwork: Submit a pull request to https://github.com/cncf/artwork with your artwork - [x] Domain: transfer domain to the CNCF - https://jira.linuxfoundation.org/plugins/servlet/theme/portal/2/create/63 Things that CNCF will need from the project: - [x] Provide emails for the maintainers added to https://maintainers.cncf.io/ in order to get access to the maintainers mailing list and ServiceDesk - [project-onboarding@cncf.io](mailto:project-onboarding@cncf.io) is the best email to send those to - [x] Trademarks: transfer any trademark and logo mark assets over to the LF - https://github.com/cncf/foundation/tree/master/agreements has agreements - [x] GitHub: ensure 'thelinuxfoundation' and 'caniszczyk' are added as initial org owners, this helps us make sure we have continuity of GH ownership that we will onboard to our GitHub Enterprise instance: https://github.com/enterprises/cncf - [x] GitHub: ensure [DCO](https://github.com/apps/dco) or [CLA](https://github.com/cncf/cla) are enabled for all GitHub repositories of the project - [x] GitHub: ensure that that the [CNCF Code of Conduct](https://github.com/cncf/foundation/blob/master/code-of-conduct.md) (or your adopted version of it) are explicitly referenced at the project's README on GitHub - [x] Website: ensure LF footer is there and [website guidelines](https://github.com/cncf/foundation/blob/master/website-guidelines.md) followed (if your project doesn't have a dedicated website, please adopt those guidelines to the README file of your project on GitHub). @nikimanoledaki @husky-parul can you help this one? - [x] Website: Analytics transferred to [projects@cncf.io](mailto:projects@cncf.io) - [x] OpenSSF Best Practices Badge: Start on an OpenSSF Best Practices Badge https://bestpractices.coreinfrastructure.org/en # Maintainers: | Name | Company | Github ID | Email | |---|---|---|---| | Huamin Chen | Red Hat | rootfs | hchen@redhat.com | | Ji Chen | IBM | jichenjc | jichenjc@cn.ibm.com | | Parul Singh | Red Hat | husky-parul | parsingh@redhat.com | | Kaiyi Liu | Red Hat | KaiyiLiu1234 | kaliu@redhat.com | | Peng Hui Jiang | IBM | jiangphcn | jiangph@cn.ibm.com | | William Caban | Red Hat | williamcaban | wcabanba@redhat.com | | Yi Yuan | IBM | SamYuan1990 | yy19902439@126.com | | Qi Feng Huo | IBM | huoqifeng | huoqif@cn.ibm.com | | Ken Lu | Intel | kenplusplus | ken.lu@intel.com | | Marcelo Amaral | IBM | marceloamaral | marcelo.amaral1@ibm.com | | Niki Manoledaki | Weaveworks | nikimanoledaki | niki@weave.works | | Brad McCoy | Basiq | bradmccoydev | bradmccoydev@gmail.com | | Sunyanan Choochotkaew | IBM | sunya-ch | sunyanan.choochotkaew1@ibm.com | | Ruomeng Hao | Intel | ruomengh | ruomengh@intel.com | Chen Wang | IBM | wangchen615 | chen.wang1@ibm.com |

[SamYuan1990]

I tried with https://bestpractices.coreinfrastructure.org/en/projects but some error happens as return from the website.

[rootfs]

@sustainable-computing-io/community-manager @sustainable-computing-io/community-manager @sustainable-computing-io/maintainer @sustainable-computing-io/reviewer @sustainable-computing-io/kepler-helm-maintainer @sustainable-computing-io/kepler-deployment

we are going to sign off the trademark agreement. Please make sure your info is up to date.

[SamYuan1990]

about openSSF, personally I suppose we can edit and update as:

Basic project website content

Met after https://github.com/sustainable-computing-io/kepler-doc/issues/47

Documentation

The project MUST provide reference documentation that describes the external interface (both input and output) of the software produced by the project. https://github.com/sustainable-computing-io/kepler-doc/issues/22

Other

The project SHOULD provide documentation in English and be able to accept bug reports and comments about code in English. Met?

Change Control

To enable collaborative review, the project's source repository MUST include interim versions for review between releases; it MUST NOT include only final releases. Met?

• Unique version numbering The project results MUST have a unique version identifier for each release intended to be used by users. Met? by github commit hash in code?

• It is SUGGESTED that the Semantic Versioning (SemVer) or Calendar Versioning (CalVer) version numbering format be used for releases. It is SUGGESTED that those who use CalVer include a micro level value. Met?

• It is SUGGESTED that projects identify each release within their version control system. For example, it is SUGGESTED that those using git identify each release using git tags. Met

Release notes

N/A Github release workflow used? I can't open https://github.blog/2013-07-02-release-your-software/ but https://github.com/sustainable-computing-io/kepler/blob/main/.github/workflows/release.yml#L62 N/A

@rootfs , I go through parts of https://bestpractices.coreinfrastructure.org/en/projects/7391#reporting and updated my opinion here. Please take a look at.

[SamYuan1990]

• Working build system The project SHOULD be buildable using only FLOSS tools. N/A

• Automated test suite

• The project MUST use at least one automated test suite that is publicly released as FLOSS (this test suite may be maintained as a separate FLOSS project). The project MUST clearly show or document how to run the test suite(s) (e.g., via a continuous integration (CI) script or via documentation in files such as BUILD.md, README.md, or CONTRIBUTING.md) Met golang

• A test suite SHOULD be invocable in a standard way for that language. make test or even better in pr

• It is SUGGESTED that the test suite cover most (or ideally all) the code branches, input fields, and functionality. in the pr the command make check runs all linting, unit and bdd tests

• It is SUGGESTED that the project implement continuous integration (where new or changed code is frequently integrated into a central code repository and automated tests are run on the result） Met， Github action， but our test coverage is....

• The project MUST enable one or more compiler warning flags, a "safe" language mode, or use a separate "linter" tool to look for code quality errors or common simple mistakes, if there is at least one FLOSS tool that can implement this criterion in the selected language. Met, golint

• The project MUST address warnings. Met

• It is SUGGESTED that projects be maximally strict with warnings in the software produced by the project, where practical. Met

• Use basic good cryptographic practices N/A for all?

• Publicly known vulnerabilities fixed Met by dep bot?

• Other security issues Met

• At least one static code analysis tool (beyond compiler warnings and "safe" language modes) MUST be applied to any proposed major production release of the software before its release, if there is at least one FLOSS tool that implements this criterion in the selected language. Met, golint, gofmt?

• It is SUGGESTED that at least one of the static analysis tools used for the static_analysis criterion include rules or approaches to look for common vulnerabilities in the analyzed language or environment. Met, by make scripts

[stale[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.