RFC: Neuroglancer governance proposal

[fcollman]

Add community governance documentation

This PR establishes a governance structure for Neuroglancer by adding a GOVERNANCE section to the Sphinx documentation at docs/governance/governance.rst.

Motivation

Neuroglancer has become a foundational tool for the connectomics and high-dimensional imaging communities. The project has reached a scale where the current single-maintainer model creates friction:

Review latency: Useful contributions sit in the PR queue due to a lack of empowered reviewers
Maintainer burnout: The burden of both architectural vision and day-to-day maintenance on a single individual is unsustainable
Institutional risk: Organizations relying on Neuroglancer need a transparent governance path to justify continued engineering investment

What this establishes

A tiered "Ladder of Participation" (Contributors → Community Managers → Reviewers → Maintainers → Technical Lead) with a Steering Committee responsible for the roadmap, promotions, and structural health of the project. Key operational policies include a two-approvals merge policy, PR escalation for stale reviews, stale PR closing, and a lazy-consensus model for designated subsystem owners.

This document is itself the first RFC in the process it describes — please use PR review comments for discussion.

Implementation roadmap

Month 1 (this PR): Merge governance documentation; add a GOVERNANCE.md and update CONTRIBUTING.md
Month 2: First Steering Committee meeting to vote on the initial cohort of Community Managers, Reviewers, Maintainers, and subsystem definitions; Jeremy updates repository permissions accordingly
Month 3: Community prepares roadmap proposals for the Steering Committee
Month 4: Second Steering Committee meeting — iterate on membership, assess effectiveness of the model, discuss and approve 1–2 major roadmap items

Feedback requested

Jeremy Maitin-Shepard: Does the Technical Lead framing accurately reflect how you'd like to engage, and does this model give you the space you need?
Institutional stakeholders: Does this structure provide enough stability to justify continued engineering investment?
Active contributors: Are the roles and promotion path clear enough to guide your participation?

[seankmartin]

thank you very much for the thoughtful document @fcollman

[stuarteberg]

I agree, thanks for putting this forward. Looks quite reasonable to me. I've sent this around to interested folks here at Janelia to get their thoughts.

[jbms]

Thanks Forrest for creating this governance plan --- as we discussed, this plan looks great to me.

[seankmartin]

I think that the two approval system could be a bit much with the current number of maintainers/reviewers in the community. At the moment that risks this system to not unblock the PRs as intended. It's definitely a bit nuanced, but here are some alternatives I can think of:

1. One approval system - Two approvals is reduced to one.
2. Author role based approvals - PRs by a tech lead do not require approval. This means a tech lead can make a hot fix etc without waiting. PRs by a maintainer require one approval. All other PRs require two approvals.
3. PR size based approvals - While I don't much like lines of code as a sole measure of complexity, it could be an indicator of the PR scope. So large PRs would require two approvals, while small PRs would only require one approval.

In any case, these approval guides would be superseded by the "subsystem ownership". I think the main drawback with suggestions 2 or 3 is that they are difficult to implement. Possibly it could be a one approval system, but maintainers are mindful of points 2 and 3 to seek more consensus on complex PRs.

[chrisj]

I agree with 2, though I think tech lead 0 approval should mostly be hot fix focused. 3 is important to discuss.

I think PR's like #858 need higher requirements. Two non-maintainer reviewers are probably not enough. I would say at least one maintainer approval and a feature like that needs feedback from the steering committee. The role of the steering committee and what can be merged without their input needs to be discussed.

Also, I didn't follow the proposal when merging #915, not intentionally, Jeremy gave feedback without an official approval. I'm holding off on merging #916 because of the two approval requirement and that's an example where I feel 2 makes perfect sense.

[fcollman]

When i wrote it that I was hoping that this would incentivize everyone to give quality reviews to PRs because they want to see features flowing forward in general. Reviewers are going to be picked from people who have given good PRs (or i suppose we could also count non-reviewer "reviews" as part of the criteria for elevating someone to a reviewer).

I agree though that there is a startup problem when there are few people actively contributing, especially when the author of the PR is 1 of the 3 that can give reviews presently. I like the hot fix of only requiring a minimum of 1 review when the author is a maintainer or tech lead (and 0 for the tech-lead for hot-fixes), then hopefully over time we can get rid of this as we have a larger stable set of reviewers and maintainers.