docs: add experimental features to the governance docs - #8304
Conversation
github-actions
Bot
added
A-docs
![lance-gatekeeper[bot]](https://avatars.githubusercontent.com/in/4433141?s=60&v=4){kind=small}
There was a problem hiding this comment.
❌ Gate recommendation: request changes.
The fast path for experimental format work addresses a real development need, but the policy must preserve one authoritative, time-bounded PMC decision path. Define where stabilization votes are cast and when they must begin and end so an experimental feature cannot remain on main indefinitely without formal acceptance or rejection.
A viable revision can either start the Discussion vote before the experimental merge, as the original proposal suggested, or define an explicit post-merge deadline, owner, and close/removal rules, while keeping the vote venue consistent with the requirements table.
| 2. Open a discussion of the feature on GitHub Discussions. This is not a voting discussion. It is a place for maintainers | ||
| to provide early feedback. | ||
| 3. Merge the PR with the feature clearly marked as experimental. | ||
| 4. When ready, open a PR to remove the experimental markers. This is the PR that will carry the vote. Merging this PR |
There was a problem hiding this comment.
Step 2 declares the Discussion non-voting, while the requirements table says the stabilization vote is held in GitHub Discussions; this line instead says the PR carries the vote. Those are different authority and recording mechanisms, so maintainers cannot determine where the three binding +1 votes and vetoes are counted. Pick one venue and state the complete linkage—for example, open a voting Discussion linked to this stabilization PR and count votes there, or explicitly change the table and voting rules to define PR Reviews as votes.
| 3. Merge the PR with the feature clearly marked as experimental. | ||
| 4. When ready, open a PR to remove the experimental markers. This is the PR that will carry the vote. Merging this PR | ||
| stabilized the feature. | ||
| 5. If the stabilization PR **fails or expires**, remove the feature from the codebase and specification. |
There was a problem hiding this comment.
fails or expires has no defined trigger: the existing policy specifies only a minimum one-week period, and Step 4 lets the author wait until “when ready” before opening the stabilization PR. An experimental feature can therefore remain merged forever without a vote that can fail or expire, defeating the stated community rejection guarantee. Restore the original proposal condition that the vote start before merge, or define a mandatory post-merge deadline, responsible actor, pass/fail/expiry criteria, and removal trigger.
1 participant
Certain format specification changes may be merged as experimental before their stabilization vote closes. This allows iteration on new features without blocking on a completed vote, while preserving the integrity of the stable format and the community's ability to reject or modify the feature.