Open
Conversation
Contributor
|
thank you very much for the thoughtful document @fcollman |
Contributor
|
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. |
Collaborator
|
Thanks Forrest for creating this governance plan --- as we discussed, this plan looks great to me. |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
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?