[Incubation] Meshery Incubation Application

[ctcarrier]

Meshery Incubation Application

v1.5
This template provides the project with a framework to inform the TOC of their conformance to the Incubation Level Criteria.

Project Repo(s): https://github.com/meshery/meshery
Project Site: https://meshery.io/
Sub-Projects: https://github.com/meshery/schemas, https://github.com/meshery/meshkit, https://github.com/meshery/meshery-istio, https://github.com/meshery/meshsync, https://github.com/meshery/meshery-linkerd, https://github.com/meshery/meshery-operator
Communication: https://slack.meshery.io/

Project points of contacts: Meshery Maintainers, [email protected]

Incubation Criteria Summary for Meshery

Adoption Assertion

The project has been adopted by the following organizations in a testing and integration or production capacity:

https://github.com/meshery/meshery/blob/master/ADOPTERS.md

Application Process Principles

Suggested

N/A

Required

• Give a presentation and engage with the domain specific TAG(s) to increase awareness
  • This was completed and occurred on 04-Nov-2021, and can be discovered at https://www.youtube.com/watch?v=FPMde6EHcJU&t=3936s.

• TAG provides insight/recommendation of the project in the context of the landscape

https://docs.meshery.io/project/community

• All project metadata and resources are vendor-neutral.

As an open source, vendor neutral project, Meshery was created out of the necessity to enable platform engineers, site reliability engineers, DevSecOps teams - all engineers to collaborate in the management of their infrastructure and workloads.

• Review and acknowledgement of expectations for Sandbox projects and requirements for moving forward through the CNCF Maturity levels.
• Met during Project's application on 01-Mar-2024: [Proposal] - Meshery to incubation #1264

• Due Diligence Review.

Completion of this due diligence document, resolution of concerns raised, and presented for public comment satisfies the Due Diligence Review criteria.

• Additional documentation as appropriate for project type, e.g.: installation documentation, end user documentation, reference implementation and/or code samples.

Installation
Concepts
Guides
Contributing and Community
Reference

Governance and Maintainers

Note: this section may be augmented by the completion of a Governance Review from TAG Contributor Strategy.

Suggested

• Clear and discoverable project governance documentation.

https://github.com/meshery/meshery/blob/master/GOVERNANCE.md

• Governance has continuously been iterated upon by the project as a result of their experience applying it, with the governance history demonstrating evolution of maturity alongside the project's maturity evolution.

• Governance is up to date with actual project activities, including any meetings, elections, leadership, or approval processes.

• Governance clearly documents vendor-neutrality of project direction.

• Document how the project makes decisions on leadership, contribution acceptance, requests to the CNCF, and changes to governance or project goals.

https://github.com/meshery/meshery/blob/master/GOVERNANCE.md
https://docs.meshery.io/project/contributing
https://docs.meshery.io/project/community

• Document how role, function-based members, or sub-teams are assigned, onboarded, and removed for specific teams (example: Security Response Committee).

https://github.com/meshery/meshery/blob/master/GOVERNANCE.md#contributors
https://github.com/meshery/meshery/blob/master/GOVERNANCE.md#maintainership

• Document a complete maintainer lifecycle process (including roles, onboarding, offboarding, and emeritus status).

https://github.com/meshery/meshery/blob/master/GOVERNANCE.md#becoming-a-maintainer
https://github.com/meshery/meshery/blob/master/GOVERNANCE.md#emeritus-maintainers

• Demonstrate usage of the maintainer lifecycle with outcomes, either through the addition or replacement of maintainers as project events have required.

• If the project has subprojects: subproject leadership, contribution, maturity status documented, including add/remove process.

https://github.com/meshery/meshery/blob/master/MAINTAINERS.md

Required

• Document complete list of current maintainers, including names, contact information, domain of responsibility, and affiliation.

https://github.com/meshery/meshery/blob/master/MAINTAINERS.md

• A number of active maintainers which is appropriate to the size and scope of the project.

• Code and Doc ownership in Github and elsewhere matches documented governance roles.

• Document agreement that project will adopt CNCF Code of Conduct.

https://github.com/meshery/meshery/blob/master/CODE_OF_CONDUCT.md

• CNCF Code of Conduct is cross-linked from other governance documents.

https://github.com/meshery/meshery/blob/master/CODE_OF_CONDUCT.md

• All subprojects, if any, are listed.

Contributors and Community

Note: this section may be augmented by the completion of a Governance Review from TAG Contributor Strategy.

Suggested

• Contributor ladder with multiple roles for contributors.

https://github.com/meshery/meshery/blob/master/GOVERNANCE.md#contributors
https://github.com/meshery/meshery/blob/master/GOVERNANCE.md#maintainership

Required

• Clearly defined and discoverable process to submit issues or changes.

https://docs.meshery.io/project/contributing

• Project must have, and document, at least one public communications channel for users and/or contributors.

Slack and mailing lists documented on website.

• List and document all project communication channels, including subprojects (mail list/slack/etc.). List any non-public communications channels and what their special purpose is.

Documented on website.

• Up-to-date public meeting schedulers and/or integration with CNCF calendar.

https://meshery.io/calendar

• Documentation of how to contribute, with increasing detail as the project matures.

https://layer5.io/community/newcomers

• Demonstrate contributor activity and recruitment.

Engineering Principles

Suggested

• Roadmap change process is documented.

https://github.com/meshery/meshery/blob/master/ROADMAP.md

• History of regular, quality releases.

https://github.com/meshery/meshery/releases

Required

• Document project goals and objectives that illustrate the project’s differentiation in the Cloud Native landscape as well as outlines how this project fulfills an outstanding need and/or solves a problem differently.

https://docs.meshery.io/project/overview

• Document what the project does, and why it does it - including viable cloud native use cases.

https://docs.meshery.io/concepts/logical

• Document and maintain a public roadmap or other forward looking planning document or tracking mechanism.

https://github.com/meshery/meshery/blob/master/ROADMAP.md

• Document overview of project architecture and software design that demonstrates viable cloud native use cases, as part of the project's documentation.

https://docs.meshery.io/concepts/architecture

• Document the project's release process.

https://docs.meshery.io/project/contributing/build-and-release

Security

Note: this section may be augemented by a joint-assessment performed by TAG Security.

Suggested

N/A

Required

• Clearly defined and discoverable process to report security issues.

https://docs.meshery.io/project/security-vulnerabilities

• Enforcing Access Control Rules to secure the code base against attacks (Example: two factor authentication enforcement, and/or use of ACL tools.)

https://github.com/meshery/meshery/blob/master/GOVERNANCE.md#github-project-administration

• Document assignment of security response roles and how reports are handled.

https://docs.meshery.io/project/security-vulnerabilities

• Document Security Self-Assessment.

https://docs.meshery.io/project/security-vulnerabilities#evaluation

• Achieve the Open Source Security Foundation (OpenSSF) Best Practices passing badge.

https://www.bestpractices.dev/en/projects/3564

Ecosystem

Suggested

N/A

Required

• Publicly documented list of adopters, which may indicate their adoption level (dev/trialing, prod, etc.)

https://github.com/meshery/meshery/blob/master/ADOPTERS.md

• Used in appropriate capacity by at least 3 independent + indirect/direct adopters, (these are not required to be in the publicly documented list of adopters)

The project provided the TOC with a list of adopters for verification of use of the project at the level expected, i.e. production use for graduation, dev/test for incubation.

• TOC verification of adopters.

Refer to the Adoption portion of this document.

• Clearly documented integrations and/or compatibility with other CNCF projects as well as non-CNCF projects.

https://docs.meshery.io/extensibility/integrations

Additional Information

[angellk]

@ctcarrier thank you for submitting Meshery's application for incubation. Your presentation to TAG Network was almost 3 years ago - please work with TAG Network and/or TAG Runtime to provide an update on Project meshery scope, architecture and community.
cc: @leecalcote @raravena80

[angellk]

Note: replaces #1264

[craigbox]

@ctcarrier thank you for submitting Meshery's application for incubation. Your presentation to TAG Network was almost 3 years ago - please work with TAG Network and/or TAG Runtime to provide an update on Project meshery scope, architecture and community. cc: @leecalcote @raravena80

Reading the project website:

A self-service engineering platform, Meshery, is the open source, cloud native manager that enables the design and management of all Kubernetes-based infrastructure and applications (multi-cloud). Among other features, As an extensible platform, Meshery offers visual and collaborative GitOps, freeing you from the chains of YAML while managing Kubernetes multi-cluster deployments.

Would TAG App Delivery not be the appropriate group?

[leecalcote]

Meshery's August 15th, 2024 prevention to TAG Runtime - meeting recording and slides

[angellk]

@ctcarrier In preparation for Meshery to be picked up by a TOC member after the KubeCon freeze period -- and prior to TOC member assignment -- please:

• review the definition of an adopter
• verify 5-7 project adopters that can and are willing to be interviewed by the TOC reviewer(s) and
• submit information for each adopter to the Adopter Interview Questionnaire form
• complete the required Security Self Assessment
• review the Meshery GitHub and Website for all documents linked that are not open to the public, for example:
  • Meshery Test Plan linked on the Meshery Build and Release page
  • Roadmap Document linked at the bottom of the ROADMAP.md

[angellk]

@craigbox

Would TAG App Delivery not be the appropriate group?

With a lot of overlap between different domains with some projects - if the TOC reviewer determines the TAG Runtime presentation was insufficient, they can ask additional clarifying questions and/or ask the TAG App Delivery to conduct a Domain Technical Review.