Onboard devs to your codebase faster 🧑💻👩💻 ⚡Supercharge developers editor 🤝help understand other people’s code faster 🔍save devs hours of searching through the company’s code context 🔌 index information from GitHub and Jira, on VS Code
Thanks for hunting us @fmerian !
What is Watermelon?
For software engineering teams that spend a lot of time reviewing pull requests, we provide an open-source copilot for code review.
We trace the code context associated with PRs from sources like GitHub, Slack, Linear, and Notion. Our system identifies errors in PRs, initially focusing on console log detection and comments on the line diffs. Taking these insights into account, we conduct a pre-review of PRs and assign them appropriate labels.
Why us?@estebandalelr and I have been developing software for the past 6 years and we've worked at companies of all sizes, from 2-person to 1,000-person companies. Code review was always a pain for us.
Devs spend 30% of their time doing code reviews, and 40% of PRs don't contain a description. Despite advances in AI for code, there hasn't been much innovation around solving this pain point.
We aimed to create a tool that goes beyond just a basic syntactic analysis of the PR.
Please help us with the following. We will highly appreciate it:
- Introductions to engineering leaders at companies who use GitHub.
- Star us on GitHub.
- Install Watermelon and give us your feedback.
Thank you very much, ProductHunt! 😄
Hey! Congrats on the launch! It’s looks very-very good and I’ll try to use it in my current project. I only scare that your teammates will become lazy reviewing PRs)
@kgrebenjukov Hey Kirill, we would also like your opinion about this.
We also want to introduce author behavior to the PR scoring system that ultimately creates a label. Eg: Reward the score of a PR authored by a dev that has commented and reviewed a lot of PRs. Penalize the score of a PR authored by someone who doesn't do code review.
Do you think would disincentivize lazy behaviors?
@helloteban What this score should say to the team? 1) that one dev reviewed bunch of PRs and other didn't? 2) Or that someone is doing it great?
I don't think that 1) is the real problem. In most of the team I was working there always was some kind of rotation in reviewing + tech lead views most of PR, often not in details but to ensure that team doesn't make huge mistakes.
For 2) it's very hard to measure a quality or review, because it depends on quality of PR. If PR is great, review could be "LGTM :+1". From the other hand the same review could be for a terrible PR. Who will judge? AI? Is AI is good in this area? Is team trust to AI? I don't think so. You also will face the problem, that people who doesn't really understand dev processes will trust by this AI generated label and could make a decisions based on it.
Another key point is the goal of such label? Who is target audience for it? There is a gold rule - celebrate publicly and provide negative feedback in private. Could we demotivate some team members by such labels? I think so.
Here is something from top of my head
@kgrebenjukov this is very insightful ty! This has been our train of thought:
- Not all dev teams have a round-robin PR review strategy. In the ones that do, what we're thinking about would incorrectly punish correct behavior. That's a great insight.
- Code review in our opinion, more than making developers become a linter to each others' code, should be about sharing context and learning about the codebase and the business together. Because of this, an important part of our vision is to contextualize PRs with way more than an all-too-common "LGTM".
- We're a copilot - not an autopilot - for code review. We pre-review PRs by adding a corresponding label, but we don't immediately approve or request changes on the PR. Same when commenting line diffs, they come with a comment, but not with a request to change.
- Some users really like the labels, others don't. We initially opinionated the product towards these labels, but very soon you'll be able to turn them off via settings. It's a taste thing.
But it's still very early and we iterate something every day! Your input is very valuable for this iteration process.
@helloteban@kgrebenjukov Great insights!
I'm usually the one pushing back on innovation on the product, I try to play safe and would like to talk more.
Watermelon
Watermelon
Watermelon
Watermelon
Watermelon
Watermelon