Add policy for generative artificial intelligence#408
Merged
Conversation
youngnick
reviewed
May 1, 2026
youngnick
left a comment
There was a problem hiding this comment.
Thanks for all your work on this @joestringer, LGTM, and it's great to have a start here.
I'll just comment rather than approve so we can get some more feedback before merging.
pchaigno
approved these changes
May 1, 2026
kkourt
approved these changes
May 4, 2026
bimmlerd
approved these changes
May 4, 2026
giorio94
approved these changes
May 4, 2026
kaworu
approved these changes
May 4, 2026
gandro
approved these changes
May 4, 2026
xmulligan
approved these changes
May 4, 2026
nbusseneau
approved these changes
May 4, 2026
HadrienPatte
approved these changes
May 4, 2026
rolinh
approved these changes
May 4, 2026
christarazi
approved these changes
May 4, 2026
Member
christarazi
left a comment
There was a problem hiding this comment.
Thanks for the efforts of those involved on this!
smagnani96
approved these changes
May 4, 2026
Contributor
smagnani96
left a comment
There was a problem hiding this comment.
Thank you so much to anyone involved into this 💯
msune
suggested changes
May 4, 2026
joestringer
commented
May 5, 2026
joestringer
commented
May 5, 2026
Member
Author
joestringer
left a comment
There was a problem hiding this comment.
Couple more links for reference
cf29289 to
7482fa3
Compare
joestringer
commented
May 7, 2026
joestringer
commented
May 7, 2026
The Cilium community builds and distributes a range of software that is critical for operating many pieces of modern Internet infrastructure. In order to uphold the trust our users place in our software, the Cilium community maintains a high quality bar for contributions. We cultivate this bar by investing significant time and effort into contributors who show a sustained interest in contributing to systems development. Over time, by spending time learning, contributing, and mentoring others, we build trust in newer contributors, delegate trust to them, and ultimately increase the community's capacity to work on our shared [vision]. We've identified and recognized several committers and maintainers over time through their activity within this community. These valuable maintainers of the project started as individual contributors and grew their involvement over time, gradually building trust within the community. The pattern of these contributors is a common one: They start small, they learn the project's guidelines and expectations, and they give more to the community than what they take. For core team members, it's a pleasure to work with these individuals as we collectively build software we can all be proud of. We are able to move faster by delegating significant trust to the individuals we frequently work with. Recent industry developments in software tooling have lowered the barrier of entry for people to generate contributions to open source communities. We see newer contributors jump directly to proposing larger, more complex changes. The purported author of these changes often cannot explain why they are trying to make the change. At a cursory glance, these changes may appear sensible enough, but reviewers must spend significant time considering the details of the implementation and identifying potential technical debt and long term maintenance burden. In the past, a contributor would need to be heavily invested in the community in order to submit such a change, but these are now created by "drive-by" contributors. The result of this trend is that reviewers feel overburdened by many complex submissions. It is harder to recognize when contributors intend to stick around in the community to help maintain the changes over time. There are more contributors to teach and mentor, but it's less clear whether the time spent teaching newer contributors will lead to the community growing. Key decisions about longer term architecture and maintenance are not naturally brought up as part of larger contributions, because the contributors themselves have not been involved in the community enough to recognize that tech debt. And reviewers are demotivated by submissions which are made by untrusted individuals who cannot demonstrate understanding of how to build quality systems software. The goal of this contribution is to set out clear guidance on the use of generative AI tooling in order to build a healthy and vibrant community. Newer contributors should benefit from this guidance by understanding the expectations for their contributions. Those who are able to acknowledge this guidance, learn, and contribute on an ongoing basis can more easily build trust in the community through clear communication. At the same time, reviewers and maintainers can use this guidance to balance the time they spend on contributions based on the effort put in by the contributor. This policy has been drafted over the past several months in consultation with a range of community members and committers. Notably, it draws inspiration from discussions in the following sources: - #239 - zulip/zulip@2be6c72 - bootc-dev/infra@3e0c644 [vision]: https://github.com/cilium/community/blob/main/VISION.md Co-authored-by: Bill Mulligan <billmulligan516@gmail.com> Signed-off-by: Joe Stringer <joe@cilium.io>
7482fa3 to
ada28d3
Compare
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
The Cilium community builds and distributes a range of software that is
critical for operating many pieces of modern Internet infrastructure. In
order to uphold the trust our users place in our software, the Cilium
community maintains a high quality bar for contributions. We cultivate
this bar by investing significant time and effort into contributors who
show a sustained interest in contributing to systems development. Over
time, by spending time learning, contributing, and mentoring others, we
build trust in newer contributors, delegate trust to them, and
ultimately increase the community's capacity to work on our shared
vision.
We've identified and recognized several committers and maintainers over
time through their activity within this community. These valuable
maintainers of the project started as individual contributors and grew
their involvement over time, gradually building trust within the
community. The pattern of these contributors is a common one: They start
small, they learn the project's guidelines and expectations, and they
give more to the community than what they take. For core team members,
it's a pleasure to work with these individuals as we collectively build
software we can all be proud of. We are able to move faster by
delegating significant trust to the individuals we frequently work with.
Recent industry developments in software tooling have lowered the
barrier of entry for people to generate contributions to open source
communities. We see newer contributors jump directly to proposing
larger, more complex changes. The purported author of these changes
often cannot explain why they are trying to make the change. At a
cursory glance, these changes may appear sensible enough, but reviewers
must spend significant time considering the details of the
implementation and identifying potential technical debt and long term
maintenance burden. In the past, a contributor would need to be heavily
invested in the community in order to submit such a change, but these
are now created by "drive-by" contributors.
The result of this trend is that reviewers feel overburdened by the
volume of submissions. It is harder to recognize when contributors intend
to stick around in the community to help maintain the changes over time.
There are more contributors to teach and mentor, but it's less clear
whether the time spent teaching newer contributors will lead to the
community growing. Key decisions about longer term architecture and
maintenance are not naturally brought up as part of larger
contributions, because the contributors themselves have not been
involved in the community enough to recognize that tech debt. And
reviewers are demotivated by submissions which are made by untrusted
individuals who cannot demonstrate understanding of how to build quality
systems software.
The goal of this contribution is to set out clear guidance on the use of
generative AI tooling in order to build a healthy and vibrant community.
Newer contributors should benefit from this guidance by understanding
the expectations for their contributions. Those who are able to
acknowledge this guidance, learn, and contribute on an ongoing basis can
more easily build trust in the community through clear communication. At
the same time, reviewers and maintainers can use this guidance to
balance the time they spend on contributions based on the effort put in
by the contributor.
This policy has been drafted over the past several months in consultation
with a range of community members and committers. Notably, it draws
inspiration from discussions in the following sources:
Co-authored-by: @xmulligan (PR content; This description is my own musings)