Question on the maintainer side of IssueCompass

[flyoung588]

I read the IssueCompass README and the framing is pretty specific: contributors waste time browsing GitHub, while maintainers using good first issue can still attract people without the right skills. The “actual GitHub activity → skill fingerprint → matched issues” flow seems aimed at making issue discovery less random.

I’m Ray, a founder working in an adjacent part of early open-source contributor/recruiting problems. This is a genuine question, not a pitch.

One thing I’m trying to understand: when you included the maintainer-side pain in the README, was that based on maintainers you’ve seen manually searching for or reaching out to potential contributors, or was it more an inferred counterpart to the contributor discovery problem?

A short reply is plenty.

[PaulBrytonRaj18]

Honestly, it was more from observing the pattern repeatedly in open source than from maintainers directly saying they manually search for contributors.

I kept seeing contributors spend a lot of time finding issues that actually fit their skills, while maintainers still got many contributions that weren’t really aligned with the repo or problem space.

So the maintainer-side pain felt like the natural other half of the same discovery problem.

Right now, IssueCompass is still very much in the MVP stage, so I’m mainly focused on improving the matching quality, contributor experience, and making the selection process more meaningful instead of just showing random “good first issues.”

I’ve also noticed some maintainers informally checking GitHub activity, past PRs, or community presence before engaging with contributors, which reinforced the idea for me.

Also curious from your side — since you mentioned you’re working in an adjacent space — what part of the contributor/recruiting problem do you think people are still underestimating the most right now?

[flyoung588]

Thanks for the honest read, Paul.

What I think is most underestimated: the asymmetry between the two halves. Contributor-side pain ("I can't find issues that fit me") seems consistently felt — contributors say it out loud. Maintainer-side pain ("I can't find the right contributors") gets inferred from that more often than it gets felt.

The maintainers I've talked to recently have almost all described contributor recruiting as something they're deliberately deferring until the product or first release is further along — not as an active pain they'd pay to remove now. A few have even reframed it: "this is a find-my-first-real-users problem, not a find-contributors problem."

The implication isn't that the maintainer side is fake. It's that it may be a problem maintainers acknowledge but don't feel acutely — which is a different shape than the contributor side, and probably a different product.

Genuinely curious what you've seen on your side: has any maintainer come to you with a story where their own recruiting pain was the trigger to look for IssueCompass-shaped help (vs landing because of the contributor-discovery angle)?