How to improve community-contributed PR velocity

[wesharper]

I'm extremely appreciative of the Meilisearch team and its commitment to its open source repositories. There is a massive amount of great work that has been done and I don't in any way want this feedback to come across as critical of the team or its contributions. Open source work is a privilege to be able to use, and I'm very grateful to any of the core contributors to this service, which has done wonders for my own team.

I have been tracking some great new PRs to the ruby and Rails SDKs/client libraries and have noticed that the review velocity for some of the work there has been slow. Some old PRs have been stale for some time. I really hate to directly ping core contributors to ask for reviews, but at the same time, I'm sure the team doesn't want its client SDKs getting too far out of sync with the core feature set.

• What is the best way for community members to help maintain and update client libraries in their domain without spamming the core maintenance team?
• Is there a vetting process for community members becoming PR approvers? Can we recruit some valued community members who meet some set of criteria?
• Are there intended and well-known CODEOWNERS for every repo that the community can ping when needed?

[wesharper]

@ellnix do you have any thoughts?

[curquiza]

Hello @wesharper,
Thank you for using Meilisearch! It's always great to get feedback from the OSS community.

Meilisearch is built and maintained by a small but dedicated team, and we strive to offer the best maintenance possible across our SDKs and libraries. I can say that managing everything is challenging on a daily basis! To stay efficient, we organize our work by prioritizing based on usage and impact. Our SDKs and libraries are ranked by scope (tier), which you can find detailed here: https://github.com/meilisearch/integration-guides/blob/main/resources/tiers.md.
Ruby and Rails are not tier 1, which may explain why responses take a bit longer. That said, priority isn't strictly tied to tiers—critical issues in tier 2 can take precedence over minor improvements in tier 1, depending on their impact.

On some repositories, we also rely on external maintainers, like ellnix, who help review, merge, and release changes. However, when they submit PRs themselves, they still need a final review from Meilisearch employees, which can sometimes introduce delays. Additionally, since these external maintainers are not Meilisearch employees, their availability varies based on their own schedules. While pinging them might help in some cases, it won’t always speed up the process.

Currently, the integrations team at Meilisearch consists of just @brunoocasali, @Strift, and me. Alongside our work on SDKs, we manage other tasks and prioritize them accordingly. We do our best to ensure contributions aren't blocked, but juggling everything efficiently is always a challenge.

Now, to answer your question 😁

• As an external contributor, you can help in many ways: creating or responding to issues, submitting PRs, and even reviewing PRs. While your approval might not count for GitHub directly, having feedback from the Ruby community makes our review process easier and is always appreciated. Since we are a small team, any help means a lot! ❤️
• We don’t have a formal process for welcoming new external maintainers yet. So far, we've invited active, efficient, and friendly contributors after they've made valuable contributions over time—if they’re interested, of course! 🤓 Would you be interested in becoming one someday?

By the way, I’m curious—how are you using Meilisearch? Are you self-hosting, or using our cloud solution? And which aspects of Ruby/Rails or our SDKs would you like to see improved for your project?

[ellnix]

To answer the original question, I'm not sure I have anything to add. This seems mainly like an understaffing problem. Not to put blame on anyone, I understand that it's important to focus on more immediate sources of income for the company to begin to turn a profit (hence the focus on cloud)

The specific problem with the ruby repos is that I am the sole maintainer on them. I've been able to contribute to rust, python, and js ironically much easier than these repos where I'm a collaborator. It's just the way open source works, I wouldn't even want the power & responsibility to push changes without approval: code review catches a ton of bugs.

---

To reply to what @curquiza added: I think it's a decent idea for users of the repos to leave reviews on any PRs that they have tested. That might allow someone from meili team who is not as familiar with these repos to give the final approval, since for any sizable changes only Bruno seems to have the experience to review them (or at least that's my impression).

---

It could make some sense to run an "edge" or "community" edition of the gem which develops much faster and does not inundate meili with bug reports. That way we could deliver features faster and have bugs caught before they appear on the main gem. However, I think even coming to an agreement on that would be more work than simply reviewing the PRs...

I believe sanders41 (community maintainer of meilisearch-python, I don't think he's meili staff) had some similar projects where he had his own forks of meilisearch-python with special features/rewrites like async support. See this comment from 2022: meilisearch/meilisearch-python#414 (comment)

[wesharper]

@curquiza I definitely understand your priorities and the necessity to make the most of pretty scarce resources. Coming from a small team myself maintaining a large internal application, I understand how quickly tasks stack up and how important realistic triage is. That tier list link is exactly the thing I was looking for to set a baseline understanding and I'll adjust my expectations accordingly.

I do think @ellnix's idea of making some sort of edge/alpha release branch available makes sense for those of us who have higher risk/bug tolerance and who prefer to be on the bleeding edge, although this doesn't necessarily make it any easier to deal with a high review volume unless there's some sort of alternate approval path; I'm not sure what that might look like in practice.

I wonder if there's any willingness to adjust the baseline policies for tier 2 and 3 libraries to have incrementally less official oversight (i.e. more relaxed approval restrictions) as they are inherently more community-driven and explicitly less supported by the core team. I would not want to put the brand's reputation at risk by allowing the community to sow chaos, but surely there is some sort of middle-ground. Perhaps marking tier 2 and 3 libraries as "community" and "unofficial" libraries might help mitigate brand risk?

Regarding your question about our usage:
Our team self-hosts due to our organization's stringent budgeting constraints, so I don't expect the needs of our small org to become an urgent priority any time soon. However, I would like to pay that back with open source contributions where possible (I would be interested in becoming an external maintainer if/when I've met that threshold).

Right now, our team is anxious to get federated search into our rails application and migrate from the ruby gem to the rails gem all-at-once. The rails gem provides some really nice quality of life features that make the swap from the ruby gem worthwhile, but we're waiting to migrate until first-party federated search makes it way to the gem. It's not an urgent blocker by any means, but the code cleanup we've been able to achieve on our test branch is substantial.