Passive documentation is the code context devs are generating as they talk about code in systems such as GitHub, Slack, Notion and Jira. Our search engine serves both our IDE extension (for individuals) and GitHub app (for teams).

As devs we know that there are certain PRs that stay unmerged for weeks or even months, not because of the technical complexity, but because of the debate that they produce around changes in the business logic: "Will this change really improve our metrics?" We know that non-technical stakeholders (managers and designers) can bring a more holistic view to these debates but code review is too technical for them. So we decided to build this with the premise of "let's contextualize devs with business logic".

We’re starting with a GitHub app that contextualizes Pull Requests with pieces of related passive documentation. Our big vision is to build a copilot for engineering leaders, starting by automating code review. If we're already indexing passive documentation tied to a new PR, we suspect that we can provide a "first health check" to a PR and say whether or not it's meeting the business requirements.

Here's the repo if you want to check it out: https://github.com/watermelontools/watermelon

And here's a blog post explaining why we made our search engine source-available: https://www.watermelontools.com/post/promoting-openness-star...

Please give us your feedback! Thanks.