We're Fixing Cline's PR Contributor Process

We really appreciate all our contributors who have submitted code, ideas, and other improvement to Cline. For me it's honestly been one of the coolest parts of being involved with this project. The creativity, expertise, and dedication I've see from our community has always blown me away. Thank you so much!

Current state

We've been working hard to merge as many community contributions as possible, but let's be real, our existing system isn't working. Our PR backlog keeps growing, and that's on us. I've been thinking deeply about how we can improve this process, and hopefully I've found something that can work.

I think a core issue is that, often when we get a PR, there's effectively been no conversation done ahead of time even to decide whether this change makes sense (wrt implementation, concept, impact, etc). And once we reach the code review stage, it gets significantly harder to meaningfully discuss and alter a feature. This is because our contributors have already made the effort to create the initial implementation - meaning if significant changes are required, this results in double the time spent both on our side for review as well as for our contributors for re-implementation.

I don't like how its sometimes felt there's a disconnect between the core Cline team and our community. It's not sustainable on our side, and more importantly, its not respectful of your time and energy.

Fixing the issue

Here's what we are going to do about this: we've implemented a new system that highly encourages conversation about potential new features prior to contributors creating PRs. For non-trivial changes, we are now enforcing that there is an associated issue created, either a feature proposal or bug report. It's honestly kind of a trivial fix, but i think it will have a significant positive impact.

We've updated our contributor guidelines and created a new issue template dedicated to detailing new feature requests. This gives all of us a chance to have meaningful discussions before any code gets written. Contributors will be able to outline their ideas, get feedback, and ideally together we can ensure that your contributions get into the codebase as soon as possible. This is specifically for feature requests, while PRs for resolving bugs will remain the same.

The idea is not to make this some kind of gatekeeping thing, but rather ensuring your valuable time is spent on contributions that will definitely make it into the Cline codebase. Also, on our end, we're increasing our focus internally on dedicating time specifically on reviewing community PRs.

The road ahead

I'm super bullish on Cline's future and on our open source community. We're only where we are today because of the great work by our contributors. Every bug fix, every feature, every improvement – they all add up to make Cline better for everyone.

Thanks for sticking with us as we figure this shit out.

-Toshi