[VOTE] Introduce Incubating Subprojects and Simplify Subproject Governance

[jackye1995]

Summary

This proposal introduces a new "Incubating Subproject" tier to our project governance, simplifies the subproject rules, and removes the graduation path from subproject to core project.

For full governance doc change, see: #5847

Motivation

Based on our experience since establishing community governance:

1. Review and release standards are hard to maintain for subprojects. Projects that do not have as many eyes as the core project struggle to meet the same strict standards. This creates unnecessary friction and slows down development in those areas.

2. Current rules are too strict for subproject contributors. There are people who have been actively working on projects currently listed as core (e.g., lance-spark, lance-ray) and effectively act as owners, but have not been granted write permission due to our current rules. This indicates the rules may be too restrictive. We should promote people to better act as owners of subprojects and pave a clear path for them to eventually become maintainers.

3. Voting periods for new subprojects feel excessive. From our experience with the lance-context and lance-huggingface votes, waiting 3 days for approval of experimental projects seems like too much overhead.

Proposed Changes

1. Introduce Incubating Subprojects

A new tier for experimental or early-stage repositories:

• Any PMC member can create an incubating subproject without a formal vote
• Anyone can be added as a contributor with write access by the project creator or existing PMC members
• Merges without review are allowed
• No formal release process is required
• Must include a prominent README notice about incubating status
• The PMC is responsible for updating the governance doc with the new incubating subproject to the list of incubating subprojects.

2. Simplify Subproject Rules

Subprojects will have relaxed requirements compared to the core project:

• Contributors may receive write access even if not maintainers
• Merges may be allowed without review at maintainer discretion
• Release processes may be simplified

New subprojects are created by graduating from incubating subprojects through a PMC vote.

3. Remove Graduation to Core Project

Remove the concept of graduating from subproject to core project. Subprojects will remain subprojects. This reflects the reality that maintaining core project standards across many repositories is not practical.

4. Consolidate Core Project

Only lance will be the core project. Other projects previously listed as core will move to subprojects or incubating subprojects based on their maturity.

5. Update Project Lists

Core Project:

• lance

Subprojects (7):

• lance-duckdb
• lance-huggingface
• lance-namespace
• lance-namespace-impls
• lance-python-docs
• lance-ray
• lance-spark

Incubating Subprojects (6):

• lance-context
• lance-data-viewer
• lance-flink
• lance-graph
• lance-trino
• pglance

6. Update Voting Requirements

Decision Type	+1 Votes Required	Binding Voters	Minimum Period
Incubating subproject graduation to subproject	3	PMC	3 days
Subproject management	1	PMC	N/A

Remove:

• "Subproject creation and management" (replaced by incubating subproject creation without vote)
• "Subproject graduation to core project" (concept removed)

7. Graduation Requirements

For an incubating subproject to graduate to a subproject, it must demonstrate:

• Proper repository setup including CI, issue tracking, and contributing guide
• Proper code standard enforcement including lint and testing
• Established use cases
• Community adoption outside the primary contributor
• At least 2 Lance maintainer actively maintaining the project

Upon graduation, contributors with write access who are not Lance maintainers will keep their commit privileges. They are encouraged to become Lance maintainers through their continued contributions.

Expected Benefits

1. Lower barrier for experimentation. PMC members can quickly spin up new projects without voting overhead.
2. Clearer ownership path. Contributors can get write access to subprojects and grow into maintainers.
3. Realistic expectations. Acknowledges that not all projects can or should meet core project standards.
4. Faster iteration. Reduces bureaucracy for projects that are still finding their footing.

Vote

Please vote on this proposal:

• +1: Approve the governance changes as proposed
• 0: Abstain
• -1: Reject (must include justification)

[majin1102]

+1
Looking farward to new incubating subprojects

[HaochengLIU]

+1
I like the change and am looking forward to the new era

[westonpace]

+1

This seems fine to me overall.

I do have one question. Can a subproject still be a viable path for someone to become a maintainer and/or PMC? I think the answer is probably yes? I guess even if a user is purely interested in maintaining their subproject they probably still would like to have some say on how the spec itself evolves (even if they don't modify the code in the core project at all)?

[HaochengLIU]

i vote for yes
my friend used to work on apche arrow sub project and they've made enough contributions to earn a committer title

[Xuanwo]

+1 binding

Looks good to me, except that I think projects like lance-python-docs which doesn't do release should not be treated as subprojects.