chore: fine-tuning wording on the KDC charter#1007
Open
deusebio wants to merge 7 commits into
Open
Conversation
|
[APPROVALNOTIFIER] This PR is NOT APPROVED This pull-request has been approved by: The full list of commands accepted by this bot can be found here. DetailsNeeds approval from an approver in each of these files:Approvers can indicate their approval by writing |
deusebio
commented
Jul 1, 2026
| # Kubeflow Distribution Committee | ||
|
|
||
| The Kubeflow Distribution Committee (KDC) is a vendor-neutral body dedicated to supporting a healthy ecosystem of solutions by prioritizing the development, sustainability, interoperability, and distribution of individual Kubeflow sub-projects. While the primary focus of the KDC is to empower these sub-projects as modular, high-quality components, the Kubeflow Community Distribution serves as a primary example of this effort – providing a validated community supported implementation that demonstrates the collective power of these projects in a unified environment. By maintaining this distribution, the KDC aims to lower the barrier to entry for users and provide a streamlined path to adoption, while ensuring that sub-projects remain robust and valuable. | ||
| The Kubeflow Distribution Committee (KDC) is a vendor-neutral body dedicated to supporting a healthy ecosystem of solutions by prioritizing the development, sustainability, interoperability, and distribution of individual Kubeflow sub-projects. While the primary focus of the KDC is to empower these sub-projects as modular, high-quality components, the Kubeflow Community Distribution serves as a primary example of this effort – providing a validated community supported implementation that demonstrates the collective power of these projects in a unified environment. |
Author
There was a problem hiding this comment.
note: From my conversation with @andreyvelich , it would not be KDC responsibility to maintain the Kubeflow Community Distribution. I feel the sentence here was somewhat misleading, and I don't think it provides more value.
Member
There was a problem hiding this comment.
The KCD maintainers do maintain it.
Author
There was a problem hiding this comment.
Yes, but KDC and KCD maintainers are not the same thing as far as I understand. This is in scope for the KCD maintainers, not for the KDC.
Member
There was a problem hiding this comment.
As we discussed with KSC, it should be fine to remove KCD maintaining from here.
Author
There was a problem hiding this comment.
Sounds good! Will you resolve the comment, or should I?
deusebio
commented
Jul 1, 2026
Signed-off-by: Enrico Deusebio <enrico.deusebio@canonical.com>
Signed-off-by: Enrico Deusebio <enrico.deusebio@canonical.com>
deusebio
force-pushed
the
kdc-charter-updates
branch
from
5e6af2f to
f05b9bb
Compare
andreyvelich
reviewed
Jul 3, 2026
| # Kubeflow Distribution Committee | ||
|
|
||
| The Kubeflow Distribution Committee (KDC) is a vendor-neutral body dedicated to supporting a healthy ecosystem of solutions by prioritizing the development, sustainability, interoperability, and distribution of individual Kubeflow sub-projects. While the primary focus of the KDC is to empower these sub-projects as modular, high-quality components, the Kubeflow Community Distribution serves as a primary example of this effort – providing a validated community supported implementation that demonstrates the collective power of these projects in a unified environment. By maintaining this distribution, the KDC aims to lower the barrier to entry for users and provide a streamlined path to adoption, while ensuring that sub-projects remain robust and valuable. | ||
| The Kubeflow Distribution Committee (KDC) is a vendor-neutral body dedicated to supporting a healthy ecosystem of solutions by prioritizing the development, sustainability, interoperability, and distribution of individual Kubeflow sub-projects. While the primary focus of the KDC is to empower these sub-projects as modular, high-quality components, the Kubeflow Community Distribution serves as a primary example of this effort – providing a validated community supported implementation that demonstrates the collective power of these projects in a unified environment. |
Member
There was a problem hiding this comment.
As we discussed with KSC, it should be fine to remove KCD maintaining from here.
Co-authored-by: Andrey Velichkevich <andrey.velichkevich@gmail.com> Signed-off-by: deusebio <edeusebio85@gmail.com>
deusebio
commented
Jul 6, 2026
deusebio
left a comment
deusebio
left a comment
Author
There was a problem hiding this comment.
@andreyvelich I have addressed and included your suggestions. I only need you to:
andreyvelich
reviewed
Jul 6, 2026
Co-authored-by: Andrey Velichkevich <andrey.velichkevich@gmail.com> Co-authored-by: Julius von Kohout <45896133+juliusvonkohout@users.noreply.github.com> Signed-off-by: Julius von Kohout <45896133+juliusvonkohout@users.noreply.github.com>
Comment on lines
+16
to
+23
| ### Restrictions | ||
|
|
||
| ### Out of Scope (Limitations) | ||
| The committee will not approve decisions or policies on the upstream project that may undermine the longevity of the community or violate vendor-neutral sovereignty. This includes, but is not limited to: | ||
|
|
||
| - Anti-Ecosystem-Competitive Actions: Engaging in or permitting actions that undermine the longevity of the community or violate vendor-neutral sovereignty. This includes, but is not limited to: | ||
| - **Proprietary Lock-in:** Mandating that sub-projects or the distribution depend on proprietary APIs or closed-source components when general, open-source alternatives exist. | ||
| - **Core Fragmentation:** Implementing core functionality that is not upstreamed, as the KDC’s goal is to maintain a Kubernetes-native, portable, and extensible foundation. | ||
| - **Exclusionary Integration:** Forcing dependencies that intentionally disadvantage specific vendors or environments. | ||
| - **Note on Compatibility:** This does not exclude the development of community-supported or vendor-contributed adapters (e.g., data exporters, storage drivers, or external dependencies) designed to support specific environments, provided they remain external to the project's core functionality and do not compromise the portability of the base ecosystem. | ||
|
|
||
| Note on Compatibility: Development of community-supported, vendor-contributed adapters (e.g., data exporters, storage drivers, or external dependencies) or proprietary plugins designed to support specific environments shall remain external to the project's core functionality and as to not compromise the portability of the base ecosystem, unless it is decided that such components would pursue the goals above and not conflict with the restrictions. |
Member
There was a problem hiding this comment.
This section i would like to rever tback to its original state
Member
There was a problem hiding this comment.
We can keep the Restrictions subsection title.
Member
There was a problem hiding this comment.
SO
### Restrictions
- Anti-Ecosystem-Competitive Actions: Engaging in or permitting actions that undermine the longevity of the community or violate vendor-neutral sovereignty. This includes, but is not limited to:
- **Proprietary Lock-in:** Mandating that sub-projects or the distribution depend on proprietary APIs or closed-source components when general, open-source alternatives exist.
- **Core Fragmentation:** Implementing core functionality that is not upstreamed, as the KDC’s goal is to maintain a Kubernetes-native, portable, and extensible foundation.
- **Exclusionary Integration:** Forcing dependencies that intentionally disadvantage specific vendors or environments.
- **Note on Compatibility:** This does not exclude the development of community-supported or vendor-contributed adapters (e.g., data exporters, storage drivers, or external dependencies) designed to support specific environments, provided they remain external to the project's core functionality and do not compromise the portability of the base ecosystem.
Member
There was a problem hiding this comment.
@juliusvonkohout We might need to remove these restrictions since they are note applied to vendors:
Core Fragmentation: Implementing core functionality that is not upstreamed, as the KDC’s goal is to maintain a Kubernetes-native, portable, and extensible foundation.
Signed-off-by: Julius von Kohout <45896133+juliusvonkohout@users.noreply.github.com>
Signed-off-by: Julius von Kohout <45896133+juliusvonkohout@users.noreply.github.com>
Removed mention of 'Core Fragmentation' from restrictions. Signed-off-by: Julius von Kohout <45896133+juliusvonkohout@users.noreply.github.com>
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
3 participants
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.
Few updates to the text to better reflect the goals of the KDC to promote discussion/decisions/policy for the KF project to keep being vendor-neutral, while easily consumable by Distributions to also provide solid testing and integrations between the various subprojects
Some of the phrasing as it stands right now was somewhat suggesting restrictions on Distribution operations which I don't think it is the aim for the KDC, but that could prevent Distribution to join the extremely interesting initiative.