Add an optional leads mailing list address #8562

skitt · 2025-08-25T16:10:10Z

This was inspired by a SIG-Multicluster discussion; there are leads mailing lists that can be used to contact all the leads of a given SIG, but they aren't advertised. This adds a field, a template entry, and the information for SIG-MC.

Since the mailing list is only useful as an email address, the entry is supposed to be an email address (or slight anti-spam variant thereof), rather than the web link commonly used for open mailing lists.

Which issue(s) this PR fixes:

Fixes #

This was inspired by a SIG-Multicluster discussion; there are leads mailing lists that can be used to contact all the leads of a given SIG, but they aren't advertised. This adds a field, a template entry, and the information for SIG-MC. Since the mailing list is only useful as an email address, the entry is supposed to be an email address (or slight anti-spam variant thereof), rather than the web link commonly used for open mailing lists. Signed-off-by: Stephen Kitt <[email protected]>

k8s-ci-robot · 2025-08-25T16:10:20Z

[APPROVALNOTIFIER] This PR is NOT APPROVED

This pull-request has been approved by: skitt
Once this PR has been reviewed and has the lgtm label, please assign justaugustus for approval. For more information see the Code Review Process.

The full list of commands accepted by this bot can be found here.

Needs approval from an approver in each of these files:

OWNERS

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

pacoxu · 2025-08-26T01:34:37Z

/lgtm
/cc @kubernetes/steering-committee

k8s-ci-robot · 2025-08-26T01:34:40Z

@pacoxu: GitHub didn't allow me to request PR reviews from the following users: kubernetes/steering-committee.

Note that only kubernetes members and repo collaborators can review this PR, and authors cannot review their own PRs.

In response to this:

/lgtm
/cc @kubernetes/steering-committee

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes-sigs/prow repository.

BenTheElder

I think we might need to put a little thought into public vs private leads lists and how we communicate that here.

(EG private lists may be used for SRC reaching out about vulnerabilities reported through https://kubernetes.io/docs/reference/issues-security/security/, users should not do this directly)

BenTheElder · 2025-08-26T02:14:04Z

sigs.yaml

@@ -2193,6 +2193,7 @@ sigs:
  charter_link: charter.md
  label: multicluster
  leadership:
+    mailing_list_email: kubernetes-sig-multicluster-leads at googlegroups.com


You might want to migrate this to @kubernetes.io

BenTheElder · 2025-08-26T02:14:33Z

generator/sig_readme.tmpl

@@ -26,6 +26,9 @@ The [charter]({{.CharterLink}}) defines the scope and governance of the {{.Name}
 {{- if .Leadership }}

 ## Leadership
+{{- if .Leadership.MailingListEmail }}
+To contact all the leads, email `{{.Leadership.MailingListEmail}}`.


We should probably give some guidance about when it's appropriate to contact the leads versus to use the public forums?

Somewhat similar question, why would anyone need to reach out to leads rather than the entire SIG/WG? Alternatively, if there are org-related issues it will be steering the person should reach out to. So I second Ben's question, why would we need to advertise this?

@lauralorenz could you give more of the context here (this is based on #8541)?

Our leads mailing list doesn’t get used (except for automatic messages from Zoom etc.), people contact us (the leads) on Slack when they need to; but there are circumstances where contacting leads rather than the public forums or steering seems appropriate: discussing misbehaviour during calls or in forums (perhaps that should go to the CoC response team instead), or people asking about TL / chair “opportunities”.

If this isn’t needed at all then that makes life simpler for everyone, I opened this as a way forward for #8541 but I don’t have a preference either way.

discussing misbehaviour during calls or in forums (perhaps that should go to the CoC response team instead)

Yes, please. CoCC should handle reports of misbheavior.

or people asking about TL / chair “opportunities”.

Generally SIGs will handle this by internally nominating active participants, or doing an open call for interested parties (SIG Contribex can help run mentoring), I don't know that we should be encouraging the idea of "cold calling" for lead positions ... and I'm sure active participants will not have trouble getting in touch with one or more of the leads.

We do need a leads list, but usually it's for permissions reasons.
Some of the committees need a public + private list, because they need to handle non-public escalations (CoCC, SRC, Steering), though we still prefer broader forums when possible.

I'm not saying we shouldn't track / document this better, but if we do, we should explain when we expect users to reach out to these (as opposed to leads using it internally to manage permissions and to be recursively included in the community-wide leads list, etc).

or people asking about TL / chair “opportunities”.

Generally SIGs will handle this by internally nominating active participants, or doing an open call for interested parties (SIG Contribex can help run mentoring), I don't know that we should be encouraging the idea of "cold calling" for lead positions ... and I'm sure active participants will not have trouble getting in touch with one or more of the leads.

Indeed, and documenting this would no doubt encourage such contacts, which wouldn’t be a desirable outcome.

I'm not saying we shouldn't track / document this better, but if we do, we should explain when we expect users to reach out to these (as opposed to leads using it internally to manage permissions and to be recursively included in the community-wide leads list, etc).

Perhaps we could add it to the YAML file without using it in the template…

For context this came up when I was getting help setting up the google drive for our SIG and we needed to separate perms for admin vs access. I came away from that under the impression that it was expected to be easier to find what this email address was supposed to be for those purposes. If that's not true or it's not advisable to be visible in the README in particular, that's ok. The YAML file does seem like a better home if we want it findable but not necessarily /in your face/ when you're first landing on a community page.

RE: Finding it ... This somewhat duplicates where those groups are managed, which is organized into folders by SIG / WG / committee with permissions to self-manage:
https://github.com/kubernetes/k8s.io/tree/main/groups

Both SIG Contribex and K8s Infra can help with this sort of question about managing Docs permissions, it is within their charters (contributor platforms & experience, cloud accounts & resources).

The leads onboarding checklist includes updating these groups, and it's sort of expected that leads themselves know about their groups. https://github.com/kubernetes/community/blob/master/.github/ISSUE_TEMPLATE/leadership-change.yml

For other contributors, it's not really expected to be interacting with these, outside of documented escalation paths (like CoCC, or steering-private@).

Thanks for all the info @BenTheElder; since this info is available elsewhere and there isn’t any public use for these leads mailing lists we’d want to encourage, I’ll close this PR.

/close

pacoxu · 2025-08-26T10:20:20Z

generator/app.go

-	Chairs         []Person
-	TechnicalLeads []Person `yaml:"tech_leads,omitempty"`
-	EmeritusLeads  []Person `yaml:"emeritus_leads,omitempty"`
+	MailingListEmail string `yaml:"mailing_list_email,omitempty"`


Just find that there is private_mailing_list/PrivateMailingList in contact. Can we reuse that?

/lgtm cancel

However, some SIGs have both private and leads mailing list. For instance, https://github.com/kubernetes/k8s.io/blob/3f23fa8457979a6f20c5cbaf80204e8f2d55dce4/groups/sig-k8s-infra/groups.yaml#L21-L50.

k8s-ci-robot · 2025-09-01T08:51:53Z

@skitt: Closed this PR.

In response to this:

Thanks for all the info @BenTheElder; since this info is available elsewhere and there isn’t any public use for these leads mailing lists we’d want to encourage, I’ll close this PR.

/close

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes-sigs/prow repository.

k8s-ci-robot requested review from JeremyOT and palnabarun August 25, 2025 16:10

skitt mentioned this pull request Aug 25, 2025

Update README.md #8541

Closed

k8s-ci-robot assigned pacoxu Aug 26, 2025

k8s-ci-robot added the lgtm "Looks good to me", indicates that a PR is ready to be merged. label Aug 26, 2025

BenTheElder reviewed Aug 26, 2025

View reviewed changes

pacoxu reviewed Aug 26, 2025

View reviewed changes

k8s-ci-robot removed the lgtm "Looks good to me", indicates that a PR is ready to be merged. label Aug 26, 2025

k8s-ci-robot closed this Sep 1, 2025

Add an optional leads mailing list address #8562

Add an optional leads mailing list address #8562

Conversation

skitt commented Aug 25, 2025

Uh oh!

k8s-ci-robot commented Aug 25, 2025

Uh oh!

pacoxu commented Aug 26, 2025

Uh oh!

k8s-ci-robot commented Aug 26, 2025

Uh oh!

BenTheElder left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

BenTheElder Aug 26, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

k8s-ci-robot commented Sep 1, 2025

Uh oh!

Uh oh!

BenTheElder Aug 26, 2025 •

edited

Loading