Meshery Incubation Feedback: Labeling of repositories by support type (Community / Official)

[Lee Calcote]

Hi All,

As the diligence process continues with Meshery incubation proposal, one point of feedback has been to ensure that we fully realize a proposal to label repositories with their level of support that we outlined back in October when we split the “meshery” org to two different organizations.

• Clear labeling: Documentation should indicate the support level (e.g., “Official” vs. “Community”) for each extension.

We describe this repo labeling again in our GOVERNANCE.MD:

• Support labeling. Each extension's documentation indicates its support level so that users understand what to expect:
• Official. Maintained by the core maintainers or designated maintainers, with robust support and compatibility testing against supported core releases.
• Community. Maintained by community contributors, with support and release cadence determined by those maintainers.

I have put together a list of the meshery-extensions repos in this spreadsheet along with their proposed support type. Please review, and agree/disagree/propose changes.

Thanks!

- Lee

[Lee Calcote]

Here is the issue calling for implementation of this repo labeling - https://github.com/meshery/meshery/issues/21137

- Lee

[Yi Nuo]

I have been busy on a framework to implement the labels (thanks for your help, Lee!).

Here is what I have. Labels will show up three different ways:

1. a github custom property, "support", with possible values of ("official" | "community") added to both orgs. All repos in the meshery org receive "official", while only some receive this under the meshery-extensions org.
2. a topic on each repo ("support-official" | "support-community")
3. a README badge in each repo ("support-official" | "support-community")

On an ongoing basis, these labels will be enforced by: 

1. Automated: A scheduled check using a GitHub workflow comparing live values against the maintainers.md file, which is treated as the source of truth for repo support level and files an issue on drift.

2. Manual: A new-extension onboarding now requires a manifest entry before a repo is considered admitted, folded into instructions under "Adding a subproject or extension" in GOVERNANCE.md.

What do you all think?

Yi

[Lee Calcote]

This sounds robust. I'm a fan of your proposed use of the maintainers.md file for tracking support labels, however, I think the fact that the data is unstructured in that file is going to cause pain - more pain than the trouble of having to maintain a separate manifest, losing the repos. My vote is for a separate manifest. I also wonder if this workflow shouldn't be run from the .projects repo. That’s something we’d have to ask the CNCF staff about. In the meantime, .github in meshery-extensions seems reasonable.

- Lee

-- 
Visit and engage with the Meshery community in the forum at http://discuss.meshery.io or in Slack at https://slack.meshery.io.
--- 
You received this message because you are subscribed to the Google Groups "Meshery Maintainers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to maintainers...@meshery.io.
To view this discussion visit https://groups.google.com/a/meshery.io/d/msgid/maintainers/e4480546-d020-47bb-b86b-ad908ec60eefn%40meshery.io.

[Pontus Ringblom]

Yi,

Recognizing the urgency here, I’m elevating your GitHub permissions (to owner) so that you can proceed with the custom properties and rest of implementation of label framework.

Best,

Pontus