How to communicate in a Pull Request?
Hi there! I'm Aritra, and let me tell you, I didn't have a clue about Open Source contributions or GitHub until 2018. My first PR to a big repository was a simple typo fix in the TensorFlow documentation (you can check it out here, though it never got in).
Fast forward a few years, and I've been fortunate enough to contribute to some incredible libraries like peft, transformers, and more. But enough about me — let's talk about something that’s really important when contributing to open source: how to communicate in a pull request (PR).
- Find or Create an Issue First
Before diving into the code, the first thing you should do is search for an existing issue that you’d like to fix. If there isn’t one, create it yourself. This is your first step in engaging with the maintainers, who will likely jump in and brainstorm with you.
Trust me, this part of the process is incredibly rewarding. You get to interact with people who might be a lot smarter than you (I always think of it this way, which helps me stay grounded and not feel overwhelmed). You will most certainly learn a lot about the repository and how things work.
To see an example, here's where I learnt about a new LoRA technique which was mind blowing.
- Crafting Your PR
Once you’ve identified the issue and are ready to create a PR, take your time with the description. This is not just a formality; it’s your chance to clearly communicate what your PR is about. The title and description should be precise and to the point.
I have never been able to perfect this craft, but I always try. I take immense pride in this PR description and title.
This clarity is crucial for maintainers and others in the community to understand your intentions and join the conversation. Who knows? Your PR might get reviewed by someone you admire, and that’ll make your day!
Benjamin says, "My approach is to craft a well written commit message and then re-use it (maybe with a few alterations) as the PR description. That way, the effort to write a good description is rewarded twice, once on GH and once in the git history."
- Overcommunicate (But in a Good Way)
As my friend/mentor Sayak Paul often says, "Overcommunication never hurts; undercommunication always does." Be as detailed as possible in your PR conversation. I’m a bit biased here, but if your PR is related to deep learning or Python, consider including Colab notebooks that reviewers can easily run, or Gradio links to a working model. These small steps can make a huge difference in how your contribution is perceived.
- Respect Others' Time
Always remember that the maintainers and reviewers are busy people. Avoid asking open-ended questions that leave them guessing. Instead, try to solve the problem on your own first. If you get stuck, list out what you’ve already tried and where you’re facing issues. Isolate the problem and include relevant code snippets in your PR. This shows that you respect their time and effort.
- Stay Humble and Respectful
Finally, be kind and patient, especially when someone asks a "not so mature" question on your PR. This might be their first time contributing to something big, just like you were once. A little empathy goes a long way—offer a helpful hand instead of a harsh word. After all, we’re all here to learn and grow together.
Hope you like it and will follow this in your own Open Source endeavour. I will get it reviewed by my fellow Open Source wizards. I am sure there will be a lot of edits, so come back after a week to get some better tips and tricks!
