Would the scip-code org consider adopting the remaining indexers?

[grinidx]

scip-java, scip-go and scip-rust moved to scip-code when SCIP's governance became independent. scip-typescript, scip-python, scip-clang, scip-ruby and scip-dotnet stayed under sourcegraph. I do not know whether that split was deliberate or simply where things stopped, so this is a question rather than a proposal.

The reason for asking is that the split has started to track activity. As of today:

Repository	Org	Last push	Open issues and PRs
scip-java	scip-code	9 Aug
scip-go	scip-code	9 Aug
scip	scip-code	6 Aug
scip-clang	sourcegraph	8 Aug	46
scip-typescript	sourcegraph	7 Aug	53
scip-dotnet	sourcegraph	1 Aug, no commit to main since 27 May	33

That is not a complaint about anyone's priorities. Sourcegraph have been straightforward about them: on scip-dotnet#61 a maintainer wrote that they have "no plans for any new features in SCIP indexers in general" and are "focusing on support, prioritising customer support". That is a reasonable position for a company to take, and it looks like exactly the situation the governance transition was designed for.

I have a concrete case, which prompted the question rather than being the point of it. scip-dotnet does not index Razor or Blazor. Those reach the compilation as source-generated documents, so iterating project.Documents misses every one of them: on a scaffolded app that is 0 documents for 7 .cshtml files, and 0 for 11 .razor. I have a patch, open as scip-dotnet#117, with the existing snapshots byte-identical across net8.0, net9.0 and net10.0. It has not been reviewed, and four other pull requests there have been waiting longer, so I do not read that as anything personal.

I am not asking anyone to merge that patch. I am asking whether the adoption model already used three times might suit the indexers that were left, and if so what the process would be. If the answer is that the split was intentional and those repositories are staying put, that is a perfectly good answer and worth knowing.

I would be glad to help maintain the .NET indexer if that were useful. I have been working in that codebase, I have a fork with the Razor work in it, and I would rather contribute upstream than fork permanently.

For completeness: scip-dotnet is Apache 2.0 with no CLA, so forking is available and needs nobody's agreement. I would much rather not. A fork would split the ecosystem, need a new name under the trademark clause, and leave .NET users choosing between two half-maintained indexers. Asking first seemed better.

[jupblb]

The effort to migrate the indexers started at the end of 2025. Our initial vision was to update the indexer implementations with the newest compiler and language features and bring them into compliance with the latest SCIP version. This was our approach when migrating scip, scip-go, and scip-java (+scip-kotlin).

I was against simply dumping stale codebases into the scip-code org, as such an initiative wouldn't help build a community around them. The indexers under the Sourcegraph org require an upfront investment to make them easy for others to work with.

This is especially important when using AI agents. Running them on projects that lack proper foundations will likely lead to a lot of spaghetti code. I'm not sure we would have the capacity needed to review such contributions.

CC: @peterguy @emidoots

[grinidx]

Thanks, that's a clear answer and it corrects my assumption - I'd read the split as where things had stopped rather than as a policy. Modernise first, then move, makes sense.

On the AI-agent concern, which I think is the fair one to raise: I'd rather answer it with the diff than with reassurance. #117 keeps every existing snapshot byte-identical across net8.0, net9.0 and net10.0, adds a snapshot fixture in the project's own style rather than asserting by hand, and leaves dotnet format --verify-no-changes clean. If it had generated review burden, those are the three places it would show. Happy to be told it still does.

On "requires upfront investment", it would help to know what you'd count as ready. From the outside the gap looks concrete rather than vague - scip-dotnet's vendored scip.proto predates a fair bit of the current schema:

• no typed_range or typed_enclosing_range, so it still emits only the deprecated encoding
• no Document.position_encoding, which matters for anything consuming indexes from several languages
• SymbolInformation is missing kind, display_name, signature_documentation and enclosing_symbol
• no Document.text, Occurrence.text or Occurrence.language

If bringing that up to the current spec is roughly the bar, that's a well-defined piece of work and I'd be glad to do it, in reviewable pieces rather than one drop. If the bar is something else, or if scip-dotnet is low enough priority that it isn't worth anyone's review time either way, that's a perfectly good answer too and I'd rather know than keep asking.