Thank you Aaron for starting this thread. This is an area I have been thinking a lot about. I’ve had many conversations through our Community.o events and at round tables at the LLVM Developers’ Meetings that Code Owners is an area that we need to rethink and improve. I think that there are three main parts to this discussion.
1 - How to determine areas that require code owners (such as you did with Clang)
2 - Defining the responsibilities of a code owner
3 - Defining the process to become a code owner
I think part 1 can be discussed in a separate thread in the specific parts/sub-projects areas on Discourse and I won’t go into it here.
Responsibilities of a Code Owner
Currently, the role of a code owners is mostly focused on code review but I feel its a missed opportunity to provide some real leadership in the LLVM community. Code owners should not being doing all the work, but should be fostering the next generation of contributors and mentorship is key. I would like to see code owners selecting other individuals to review code first and then they can do another review. How they respond to that first reviewer should be positive and encouraging, but also provide suggestions. Often individuals need someone to recognize them and encourage them to feel they have permission to do a review.
I also believe that code owners should be a neutral party that helps mediate difficult design decisions and resolve conflict. This is probably what Aaron means by “final decision”, but I would like to view it as a mediator type role first. This actually isn’t really described in the current documentation except for when it comes to releases (AFAIK).
So at a high level, I believe Code Owners main responsibilities should be: Ensuring reviews/code quality, providing Mediation/Conflict Resolution for design decisions or changes, and providing mentorship to grow the community of reviews/contributors.
I would love to see a Code Owner guide and code owner training as well.
Becoming a code owner
Regarding the process to become a code owner, it is very vague right now. Do you nominate yourself? Does someone have to nominate you? How many “votes” do you need to be “approved”? It’s very intimidating and it feels like you have to be “well known” in order to even think about being a code owner. It feels like this happens behind closed doors if you know the right people. This process needs an overhaul. I think we need a way to provide anonymous feedback and have a higher level body that is overseeing code owners to ensure fairness and an even distribution of representative companies involved and diversity within the community. It is for sure a balance of “who does the work” versus having an open source community just catering to one organization’s needs.
I also feel that we need to encourage more minorities within our community to become Code Owners. We can’t just rely on people to raise their hand as that historical has not worked to improve diversity. We need to be actively thinking about this when we “nominate” folks to the role. We need to accept that we may have never met these individuals or have any relationship with them, but they are working hard to make LLVM and it’s codebase better. It can’t just be people we know that get promoted into these roles. We have to get outside our comfort zones.
Personally, I would love to see more women in the code ownership role. While this may not matter to some, it matters a lot to me (and I suspect many other women) and I believe it has an impact on the next generation of compiler engineers and open source contributors. Women and other minorities have often not volunteered for roles because they don’t feel “expert enough” or that it would positively impact their career. Open source work is often done in someone’s free time and we need to get companies on board with valuing its worth and considering it important enough to impact promotion and career trajectory.
We should also have a clear path for people to step down as code owners or be removed from their position. We often have folks who change jobs and don’t update their information and seem to drop off from contact. It shouldn’t be a big deal to remove them and move forward. While I want to thank and reward folks that have served in Code Owner roles in the past, I’m not sure exactly where we do that. We want the Code Owner documentation to be clear and easy to understand. It should be maintainable for years to come.
Lastly, there have been situations where we need a higher level group of individuals to help mediate disputes between an individual and a code owner. This doesn’t happen often, but if it does, we do need to have an escalation path so that all viewpoints are considered fairly. Otherwise, there is no way for an individual contributor to appeal a code owner’s decision.
That is a bit of a brain dump, but I look forward to discussing this more.