cilium/community

Here you can find community content around Cilium

Community

Here you can find community content around Cilium.

Contribute

Check out the contributor ladder for different ways to get involved and level up within the project. You can see different roles within the project in the contributor roles. If you have already contributed to the project but it isn't caputured in the code, please add yourself to the contributor file.

Socializing

Connect with the community through:

• Follow us on Twitter, LinkedIn, and our blog
• Chat with us on Slack
• Subscribe to the newsletter
• Subscribe to the eBPF and Cilium Community on Youtube

Governance

Find out more about Cilium's governance here.

Values

The Cilium Community Values are guideposts to contributors (both new and ongoing) for how the project runs. They are meant to capture the spirit of the project of how we all work collaboratively together.

Vision

Learn the Cilium project direction, vision, and scope in the Vision. It is meant to capture where we are going together.

community's Issues

Cilium community values

Similar to the project vision #101 that describes what we are doing, we should also have a set of project values that describe how we are doing it.

For examples see https://contribute.cncf.io/maintainers/governance/charter/#values--principles

Move Governance to the community repo

I was talking with @lizrice and we thought it would make more sense to move the governance out of the Cilium docs and into this community repo.

Governance doesn't quite have "releases" and someone looking at the docs could easily be looking at an outdated version of the governance. Moving it into this repo would decouple governance from the release cycle. Moving it here would also also keep all of the governance docs together since the community ladder and roles already live here.

https://docs.cilium.io/en/stable/community/governance/commit_access/

Social Media Guidelines

We should create some social media guidelines. We can use https://github.com/cncf/foundation/blob/main/social-guidelines.md as a template

Offboarding Organization Members

In the contributor ladder, we have currently defined how people can become organization members, but we don't have any offboarding requirements if people become inactive in the project.

We should define a set of criteria that would be grounds for people to be removed from the organization (for example, not doing any contributions in a year).

Make member roles files

We need files that outline team and org memebership:

• Member Management
• Triage Team
• Security Team
• Community Team
• CI Team
• Maintainers

Once they are created, we need to link them to the contributor ladder and roles doc.

Project Charter

I was looking through some of the TAG Contributor Strategy documentation and came across the section on project charters.

"The purpose of having a charter for your open source project is to help people understand the mission, scope, and values / principles, and having this documented early can help avoid issues and misunderstandings later."

This could take the form of Mission, Scope, Values, and/or Principles. May be something for us to consider.

Move hubble-otel to Historical

Repository URL

https://github.com/cilium/hubble-otel

Current Scope

Ecosystem

Proposed Scope

Historical

Motivation for Request

The repo hasn't been updated in over a year and is no longer being maintained. This can be confusing to end users and it would be better to make clear to end users that it is no longer in use.

Code of Conduct

• I agree to follow Cilium's Code of Conduct

To be filled by a Cilium committer

• Approved change of scope is reflected in REPOSITORIES.md

Contributors file should also reference code contributors

The opening sentence of the CONTRIBUTORS.md file implies that this is the full list of contributors, but the code contributors aren't actually referenced in it. (Could just refer to something on GitHub or devstats)

Repo lifecycle

As the project continues to grow and expand more repos are coming under the organization. It would be great to more formally define the lifecycle of repos under the project. We could take the work from Falco as an example. We should also consider how we handle forked repos.

Consider Extending Length of Community Meeting

During the January 7, 2024 community meeting, I suggested extending the length of the community meeting. In recent meetings, the current meeting length (30 minutes) has not provided enough time to cover all topics or the meeting ran over time. Also, we discussed including CFP reviews in the weekly meeting agenda which places additional constraints on the meeting time. Please refer to this Slack thread for additional background on this issue.

Review and document Governance practices

Since we are migrating our governance documentation with #78 it might be a good idea to check that everything we have written down is in line with what we are currently practicing. I don't think we are missing anything, but double checking that we have it written down explicitly will make it easier for new people to understand how our governance works in practice.

I think our ideas of how governance works is similar to Prometheus so it might be helpful to borrow anything that might be missing from there https://prometheus.io/governance/

Document tool admins

It might be good to document who "owns" different tools so people can find out the right person to contact.

One example from Istio can be seen here https://github.com/istio/community/blob/master/ADMINS-FOR-ISTIO.md

Security Response: Private Distribution List

As the project has grown, more vendors are integrating Cilium into their projects and products. It might make sense to have a private distribution list where verified vendors can get early access to security patches to test them out and provide private feedback before they are released.

Kubernetes has a good framework for this and Envoy and Istio also follow a similar example.

It is not clear to me yet whether this should be in the community repo, main repo, or a separate new one, but I'm just opening the issue here for now.

Update GOVERNANCE to include sub project voting

Outside of it being easier to find the governance of the project (e.g., I usually look for a GOVERNANCE.md file or a community repo), I'd like to ensure the voting is done in a transparent way.

As I understand it, all the governance is currently here: https://github.com/cilium/community

I see that it is being followed by adding maintainers, e.g., cilium/cilium@3942bea

There's been confusion in public how certain decisions have been made in the project which is an opportunity for clarity and growth imho: https://twitter.com/urlichsanais/status/1750513165148790918

For tetragon, do you have an example of where the vote happened for this? I recall that when the project was being moved to CNCF, some of the votes were happening in the Cilium Slack which isn't a best practice and we recommended recording everything on github and/or mailing list. If a vote can't be dug up, the CNCF requests that you correct things to reflect what is stated in your governance. If you need help on how to do this, look at other CNCF projects e.g., https://github.com/envoyproxy/envoy/blob/main/GOVERNANCE.md#adding-new-projects-to-the-envoyproxy-github-organization

If you want to use a tool that helps, we have https://gitvote.dev in CNCF that can help with voting.