CIRCLE WITH A DOT

@chandlerc @meowray

Also, to your last point about LLVM struggling a bit with effective infrastructure use, it sounds like you have some specific ideas in mind that would be high value?

@AaronBallman @meowray @chandlerc

It's sad to hear that AI usage is having such an impact on reviewers. Ideally the AI policy lets reviewers push back on that and label contributions as extractive, but I think there are many AI contributions where they take much more time to review while not technically being "extractive".

Echoing other reviewer's sentiments, my experience reviewing PRs produced with AI assistance has been frustrating. There are usually many more rounds of review and you can't trust that the contributor actually thought about all of the changes that they made.

I still think AI can be useful in some limited contexts. But only people with a deep knowledge of the code base are going to be effective at using it for individual PRs, which are generally not the people actually using it.

I don't know if there's a good solution to this yet. I think tools like vouch are interesting, but that feels like too big of a compromise on fostering a welcoming community for LLVM specifically.

@chandlerc @meowray @shafik

I think our leaders do a good job of this. Most of our lead maintainers review much more code than they commit themselves. I've also found them to be reasonably encouraging towards new reviewers and care deeply about the experience for existing reviewers. I for one have started trying to do more reviews because of a call from a lead maintainer.

I'm not sure one can say that they have been effective at shifting an entire project's culture towards doing an effective number of reviews given that is not happening. But they certainly seem to be putting quite a bit of effort into trying.

@shafik @chandlerc @meowray

Yep. The incentive structures here are not naturally aligned to building a healthy open source community. Doing reviews for patches that might not provide immediate (or any) benefit is time spent that is harder to justify than time spent working on immediately useful features. But it is immensely important to the health of the community which is the reason any of this can happen in the first place.

Some places seem to realize this and others do not. I hope more come around as time goes on.

@chandlerc @meowray

I think in addition to code review not being prioritized by the community as much as it should (which seems to happen for a variety of reasons), LLVM also isn’t as good as it could be at turning contributors into maintainers interested in doing review. I don’t have numbers, but it seems like LLVM gets a lot of drive by patches where people might land a couple and then disappear. Even through structured programs like GSoC, it seems like only a couple participants in each cohort go on to stay involved in the project. A lack of people walking the path to maintainership I think leaves existing maintainers significantly more burdened.

I don’t have a good idea of why we as a community aren’t better at it. I think part of might be that people don’t feel empowered to review code. I wonder if a more structured review/code owner system might help with that. I also think part of it is that developing the expertise to properly review patches for a project like LLVM is an immense effort. I’ve recently been trying to pick up the number of reviews I’m doing to try and help with the review bandwidth problem, and I think the one main thing I’ve learned is how little I understand huge swaths of the main code base I’ve been working on for the past three years.