Finding more reviewers and core maintainers


#1

Probably fairly obvious, but the long term sustainability of the project requires people. The project grows and people move on so it’s crucial for a healthy project to find more reviewers and core maintainers.

Various core maintainers have been having some informal chats about finding more reviewers and core maintainers. While there’s no plan, we have some thoughts. These are all my own interpretation and I’d be happy to be corrected. It’s also incomplete so we are actively looking for more feedback. Since we’re all already core maintainers, it also means that by definition we were not the target audience. Again, input needed :slight_smile:

First off all, I’d like to share the handbook and the Fedora Review Process. These are both very formal processes, but if I look back on my personal experience I’ve always gained commit access by doing the work until someone was tired of having to merge all my patches. Another personal anecdote: I never became a Fedora Packager since it was too much of a formal process. My reason for committing was always to scratch my own itch: fix bugs and/or introduce features I needed. If the effort to become maintainer was greater than the effort to work around it, I wouldn’t do it. This leads me to think that we should ease up on the process and just make sure maintainers don’t do anything (too) stupid and if so, how to minimize the impact.

Ways to achieve that are more tests that can prove various workflows still work. However, we didn’t discuss that (yet). Instead, we focussed on the concept of a mentor (or sponsor as Fedora calls it). Common reasons people don’t review are a lack of time, being unfamiliar with some areas and being unsure about how to do it.

While a mentor can’t magically create time (if you do know, please tell me), a mentor can help with unfamiliar areas and guide you to people who would know. They can also advise when you get stuck.

We’ve also talked about responsibilities. There’s generalists who know the entire project (well, probably nobody knows it all) and specialists who know certain areas. The current process is aimed at generalists but specialists are also needed for the deep knowledge of certain subsystems. Somebody who knows bare metal provisioning but knows nothing about UI should still become a maintainer. Along the way they can collaborate with others to make sure the UI part works and perhaps even learn it from others.

Right now we have identified a few people who we think should either have already been a core maintainer according to their contributions or are very good candidates. We’ll approach them informally to see whether they’re interested and how they think about a mentor.

From everyone else we’d love to hear their thoughts. Perhaps ask yourself if you could be a maintainer and if so, what would be needed.

If there’s a desire for direct communication (for example because it’s personal), reach out and we can work something out (IRC, video conference, other). I’m not the only one on the core team and maybe you feel more comfortable talking to them instead of me, I’d understand that :slight_smile:


#2

I’m really happy to see these changes to the reviewers/maintainers process.

I agree with this and I’ll add that I believe it’s unnecessary for maintainers to be an expert in both ruby/rails and react/js.

I’d argue that if we’re going to require react/js maintainers to learn ruby/rails and review ruby/rails PRs then we should also require existing ruby/rails maintainers to learn react/js and review those PRs as well.


#3

I’d even argue it’s practically impossible to be an expert in both ruby/rails and react/js while also knowing the problem domain we’re working in.

IMHO a maintainer should know how to get the code in a mergable shape. It can be sufficient to collaborate (whether it’s writing or reviewing) with someone who does know the right area(s). Over time it’s very likely they will pick up a thing or 2.


#4

In my opinion a core maintainer needs a decent knowledge of both ruby and javascript for core. A maintainer does not need to be an export in both languages, but should have some experience with both the languages and the frameworks we use. I’d be having a really hard time accepting a new maintainer who does not have a good grasp of the rails framework for example.

I think maintainers have to be generalists and I don’t think we should lower the barrier for someone to become a maintainer if he just knows a small part of the project. I believe a good understanding of the workflows and what users require is more important than programming skills.

I agree that the current maintainers don’t do a good job of reviewing UI PRs. In my opinion the PRs are simply too big and it’s hard to see from the diff what has changed.

In my opinion, it comes down to responsibilities. If something is merged in core, it is expected to not break a lot of code in a bazillion other repos across a lof of github organisations (plugins, packaging, katello, …) I believe we should set the goal of what core can provide and have proper test coverage for that. Other stuff (like plugins) is other people’s responsibility.
I think only by focussing on core, having clear expectations what is supposed to work and having tests to ensure the quality a maintainer can merge code with confidence.