💡 CNCF Buddy System

[leonardpahlke]

Hey all, inside the LF and CNCF we have quite a few mentorship and onboarding programs which are great to get started. For myself, I actually got started in the Kubernetes Community by applying to the Kubernetes Release Team Shadow program, so I can say for myself and many others in the community it works!

Once you are getting in to open-source collaboration and get to know your way around, this usually goes hand in hand with taking on other roles and responsibilities (code reviewer / approver, team lead, etc.). There is no need to create another onboarding program for these kinds of folks. But there are some other things which, I think, might be useful for us to improve on, 1) mentorship & 2) cross ecosystem collaboration. Likely dozens of ways are to improve on that. This is one option which I though about.

Buddy System Abstract

The idea of the buddy system is to bring “random” maintainers of CNCF projects that singed up for the program across the CNCF ecosystem together to discuss in short weekly 1:1 meetings their problems, their wins, and anything else. This could strengthen the community bond, onboard folks across projects and “disciplines”.

The process would be to sign up on a form each quarter and be randomly assigned 1 buddy (2 in total, you pick one randomly and someone picks you randomly) who applied to the program themselves (person A assigned to person B should not be assigned the other way around 😄). The program could go for a month (first month each quarter) or perhaps the entire quarter? Buddies organize weekly, ~20-minute meetings on their own. At the end of the program iteration, everyone fills out a form to provide feedback on the program, and the buddy program reopens for the next iteration.

Questions

• Who can participate? I think it's ok to have a program to strengthen the bond between maintainers of CNCF projects, so in this case it would be: CNCF GitHub Org Members
• Who facilitates this? Options: TAG contributor strategy, rotating volunteers, CNCF staff
• Can I by the buddy of person X? No, I mean yes, but outside this program since this would cause a lot of overhead to orchestrate.

Problems

• Time: everyone is very short on time and has loads of things to-do. I could imagine that this could “fluff up” the day and be a nice short “break out session” twice a week.

Some other comments I could imagine

• I don't like my buddy: well, … that's an opportunity to grow?
• I am travelling / on vacation / I liked it at first but not I don't have time: not a problem! Continue afterward.

---

I am not 100% sold on this idea myself until I hear folks giving their input 😄. This is of course just an idea / proposal for discussion, and anything can be changed 😄!

Leo

[w1593950]

Hi @leonardpahlke good thoughts.

I just wanted to share my budding system/experience with the Sacramento Kubernetes community and our work to support individuals pursuing certifications in Kubernetes and CNCF. Our community connects with students ( mostly underprivileged groups) and professionals to help them achieve their CKA, CKAD, and other Kubernetes and CNCF certifications. Personally, this has been a big win for me, and I’ve seen firsthand the impact it can have on individuals’ professional growth.

Over time, I found a few pros, cons, and value-added to this buddying system.

Pros:

1. Strengthening the community bond: The buddy system can effectively bring maintainers of different projects together and create a sense of community within the CNCF ecosystem. This can lead to increased collaboration and knowledge sharing across different projects.

2. Onboarding and mentoring: This system can help onboard new members of the community and provide them with mentors who can help guide them through the ecosystem.

3. Improving cross-ecosystem collaboration: The buddy system can encourage maintainers to work across different projects and disciplines, leading to increased collaboration and innovation.

4. Feedback and improvement: By soliciting feedback at the end of each iteration, the program can be improved over time to better meet the needs of the community.

Cons:

1. Time commitment: As mentioned, everyone is short on time, and it may be challenging for some maintainers to commit to weekly meetings.

2. Compatibility issues: There is always the possibility that buddies may not get along or may not be compatible, which could make the program less effective.

3. Limited impact: The buddy system may not be able to reach all members of the community, and it may not be the most effective way to encourage collaboration and onboarding for some individuals.

Value-added:

To maximize the value of this system, it is crucial to ensure that it is well-structured and effectively communicated to the community. This could involve creating clear guidelines for participation and expectations, as well as providing resources to support the buddy system. Additionally, it may be beneficial to track the impact of the program over time to identify areas for improvement and ensure that it is meeting the needs of the community. Finally, it may be valuable to offer incentives for participation, such as recognition or rewards, to encourage more people to get involved.

These are my thoughts. The mileage varies for other systems and other people.

[geekygirldawn]

I think this might fit under the Mentoring WG - @nate-double-u - I'd love to hear your thoughts on this idea.

[xinity]

the funny part is I've spoken with @k8tgreenley during Kubecon last week and suggested that we built kind of the same program for Kubecon.

I completely share the overall goal and I've run that kind of program back in the days during Dockercon 2017 to 2019

I follow the pros and cons given by @w1593950 ( my old pal :p ), one way to test on a small scale that kind of program before going out widely to the CNCF community is to test the concept during one or two Kubecon.

We can easily leverage CNCF ambassadors who join Kubecon to be mentors (voluntary basis) and create small groups (5 to 8 MAX) of Kubecon newcomers / Kubecon "shy" attendees.

The overall goal is to help CNCF newcomers who join Kubecon to be linked to a mentor who helps them enjoy as much as possible the conference.

I can definitely share materials and processes to build that.

If it works during Kubecon then we can open the program to KCDs to test bigger "implementation" and then success would push to CNCF chapters.

Like many of us already said, the main issue will be the commitment of the mentors, to make it works we can probably after a few runs look for incentives.

in a nutshell, I would first go for a Kubecon buddy system ==> KCD buddy system ==> CNCF chapters buddy system ==> CNCF wide buddy system. small groups, point of contact (physically or virtually), create engagement and collaboration with group members.

[leonardpahlke]

I'm glad to see the interest in this idea, it looks like we can actually do something with it 🤩. I saw comments which go into a different direction than the proposed idea, let me allow to clarify.

We can easily leverage CNCF ambassadors who join Kubecon to be mentors (voluntary basis) and create small groups (5 to 8 MAX) of Kubecon newcomers / Kubecon "shy" attendees.

in this proposal we don't have mentors. Its essentially about bringing experienced maintainers across the ecosystem together.

The overall goal is to help CNCF newcomers who join Kubecon to be linked to a mentor who helps them enjoy as much as possible the conference.

No, at least that is not the goal of my proposal. Perhaps the name "buddy system" implicitly suggests that.

We can of course change the idea to a buddy system to be maintainers <> non-maintainers, but that would undermine the core idea of building a program for "all ready" onboarding people to connect. Also as I described in the proposal we already have quite a few maintainers <> non-maintainers programs.

[kaiwalyakoparkar]

This is a really great idea, I primarily focus on bringing students and learners into the ecosystem so this would be a great platform for me to redirect and become an part of the effort :)

[parispittman]

Hi @leonardpahlke - so glad you are thinking about mentoring programs for maintainers :) I tried to run a buddy program in Kubernetes a long time ago and had similar pros and cons as @w1593950 listed above and ultimately decided to end the trial. Notable/largest reasons: The administrative pieces of matching folks and the back and forth of scheduling burned the team out and maintainers just didn't have the time, especially the ones that we needed to do knowledge transfers. Instead, we focused on some of the concepts I'll mention below:

I'm gearing up for a maintainers circle where we teach folks how to build shadow programs. The Kubernetes Release team, API reviewer team, Contributor Events team, and more are different from a buddy system because they have roles, role docs, and it's not an ambiguous mentoring arrangement which can burn folks out, especially already burdened maintainers. I think step one here is drawing up guidance on how to create roles, identify roles, etc. Want to help me? Also, with GSOC, Summer of Docs, Outreachy, and LFX, there are programs that reach the 1:1 audience although those have documented roles, too, with scope and goals.

Another avenue we went with for maintainers was group mentoring programs that are structured, time bound, and have a goal that everyone is trying to achieve. That goal is a rung on the contributor ladder which is already documented and scoped so everyone in the program is reaching for the same thing and we run education around the topics that are listed (example: how to code review with k8s style guide, how to manage your time, etc.). This is something I want to scale in CNCF projects, too. Want to help me here? :)

I think the most important thing to plan around is the maintainers time, making sure that both parties are getting something out of it, and that the mentee has intentions of sticking around.

[leonardpahlke]

Thanks all for you input sharing your experience!

From all the comments, I get that the idea in general can be very fruitful for the community, but it takes dedication and time commitment to do it right. Some comments told a success story, but some programs not much. @geekygirldawn talked about squishy maintainers at Kubecon EU last week (great keynote by the way!) - I think that applies quite well here and is also mentioned in @parispittman's comments about burnt out maintainers being the main reason for discontinuing the program:

Notable/largest reasons: The administrative pieces of matching folks and the back and forth of scheduling burned the team out and maintainers just didn't have the time, especially the ones that we needed to do knowledge transfers.

This problem (time, burned out maintainers, etc.) could again outweigh the benefits. One change in this proposal to improve on that is to make the buddy matching random to reduce administrative overhead, but this could lead to a less than ideal setting (see @w1593950 comment on "Compatibility issues").

making sure that both parties are getting something out of it

this could might be challenging to "guarantee" if its randomized..

The program would be well plannable with one month per iteration runtime for the maintainers (I dont have time next month due to K8s Code freeze, so I dont participate this round...).

I think lets gather more voices and see where this discussion about the Buddy System goes :)

---

@parispittman the "Maintainers Circle" and "Group Mentoring Programs" initiatives you mentioned sound very interesting - I could see that these ideas achieve the goals I described at the beginning 1) Maintainer<>Maintainer Mentoring and 2) strengthen the collaboration between CNCF projects and groups. Independent of this discussion about the buddy system, I am happy to support this effort :)

Because of my TAG role, I would be particularly interested in how we can possibly reuse the shadow program ideas you mentioned in the CNCF TAGs. At the last ToC <> TAG chairs meeting, I actually proposed this idea and everyone was very interested in exploring it :) soo lets do it :D

[xinity]

I'm glad to see the interest in this idea, it looks like we can actually do something with it 🤩. I saw comments which go into a different direction than the proposed idea, let me allow to clarify.

We can easily leverage CNCF ambassadors who join Kubecon to be mentors (voluntary basis) and create small groups (5 to 8 MAX) of Kubecon newcomers / Kubecon "shy" attendees.

in this proposal we don't have mentors. Its essentially about bringing experienced maintainers across the ecosystem together.

The overall goal is to help CNCF newcomers who join Kubecon to be linked to a mentor who helps them enjoy as much as possible the conference.

No, at least that is not the goal of my proposal. Perhaps the name "buddy system" implicitly suggests that.

We can of course change the idea to a buddy system to be maintainers <> non-maintainers, but that would undermine the core idea of building a program for "all ready" onboarding people to connect. Also as I described in the proposal we already have quite a few maintainers <> non-maintainers programs.

no worries at all, seems like indeed we weren't thinking about the same thing but using the same wording :)

I'll suggest the Kubecon buddy system anyway and see if it works :)

I'll be happy anyway to help in making your suggestion a success :)

[leonardpahlke]

no worries at all, seems like indeed we weren't thinking about the same thing but using the same wording :)

I'll suggest the Kubecon buddy system anyway and see if it works :)

Yes!

I'll be happy anyway to help in making your suggestion a success :)

Very welcome, thank you! :)

[aliok]

I think there are a few different ideas in this discussion:

1. CNCF cross-project buddy system (the original post of my understanding)

• 2 maintainers buddy up
• To have cross-pollination between projects
• To learn from each other: how to do community building, how to do run a project, etc.

2. Student / open source beginner mentorship program

• Maintainer and a less experienced person buddy up
• Mentee learns from mentor

3. Mentorship for non-maintainers to move them up in contributor ladder:

• Maintainer and non-maintainer buddy up
• Mentee learns from mentor

There are also mentions about group mentoring and others.

I think we already have enough programs for (2), GSoC, LFX Mentorship, etc.

IMO, I would encourage communities to do (3) but not create an official program across CNCF around it. So, @parispittman 's idea about teaching communities how they can start their shadowing programs is a great idea.

About (1)... I think it is a good idea. It basically has the same goals with the maintainers circle, as mentioned above: learn from each other's projects and communities. However, it is more of a 1:1, which is more effective.

I would love to see such program action, focusing less on the code but the community aspects. To give myself as an example maintainer: I am always up to having chats with a maintainer buddy from another project and learn what their projects are, where their projects stand in CNCF landscape, how they run their project, how they build and grow their community, what are their personal career advices, how did they become a maintainer etc. However, I wouldn't be so interested in learning technical details of other random projects though as I won't have time to go deep anyway.