Skip to content

Add an optional leads mailing list address #8562

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
wants to merge 1 commit into from
+9 −3
Closed

Add an optional leads mailing list address #8562

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
7 changes: 4 additions & 3 deletions generator/app.go
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -263,9 +263,10 @@ type Subproject struct {

// LeadershipGroup represents the different groups of leaders within a group
type LeadershipGroup struct {
Chairs []Person
TechnicalLeads []Person `yaml:"tech_leads,omitempty"`
EmeritusLeads []Person `yaml:"emeritus_leads,omitempty"`
MailingListEmail string `yaml:"mailing_list_email,omitempty"`
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

/lgtm cancel

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Chairs []Person
TechnicalLeads []Person `yaml:"tech_leads,omitempty"`
EmeritusLeads []Person `yaml:"emeritus_leads,omitempty"`
}

// PrefixToPersonMap returns a map of prefix to persons, useful for iteration over all persons
Expand Down
3 changes: 3 additions & 0 deletions generator/sig_readme.tmpl
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -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}}`.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@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”.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Member

@BenTheElder BenTheElder Aug 26, 2025 •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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).

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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…

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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@).

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

{{- end }}
{{- if .Leadership.Chairs }}

### Chairs
Expand Down
1 change: 1 addition & 0 deletions sig-multicluster/README.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -22,6 +22,7 @@ The [charter](charter.md) defines the scope and governance of the Multicluster S
* [Meeting recordings](https://www.youtube.com/playlist?list=PL69nYSiGNLP0HqgyqTby6HlDEz7i1mb0-).

## Leadership
To contact all the leads, email `kubernetes-sig-multicluster-leads at googlegroups.com`.

### Chairs
The Chairs of the SIG run operations and processes governing the SIG.
Expand Down
1 change: 1 addition & 0 deletions sigs.yaml
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -2193,6 +2193,7 @@ sigs:
charter_link: charter.md
label: multicluster
leadership:
mailing_list_email: kubernetes-sig-multicluster-leads at googlegroups.com
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

You might want to migrate this to @kubernetes.io

chairs:
- github: jeremyot
name: Jeremy Olmsted-Thompson
Expand Down