Navigating Your First Kotlin Open-Source Contribution: A Mentorship Playbook

Overview

The first Kotlin Ecosystem Mentorship Program (KEMP) pilot demonstrated that structured, pair-based mentorship can turn newcomers into confident open-source contributors. In just two months, four pairs delivered meaningful improvements across Android UI, developer tooling, CI/CD, and multiplatform libraries. This guide breaks down the winning formula used by the grand-prize pair—Ruslan (yet300) and Clare Kinery (kinerycl)—and distills the process into actionable steps for both aspiring mentees and mentors. Whether you’re a developer who has never contributed to open source or a seasoned Kotlin veteran looking to give back, these instructions will help you replicate the success of the KEMP pilot.

Prerequisites

For Mentees

• Basic Kotlin proficiency: You should be comfortable reading and writing Kotlin code. Familiarity with coroutines, DSLs, and Android basics (if targeting UI projects) helps.
• Version control skills: Know how to fork, clone, branch, commit, push, and open pull requests on GitHub.
• Access to a development environment: IntelliJ IDEA or Android Studio with the relevant SDKs installed.
• Time commitment: At least 5–7 hours per week over the two-month duration.
• Willingness to communicate: You’ll need to join a Slack channel or equivalent, attend a kickoff call, and respond asynchronously on GitHub and chat.

For Mentors

• Strong Kotlin and open-source experience: You should maintain or have deep knowledge of at least one Kotlin project.
• Patience and teaching ability: Mentors in the pilot saw success when they explained concepts rather than just giving code fixes.
• Availability for a weekly synchronous call (one hour) plus asynchronous check-ins.
• GitHub project maintainer status (or close relationship with maintainers) to accept pull requests.

Step-by-Step Instructions

1. Select a Project and Scope

In the pilot, pairs worked on real Kotlin open-source projects chosen from a curated list. For your own journey, pick a project that:

• Actively accepts contributions (look for “good first issue” labels or a contributing guide).
• Matches your skill level. Example: Clare chose bitchat-android, an Android client with clear UI/UX issues.
• Has a responsive maintainer or mentor who can review code quickly.

What Ruslan and Clare did: They agreed on BitChat Android. Clare focused on UI and UX improvements—voice note styling, camera controls, dark/light theme support, visual hierarchy, and press feedback.

2. Kick Off with a Structured Call

The pilot’s successful pairs started with a kickoff call. Use this call to:

• Set expectations: How often will you communicate? (They used a mix of chat and GitHub).
• Define the scope: Which features or bugs will the mentee tackle? List them in a project board.
• Review the codebase architecture together. The mentor should point to key files and explain the build process.
• Agree on a timeline: Milestone #1 by week 2, etc.

Ruslan noted that after this call, Clare “adapted quickly to the codebase” and could work independently.

3. Work Asynchronously with GitHub as the Hub

All collaboration after the kickoff happened via chat and GitHub issues/PRs. Follow this workflow:

1. Fork the repository and create a feature branch.
2. Implement one focused change at a time (Clare submitted two PRs: #680 and #682).
3. Write descriptive commit messages referencing the issue.
4. Open a draft PR early to get feedback on direction before polishing.
5. Respond to review comments quickly (within 24 hours if possible).

Example PRs from other pairs:

• Kaustubh Deshpande (mentee, project Calf) updated dependencies and CI/CD automation.
• Anshul Vyas (mentee, FlowMVI) fixed a bug in the metrics module and wrote migration guides.
• Yu Jin (mentee, heron) improved input handling.

4. Balance Independence with Check-Ins

Ruslan praised Clare’s ability to “work independently after the initial alignment.” However, mentors should schedule weekly synchronous check-ins (30–60 minutes) to:

• Review progress against milestones.
• Unblock stumbling points that can’t be solved over chat.
• Discuss design decisions and Kotlin idiomatic patterns.

Don’t over-mentor; let the mentee drive. Clare demonstrated “strong problem-solving skills, attention to detail, and a solid understanding of UI/UX principles” because she was given room to explore.

5. Submit and Merge Pull Requests Before the Deadline

The program lasted two months. Aim to have at least one PR merged by the halfway point. Then iterate. For the prize drawing, completed pairs were eligible—so finishing is critical.

Common merging blockers and how to avoid them:

• Large PRs: Break into smaller, logical chunks (Clare submitted two).
• Missing tests: Add unit or UI tests for any new logic.
• Style violations: Run the project’s linter before pushing.

6. Retrospect and Celebrate

After merging, write a brief retro (like the pilot’s blog post). Share what you learned. Clare noted, “The biggest thing I learned was how open-source collaboration actually works. This program made it feel approachable and far less intimidating.” Celebrate the milestone—and in the pilot’s case, the grand prize winner received a trip to KotlinConf 2026 in Munich!

Common Mistakes to Avoid

Scope Creep

Mentees often try to fix everything at once. Stick to the scope agreed upon during the kickoff. BitChat’s improvements were specifically about voice note styling, camera controls, and theme support—nothing else.

Poor Communication

Reduce lag: respond within a day on GitHub or Slack. The pilot’s eight active pairs in the middle of the program likely succeeded because they communicated regularly; the two that dropped out may not have.

Skipping the Kickoff Call

Without alignment, mentors and mentees waste time. The kickoff is non-negotiable.

Over-Engineering

Remember this is a learning exercise, not a production rewrite. Keep changes minimal and focused. Clare’s PRs improved visual polish without touching architecture.

Neglecting Documentation

Write clear PR descriptions and update any in-code documentation. Anshul’s work on the migration guide shows that contributing documentation is as valuable as code.

Summary

The KEMP pilot proved that a well-structured mentorship program can turn first-time contributors into confident open-source developers. Key steps: pick the right project, hold a kickoff call, work asynchronously via GitHub, maintain weekly check-ins, and submit small, focused PRs. Avoid scope creep, poor communication, and over-engineering. With these guidelines, your own open-source journey can mirror the success of Ruslan and Clare—and you might even end up at KotlinConf 2026!