Contributing to the Kubeflow Ecosystem - Evolving from beginner to pro OSS contr... Christian Heusel
Watch on YouTubeVideo summary
Christian Heusel opens his talk on contributing to the Kubeflow ecosystem by addressing two primary themes: how to contribute through code and how to engage without coding proficiency. For those interested in writing code, he advises starting with small, manageable tasks such as fixing bugs that personally annoy users or implementing missing functionalities, rather than tackling large features immediately. He emphasizes the importance of adhering to community rules and code conventions documented in project-specific guides like contributing.md, and stresses that for significant contributions, contributors must coordinate with maintainers beforehand to avoid duplicating work. Furthermore, he reassures new contributors not to fear extensive code review comments, noting that feedback is a vital learning opportunity that helps improve coding skills and ensures changes are ready for merging.
Beyond direct coding, Heusel highlights numerous non-coding avenues for involvement within the community, ranging from submitting high-quality bug reports and helping with triage to adding oneself to the adopters file for greater ecosystem exposure. Experienced developers are particularly encouraged to mentor newcomers and assist in governance tasks, while individuals with specific interests in security or DevOps can find relevant projects among Kubeflow's various controller code bases. He also points out a critical need for front-end experts, as many contributors working on user interfaces are new to the project, creating an opportunity for seasoned coders to bridge that gap. Additionally, those with skills in writing, design, or bridging different companies and communities can add significant value by improving documentation, publishing materials, and fostering collaboration between diverse groups.
A significant portion of the discussion is dedicated to the responsible use of AI tools, which Heusel warns against relying on as the primary driver for contributions, especially for beginners. While acknowledging that AI can assist in generating text or acting as a sparring partner for discussing implementation ideas, he argues that over-reliance can hinder the learning process and make it difficult to verify outputs. Instead, he recommends using AI as a supplementary tool to ask questions about the codebase, refine understanding, and perform pre-submission reviews to catch mistakes before human reviewers see them. He suggests that contributors periodically step away from AI tools to identify their own skill gaps, ensuring they maintain the ability to explain and justify their changes transparently in line with Kubeflow's AI policy.
In conclusion, Heusel encourages a balanced approach where technology serves as an aid rather than a replacement for human judgment and effort. Whether through testing release candidates like QFlow notebooks, supporting users in communication channels, or simply taking breaks to reflect on personal growth, every individual can find a meaningful role in the Kubeflow ecosystem. The ultimate goal is to foster a community where diverse skill sets are valued, feedback is embraced as a path to improvement, and contributors actively work together to make the project more robust and accessible for everyone involved.
Read the full video transcript
Hello everyone, and welcome to the talk
about contributing to the Kubeflow
ecosystem. Um kind of uh fitting well to
that, I uh was honored to be the
contributor of the month in in in the
last
uh edition, and so that kind of fits in
well with the talk. However, um that was
uh
far later than I submitted this talk, so
um that's not related directly.
Um
I want to talk uh to you about like the
two both uh two big themes. One is um
how do you contribute um by code, and
also how do you contribute without uh
being able to code, uh or maybe not code
as proficiently yet.
Um
when you want to contribute something in
code, um you generally should uh start
out in a rather small fashion. So, find
something that you like, um use I don't
know, any of the bugs that you're uh
currently facing that annoy you in the
UI, or uh some functionality that you
want to use that is currently not
working, um and also see if others filed
anything that would be maybe easy to fix
um
for beginners in the code base.
Also, pay close attention when you do
contribute a uh code fix to um follow
the code conventions and the community
rules.
Um these are
yeah, documented quite broadly both in
the general sense for the overall
Kubeflow ecosystem, but also on a per
project uh basis in the contributing.md
or separate contributor guides.
We also have a AI policy in the Kubeflow
landscape,
and I will um spare a few words about uh
the usage of AI agent and what I deem
sensible and what not um later on in in
this talk.
Generally, I think um if what you pick
up is um not a small and easy easy
thing, you should always coordinate with
the respective project maintainers. So,
if you take on some big feature, um
please coordinate with the people first
because
um, the maintainers of the project might
point you to
tasks that are easier to pick up at
first and this way you can also
coordinate whether someone is already
working on that feature and um,
so that there's no work being
duplicated.
Part of contributing code in the open
source world is always also getting code
review
and for me at least in the in the
beginning this felt a little bit
surprising at least. So don't panic if
you ever submit like 29 lines of changes
and get five or even more
review comments on that.
Instead make the the best out of that,
learn to become a better coder, better
contributor
and also
take the the feedback that the reviewer
provided to you
and learn
watching out for these things yourself
for the code you write on your own and
so you improve in both of those aspects.
Also of course whenever you get review
comments you should try to incorporate
that. That is kind of clear when you
want your changes being merged.
And overall you should stay responsive
and improve your code as you want.
Okay, the other thing is that you should
of course check what the right tool set
is, what topics you're interested in. So
if you are interested in contributing to
the Kubernetes manifest of course
Kubeflow community distribution is a
good place to start if you're interested
in one of the many controller code bases
that we have in the Kubeflow universe
you can start yeah, just check all of
those subprojects that own a controller
but we also have parts of the
code that for example the Kubeflow SDK
is in in Python and so there's a place
for everyone to contribute.
And the skill sets and tool that you
have
is one thing but the other one is also
what interested you. If you're
if you have a a big interest in
security, maybe find a place where that
is
that can be
taken care of or if you generally want
to do more DevOps related things,
figure out a place where that interest
can be fulfilled.
Also, of course, every cool
functionality needs a front end which
through which it can be used. And so
there is a big need, I think, in the
overall Kubeflow community for
really advanced people that know front
end pretty well because of course all
the controller folks and Kubernetes
folks are there,
but often times the contributors that
work on front end code are rather new to
both the project and coding overall. And
so experienced coders would be really
appreciated on that front, I think.
Yeah,
if you don't want to contribute in code,
of course you can always enhance the
overall ecosystem by providing high
quality bug reports
and help to triage the ones that that
are already there.
Just
yeah, take take a look at that.
Also, one thing you can do is
give the Kubeflow ecosystem a bit of
exposure by adding yourself to the
adopters file and
I will skip over the bug wrangling here
for time reasons.
Another thing that you can do to to help
in the Kubeflow ecosystem is to support
users
in one of the many communications
channels that there are. You can see
where you can help not only singular
users, but also the overall community
by mentoring people that are new to the
community, by helping in the process of
the graduation as we now heard a few
times which recently
happened. And so of course from now on
there's not much to to be helped there,
but overall the project will always have
tasks around governance and similar that
could use some help.
Also, if you are from another community
or
a big company, it's always interesting
if you bridge multiple
companies and communities and just bring
people together
and therefore create value in that
sense.
Um
Yeah.
If you have interesting hardware or
software
testing is always a a good thing to do
that you can do and just I don't know
check any of the pending merge requests
that you can test or release candidate
that's beta releases for example the
QFlow notebooks one that will be
released later today something that of
course you can test and provide feedback
on.
Um
We also of course can always use
designers or writers because often times
people are good at coding and not so
good at writing the actual text that
describes the features
and there are some tasks around
publishing that you can help out with
if you for example are a part of the or
if you help the outreach people in that
front.
Yeah, as as promised I want to spend a
few
words on AI
tool usage because I think especially
for new contributors this is something
where you could potentially
take fall into one of the many pitfalls
that there are and so of course pointed
this out earlier on you always want to
comply to the QFlow AI policy which
means that communication should happen
in in a
social and human fashion and of course
you can always use these tools to
get a bit of a better text output
generally it should be you that writes
with the contributors and reviewers in
the project.
You need to be able to verify and
explain your changes
and of course you need to make
transparent what agent you used and to
which degree you did so that the user
No, uh
reviewer knows what they're getting
themselves into.
And following on that, um my kind of
recommendation, and this may be a hot
tick a take, but I would recommend uh
beginners not to use AI tools um at
least as the main driver behind their
contributions for the reason that um for
example, verifying your outputs can be
kind of hard if you're not yet that
experienced. And you kind of cut
yourself a few corners um in the
learning process and therefore might not
learn as much. And so what I instead um
recommend to you is uh use AI as a tool
to ask questions about the code base and
get a better understanding about that.
Use AI as a sparring partner um to
discuss your implementation ideas and um
then like do the actual implement
implementation yourself um so you can
then later on have a good judgment about
uh for example, an agent output.
And you can use AI as a like
pre-submission uh review tool um to
catch uh mistakes that for example, um
then a human reviewer doesn't need to uh
spend time with.
Generally, also I can recommend from a
method point of view um to every now and
then just take a break and like stop
using all of the AI tools that you have
and see what gaps that kind of brings up
because that oftentimes tells you uh
what you can improve about yourself as a
contributor and what skill sets you can
refine further.
So,
now I uh said a lot of words. Thanks a
lot for for listening to this flurry
about um yeah, ways to contribute to the
Kubeflow ecosystem. And thank you all
for being awesome contributors and
making this community worthwhile to be
in.