Watermelon — Open source copilot for code review

@naveed_rehman there's a new breed of innovative tools adding AI to their products to expedite code review. That's correct. Being open-source is key to differentiation. As developers, we prefer to install open stuff. We trust those products more. In addition to that, I want to give you a glimpse of something that's already having a test PR: We'll give you the ability to choose your model of preference if you're more inclined towards an OSS alternative to Open AI such as Mistral. Beyond that and what's most important is that contrary to all these other products, we understand that we need to trace code context for LLMs to produce the best results.

@hosseinyazdi 100%. Repos with a lot of PRs are the ones that get the best use case. Very curious to learn: What is it exactly about the product that catches your attention the most?

@hosseinyazdi Messy repos are the ones that get the most out of us, do you have any examples we can look at?

@atsuhiro_teshima Woah that was very long ago! We were not even building a dev tool back then. It's been so long in retrospect. Thanks for your support! We've been thinking about adding something like this to our rules engine. For instance, we know that certain companies have a rule that says "a PR shouldn't exceed 200 LOC". What's going on around our heads is "how do we make this not so opinionated, but at the same time not so unopinionated as including the X number of LOC as a settings parameter?" "Is number of LOC the best proxy for everyone in the first place?" Would you please give us some advice on this? How do you recommend we think about it?

@yev_yev_yev Ty! Huge fan of Multiple here. Not yet but it's something we're planning to expand into very soon as it's something that we can very easily do on top of what we have already built. Can I ask, what language are you guys using?

@yev_yev_yev Do you have some examples we can look at?

We're using TypeScript. An example would be: ```typescript const someFn = () => { // const oldLeftoverVar = 10; const x = 5; return x; } ``` I want to detect/remove the leftover code

@sentry_co yes it is! We believe it’s very important to incentivize OSS. What other products have you seen do this very well?

@helloteban I adopted codebeat.co back in the days. Their growth hack: slide up in trending OSS repos 😂

@sentry_co Yes! We will still count, but we support open source.

@jonathandenney Thanks for your support! Hope we're adding value. Please let us know if there's anything we should fix or add.

@daxeelsoni thanks for your support! We’ve identified code review is a very common bottleneck for engineering teams, therefore we’re laser-focused on solving this. May I ask, is your team’s bottleneck more around velocity or stability?

@kgrebenjukov there are very promising AI powered dev toolchain - writing docs, writing unit & e2e tests and reviewing PR - awazing setup)

@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.

@matijash Thanks! Huge fan of Wasp BTW. Long story short: First, it's different. All dev tools have a name mixing the word "Git", "Code", or "Source" with some other word. We're gonna win by being different. Second, it has an emoji. Who doesn't like emojis? 🍉🍉🍉

@helloteban I agree with the logic! :D

@rohan_singhvi1 Thanks! Yeah the website does need some work. Are you on mobile or desktop?

@pekka Thanks for your support! Is there something in particular that grabs your attention?

@pekka Any feedback is welcome

@octocode Please do! First 500 uses are free.

@samabrika1 Indeed! Hope we can speed things up. Are you guys using GitHub?

@samabrika1 Awesome! I saw you guys started using it. Please let us know if you have any feedback for us!

@rep_eat Thanks, and more than happy to guide you through the process of using our product! Anything that you particularly like that we should double down on?

@amorimj Thanks! We'd love their feedback.

@santiago_saenz_ariza Thanks! Hope we're adding value. Quick questions: What should we improve? What are we doing well that we should double down on?

@helloteban the context indexing has been working fine, but the console log detection fails sometimes.