Contributing to Haskell Through a Beginner’s Lens | The Haskell Programming Language's blog

Contributing to Haskell Through a Beginner’s Lens

Vidit Odedra May 31, 2026 [HLS] #GSoC #activities-report

October 2025 was when I wrote my first line of Haskell. Fast forward to May 2026, I am consistently contributing to the Haskell Language Server (HLS) and my Google Summer of Code proposal also got accepted. This blog is a mix of my personal experiences along with general learnings that could help beginners to start contributing to Haskell repositories.

I came across Haskell as a language through X creator ( formerly twitter ), Dmitrii Kovanikov. I had experience with TypeScript, so types weren't new to me. Haskell though, made me feel like I'd only ever seen the surface of what a type system could be. Like any other student, my first intuition was to do a university course. I found and participated in the University of Pennsylvania’s (UPenn) Haskell course. It is a 12-week course, fully textual and fully assignment oriented. Solid structure, but honest warning, it gets boring. I barely made it through.

This was the point where I wanted to go beyond assignments, because building a real project felt like a far better way to truly understand the concepts. I had two ideas in mind: a small compiler or a chess engine, with the former seeming much more approachable because of the abundance of available resources. Around this time, I also interacted with an HLS maintainer for the first time, who guided me through setting up HLS and suggested a few projects to explore. I followed the instructions, built HLS locally, and started browsing through the issues while slowly setting up my compiler project on the side. That’s when I stumbled upon a feature request interesting enough to completely pull me away from the project idea and make me go all in on contributing instead. It was also the very first issue I had ever worked on, and going through the full contribution cycle taught me more about git than my previous two years of casually using it ever did.

Since then, I have made multiple contributions to HLS. The biggest challenge I faced initially was to find good issues to work on. I have made a small checklist that I use to find issues to work on :

Don't over-filter when searching for issues. Most repos have "good first issues", feel free to explore and solve them, but avoid narrowing your search too much upfront.

Make sure to first and foremost, replicate the issue locally. All issues have replication steps and environments specified in their description.

Visualise the fix. Generally it is a good idea to describe the solution or procedure to follow in the comments.

The more important thing to keep in mind is working on issues that are impactful. A great way to identify these, is to simply ask. Haskell’s official website has a community page where you can find ways to contact other fellow haskellers. For example the HLS community is fairly active on Element, and like most open source communities they'll be happy to point you toward meaningful issues if you're not sure where to start.

Anyway, it's 2026 and having any tech conversation without mentioning AI would be criminal. Haskell, of all the languages I have ever learned, has one of the steepest learning curves, so it would only make sense to use these tools during this process. I still am an old head when it comes to AI usage and writing code with it. I heavily believe that handwriting code builds muscle memory and improves your understanding. Don’t get me wrong, I did extensively generate code, but also made sure to follow these rules :

Never use a harness, at least in your early learning phase. Harnesses are really good at finding where to write a particular piece of code and hence eliminate the entire process of exploring different files and looking over where to write code. This process despite being unrewarding can help you gather a lot of context of the codebase. This is how I have personally found many potential next issues to work on.

The old way of using web LLM providers to ask questions and then type them or worst case scenario copy and manually paste is what I follow and has helped me.

Also, Never let your AI tool write comments. GHC, HLS and other Haskell repositories follow Haddock comments. Handwriting this yourself at least makes sure that if a function is black-box coded, you at least know what it is supposed to do. It is also noteworthy to mention in the comment if it is actually black-box coded, this can help improve the review process.

With this we have covered how to find issues and start contributing to them. Now, let’s talk about something equally important: contribution variety. Large codebases like HLS and GHC are made up of many different areas, each offering a unique experience. During my contribution journey, I worked on multiple parts of HLS like different plugins, Cabal-related issues, Stack builds, and even Git workflows....