Watermelon

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

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