Thanos & Prometheus Mentorship

Both Thanos and Prometheus projects participate in various, periodic mentoring programs.

Follow us on Twitter to be up-to-date with application process and announcements.

Programs we participated / are participating:

• LFX Mentorship (previously Community Bridge)
• Google Summer of Code
• Red Hat Beyond

For Mentees

You have been selected for mentorship with Prometheus or Thanos? Congratulations! Here is some short quick information for a quick start!

Onboarding Check List

• Please see and acknowledge our Code of Conduct. A similar one is for the Prometheus project. TL;DR: Be nice and friendly!
• Create an account on the CNCF Slack. Please add any profile photo to make it unique. (: This is Thanos's main chat provider. You can reach any of the mentors there.
• If you are a Prometheus mentee OR if your task will involve collaborating with the Prometheus project, it's also recommended to set up an IRC account e.g by joining Element. This the main channel Prometheus Team is using currently.
• Send your mentors your slack account handle, so we can join you to private channels. We have one with just you and your main mentors, and second with all mentees, ex-mentees and mentors.
• Join main Thanos channels and write a few sentences to about yourself, say hello! 💜
• You are welcome to join Twitter, start following others and gather your own followers! Who knows maybe you will get addicted? (: Feel free to post any related content around Thanos while mentioning @ThanosMetrics.
• Ask maintainers to set up some weekly 2:1 meeting (highly recommended).
• Read our contributing guides
• Read carefully your main GitHub issue and start thinking about it, but don't stress out! It's better to start slowly with a smaller task to get things going. 🚀

Suggestions

There are certain rules you can follow to make the MOST from your time with us!

• Blocked on the PR, looking for someone to review your contribution, or have some quick question around failed CI? Prefer public communication channels. Both Prometheus and Thanos have a large community that can quickly help you with any issues. There also other mentees who might have had similar questions already! (:
• Say hello to fellow mentees and ex-mentees. We even created a special channel for that goal, so you can team up and build something bigger together: Relation, maybe a future project together or just helping each other out! Take an example from Summer 2020. Previous Thanos mentees started Friday fun hangouts without mentors knowledge and it went pretty awesome! Want to start something similar? Ask fellow ex-mentees for their tips. 🤗
• Think out of the box. Do you feel like something is really painful in project development, functionality or community? Help us improve things and suggest improvements!
• Participate in the Project life cycles. We are active in many conferences e.g. KubeCon, PromCon, FOSDEM, GoDays. We participate in the CNCF SIGs, many side initiatives, blog posts and videos. Please help us! You are welcome to boost your social media visibility, start blog posting, or even start talking at conferences. Feel free to ask your mentors for guidance on whatever you are passionate with! We would love to help.
• You are welcome or even encouraged to contribute to anything you want during your internship. It's common to wait for a review of your PR some time (it's open source after all!), so it's not uncommon to drive 2 or 3 things at the time. You don't need to limit contributions to Thanos project as well. It's totally ok to contribute to some other project we depend on or relate (e.g Yash was heavily contributing to go-grpc-middleware). It's also encouraged for Thanos mentee to contribute to Prometheus or Cortex and vice versa. This is because we are part of a bigger Prometheus Ecosystem Family.
• Try to be independent and responsible for the feature you want to deliver. The sooner you start to lead your task, the better for you! It's hard in the beginning but try to think about the user experience. Is it hard or easy to make mistake using it? How difficult is it to migrate to this feature? Is there anything we can do to reduce data loss errors?
• Try to help others by reviewing other contributors, mentees or mentors' Pull Requests! It sounds scary, but this is actually the best way to learn about coding practices, patterns and how to maintain high quality codebase! (GIFs on PRs are welcome as well!)
• Try using an iterative process for development. Start with small and simple assumptions, and once you have a working example ready, keep improving and discussing with the mentors. Small changes are easy to review and easy to accept 😄.
• Try working out a proof of concept, which can be used as a baseline, and can be improved upon. These are real-world projects, so it's not possible to have a deterministic solution every time, and proof of concepts are quick way to determine feasibility.

At the end of mentorship, it's not the end! You are welcome to join our Community Office Hours. See this for details. This is the meeting for any Thanos contributor, but you will find fellow current and ex-mentees on the meeting too.

Mentees Meetup

In order to allow mentees to share the knowledge their learned and allow them to improve public speaking skills, at the end of mentorship cycles we can (optionally) organize virtual "Mentees Meetup". How to organize it:

1. Talk to mentees, check if at least two mentees are interested to present the state of their project or what they learned and how. On top of presenting, check if they are interested in organizing meetup together (organizational skills!). Check if mentors have time to help organizing too.
2. Help mentees to propose the title, description and outline for 15-20 minutes talk with 5m Q&A.
3. Consider preparing the agenda of the meetup with mentees talk first then with the "Learnings" talk.

Potential flow of learning talk is to have mentors go through some filtered list of learnings we gathered from retrospective. On the talk, all mentees might be part of the meeting to chime in anytime and have it more discussion oriented with Q&A time.

1. Find a suitable time slot, typically 2h in the evening.
2. Announce meetup on (...) platform. Describe agenda, mention timing, how to join, Code of conduct and who is a target audience!

Target Audience: Other potential mentees, students, other project mentors and community who would like to teach others more, potential Thanos contributors

1. Choose MC! (Someone who leads the meetup).
2. Create Zoom webinar on Thanos account (use cloud recording).
3. Perform it! (:

For Mentors

This section explains processes around selecting mentees and conducting retrospectives.

Retrospective

On the last meeting of the mentorship we want to finish with some actionable learnings. The experience of both Mentors and Mentees is always different due to differences among us, different task and circumstances. We always want to summarize our experience, no matter if we met the initial goals or not. If goals were not met, then it's extra important to discuss this in honest, blameless atmosphere. If the experience was mostly positive we also want to know what worked to reinforce best practices.

The example retrospective process looks as follows:

• Week before last meeting Mentors are reminding Mentees about the last session and how retrospective will look like. This allows everyone to think through the week about things that worked and not.
• On the last meeting, start first with retrospective. This is the most important part of meeting, don't let other things (e.g project status) to get in the path.
  • Write in the Working doc 2 sections: What we did well, What we could do better.
  • Give everyone 5m to write down (e.g live) items in those two sections. Be specific, blameless and honest. It's not about offending anyone, but looking for improvements for both Mentor and Mentees work. Be critical to yourself, but also try to balance the good and to improve parts. There is always something we could do better or worse.
  • When everyone has finished, create new section: Learnings.
  • Go through all elements on the list. Discuss the details. Try to find ideas how to mitigate problem or what to continue doing. Write down those things in Learning section.
  • At the end share the learnings to the team on mailing list.
  • Consider composing all learnings into nice presentation we can show in Mentees Meetup

Mentees Selection

This section is to help guide mentors, old and new, on how to select mentees for Thanos mentorship projects. It details recommendations and steps for this entire process.

Process

We follow these steps when selecting mentees for any given project:

1. After your project has been proposed to a particular mentorship program like LFX or GSoC, ensure that it is discoverable by potential mentees during the application period by sharing it on the relevant GitHub issue. You could also optionally share this on the #thanos-dev slack channel, Twitter, and even during Thanos Contributor Hours.
2. Wait for the mentee application period to end and log into the relevant portal for the mentorship in order to view mentee applications. You can refer to the relevant documentation that you will receive to familiarize yourself with the portal, application format, and selection deadlines. Additional reference: LFX Mentor docs, GSoC mentor guide.
3. Discuss with your co-mentors and shortlist roughly 30% of the mentees that you've found to be suitable by referring to their applications, which can consist of things like CVs, proposals, and "statement of purpose" type questions. Refer to recommendations for what to keep in mind while shortlisting.
4. Send an email with a few extra questions to get to know these 30% potential mentees even more. You can refer to the [email protected] mailing list for a list of such questions and the email format from past mentorships. Make sure to add mentee emails to bcc and your co-mentors and [email protected] to to. Set a deadline for the responses.
5. Once you receive replies from most of them, review again with your co-mentor and shortlist candidates that you would now like to interview.
6. Conduct 20-minute interviews (refer to recommendations for what to keep in mind during these interviews) of the shortlisted mentees to get to know them even better and finally select a single person.
7. Send an email to the selected mentee asking for confirmation and if they are happy with this.
8. Once they reply, fill out the selection form in the relevant portal! :)

Recommendations

During mentee selection for our various mentorship programs, we want to follow some best practices to ensure that the mentorship is a fruitful experience for both mentees and mentors. A large part of ensuring this is selecting the most suitable candidate for the mentorship!

This process is hard and requires time, as it involves holistically looking at mentorship applications and trying to ascertain if they would be able to benefit from this mentorship and ideally become a contributor, maintainer, or even new hire into the respective mentor's company in near future.

We have been able to distill some learnings from several past mentorship programs, which are listed here as recommendations to mentors:

• Encourage mentees interested in applying by asking them to look through our issues and try to work on one in which they would learn a bit about the codebase! There is no better proof of their motivation to work with us than seeing (meaningful) activity in the open-source project before the selection period.
• Allocate some time upfront for this process, as you might have a lot of mentee applications to look through.
  • If possible, book some time on your calendars and discuss the selection process with co-mentors in a particular quarter beforehand.
• Try to have some prerequisites in mind while shortlisting an application of a potential mentee (CV/questions/proposal/interview),
  • It is preferable to have mentees from historically underrepresented communities in tech, to ensure diverse contributors in Thanos.
  • The mentee should be able to allocate enough time to the mentorship.
    • Thus, having prior important commitments like a full-time job or large educational course load can lead to mentees not having enough time for the mentorship, even if they claim to commit to working > 30hrs a week. This could manifest as mentees not having enough energy to think about a project, skipping meetings, and not being able to utilize the time mentors can spend with them. It is hard to help them in such case. So it is better to practically judge the amount of work a mentee would be able to balance before selecting them.
    • Generally, we expect our mentees to be university/college students who would be able to balance both the mentorship and a moderate amount of course load. Commitments larger than this would need to be treated with some caution. Generally, it's only ok to have a full-time job only for more senior engineers who understand how to organize their work, be transparent about the mentorship with their employer, etc.
      • In case the mentee is employed full-time, asking for some form of proof (letter/forwarded email from manager) that their employer approves of them working on this mentorship is preferable.
  • It is preferable for the mentee to have at least one prior contribution to Thanos or its dependencies that affect it indirectly. Such prior contributions demonstrate a willingness to engage with the community and independence from the potential mentee.
    • However, the contribution should not be a minimal effort one, such as a typo/grammar fix or variable name change. While these are valued contributions, they cannot effectively demonstrate mentee effort. A better indicator would be some change to the code or documentation. Note that this contribution doesn't need to be in a merged or finalized state and can be open.
  • The mentee should have access to a stable internet connection over which they can attend regular video calls with mentors (can be ensured during a 20-minute interview).
    • As most of the discussions (meetings/issues/reviews/code comments) are conducted in English, the mentee should be able to communicate well (verbally and in written) in English (first/second language).
  • The mentee should have some form of local development environment setup that they can operate which would not require the mentor to constantly debug the mentee's environment while working on the project.
    • This is hard to ensure fully, but generally the mentee should be working on linux/linux VM/macOS/, so most generic GNU/BSD commands are compatible.
    • The mentee should have basic git, bash, and programming knowledge.
    • They should be using a common code editor with IDE functionality for Golang, e.g. VSCode, Goland etc, that they can operate comfortably for the duration of mentorship. The editor should allow them to easily navigate code and lookup definitions across large codebases as this makes it easier to pair program and share knowledge with them.