DEV Community

VINAYAK GOTE
VINAYAK GOTE

Posted on

My First Merged PR in Zalando Logbook: What I Built and What the Review Taught Me

#opensource #java #career #automation

In my last post I wrote about why I started open source. This post is about the first PR that got merged for me in a big project: Zalando Logbook.

What is Logbook?

Logbook is a Java library from Zalando that logs HTTP requests and responses. If you work with REST APIs, you know why this matters. When something breaks in production, the first thing you want to see is what request came in and what response went out.

What I worked on

My PR added two things to Logbook:

  • StatusCodeBasedSink: a sink that makes decisions based on the HTTP status code of the response.
  • LevelBasedHttpLogWriter: a log writer that uses the status code to pick the log level.

The simple idea behind both: a 200 response and a 500 response should not be treated the same. Errors should stand out, and normal traffic should not fill your logs with noise.

It got merged in May 2026. You can see the full PR, the code and the review here: zalando/logbook #2301

How I approached it

I did not start by writing code. I started by talking to the maintainers on the issue, so I knew what they wanted before I built anything. Then I kept the change small and focused, wrote tests, and signed my commits.

Looking back, that order saved me a lot of pain. Writing code first and asking later is how PRs get stuck.

What the review taught me

Maintainers read very carefully. They do not only check if your code works. They ask:

  • Does this fit the style of the project?
  • Will this break anyone who is already using the library?
  • Is the naming clear for someone who has never seen this code?

Answering those questions made my code better than my first version. Reviews are slow sometimes, but they are free teaching from people who know the codebase far better than I do.

The part I did not expect

After my PR was merged, another contributor found a gap in my own work. The ECS sink did not follow the same status code behavior, so he opened an issue and then a PR to fix it.

My first feeling was a little embarrassing. But then I thought about it properly: this is exactly how open source works. Nobody ships perfect code. So instead of rushing to send a competing PR, I reviewed his one and left comments on the threshold behavior and on the docs checklist. You can read that discussion here: zalando/logbook #2379

That was a good lesson for me: reviewing someone else's PR is also a contribution, and it teaches you how others think.

What I would tell someone starting out

  1. Read the issue and talk to the maintainer first.
  2. Keep your PR small. A small diff gets reviewed faster.
  3. Take every review comment seriously, even when it feels strict.
  4. If someone finds a gap in your work later, treat it as part of the process, not as a failure.

What is next

In the next post I will write about my PR in the Adyen Java API Library, which shipped in SDK v42.0.0, and how it felt to see my change in a real release.

Proof of my work

Everything I write about here is public, so you can check it yourself:

If you are a maintainer, a recruiter or a team looking for someone who learns in public and likes to collaborate, my DMs are open. Tell me in the comments if you work with Logbook or want to contribute to it, I am happy to share what I learned.

Top comments (0)