Move specs into separate repo with harder voting gate

[wjones127]

TDLR: What if making a format change proposal is just making a PR? And voting +1 is just approving that PR? And enforcing 3 votes is just a branch protection rule requiring 3 approvals?

We require design proposals and PMC votes for changes to the core format (file format, table format, etc.), but in practice this isn't working well:

• The requirement isn't widely known or consistently enforced — format-affecting changes regularly land without a proposal or vote.
• Nothing structurally prevents it: in the main repo, both committers and PMC members can approve and merge, so "this needed a vote" is caught socially, if at all. ¹
• I worry the current process feels onerous enough that people route around it, which makes the under-enforcement worse.
• IMO GitHub Discussions is an awkward medium for reviewing a concrete design — it's forum-shaped, not document-shaped, so we can't comment on specific lines the way we'd want to. We discussed that people could always put the main design in a google doc, but I don't think that happens in practice.

What I'm proposing:

• Move the format spec — primarily the protobuf files from Lance and Lance namespace spec.yaml — into a separate, dedicated repo.
• Give only PMC members write access there, with branch protection requiring three approvals before a PR can merge, so the vote is structurally enforced rather than remembered. Vote +1 by approving the PR. Vote -1 by requesting changes.
• Implementation repos consume the spec repo as a submodule, giving us compile-time protection against impl-vs-spec drift for anything the IDL expresses.
• Use the PR interface as the discussion venue, so we get inline, Google-Doc-style commenting on proposed changes instead of forum threads.
• (Optional / later) explore CI to enforce a minimum voting period, though that's a nice-to-have, not a blocker. (Rust has an rfcbot that manages this.)

Curious what people think — especially on write-access scope and whether three approvals is the right bar.

Footnotes

1. I've tried to add some automated reminders at least in Lance, but nothing has yet landed in LanceDB. ↩

[jackye1995]

Overall +1, this looks good to me and would make the process much more standard.

The 2 concerns I have are

1. the additional hop, would it impact productivity and introduce too much complexity in the build and release process. Our current process is already pretty complicated with format versions, lib versions, subproject versions.
2. would this reduce discussions and attention from the community. This happened to the subprojects because they are in different repos and just have in general less attention from everyone that only look at activities in the main repo.

Thoughts?

[Xuanwo]

I like this idea. My only concern is that submodules do not work well these days, especially for agents that depend heavily on worktrees.

I'm thinking about adding a CI check for approval on proto changes. This CI check would only pass when three PMC members have approved it.

[wjones127]

I'm fine exploring doing it within the repo. We might be able to make a CI check that's smart enough to do this within the repo.

[wjones127]

In the latest sync meeting, we discussed splitting this proposal into 3 parts:

1. Move the spec into a separate repo, link as a submodule. This has been rejected.
2. Implement a gate in CI that prevents any format change from merging until it has 3 approving votes from PMC members. This has been accepted, and will be implemented soon.
3. Move canonical place for format change discussions into PRs. This is deferred from now, until 2 is implemented and has been in use for a couple weeks.