For OpenJS Review: vis.gl Charter and Governance Proposal for OpenJS
#15
Conversation
tobie
left a comment
tobie
left a comment
There was a problem hiding this comment.
Thanks for accommodating our requirements to get this reviewed. This is much easier to work with.
We've simplified our template charter and so I've pulled a few suggestions from it.
The two big concerns are that the steering committee is defined completely outside of the charter. Could you please pull the key aspects in?
Additionally, I've made comments about the sync voting process with a 50% quorum. That doesn't seem super inclusive. Could you possibly revisit that?
|
|
||
| ## Section 3: `vis.gl`'s TSC Governing Body | ||
|
|
||
| `vis.gl` is governed by its [Technical Steering Committee](https://github.com/visgl/tsc/blob/master/README.md#technical-steering-committee). |
There was a problem hiding this comment.
Steering committee basics belong here. In particular terms used further down in the charter must be defined here.
CHARTER.md
Outdated
|
|
||
| - **Quorum:** A quorum is established when at least 50% of steering committee members members are present. The steering committee members may meet without quorum, but may not make binding decisions. | ||
|
|
||
| - **Votes During Meetings:** When quorum is met, decisions require a simple majority of the steering committee members present. |
There was a problem hiding this comment.
In general, processes that allow decisions to be made synchronously aren't very inclusive. It's also surprising for a consensus-seeking decision-making process to allow for decisions to be made by just above 25% of the membership synchronously. I'd suggest rethinking this approach.
There was a problem hiding this comment.
After discussion with @tobie, it's more accurate to say use lazy consensus for decisions.
Lazy consensus is designed to be a fast-ish form of governance. Faster than full consensus (especially in large TSCs), and way faster than voting on every little thing.
Lazy consensus implies there's a reasonable amount of time between proposal and action so that objections can be made.
If we care about how much time, we can put this timing in our governance doc (e.g. 2 weeks for important decisions and a couple days for minor changes).
If we care about how many people need to agree, we put that in our governance doc (e.g. 4 members need to agree to adding a new TSC member, or sub-project).
The benefit to all here is that the TSC can edit their governance without approval from the CPC.
Last resort voting, as described by CPC in section 10, is fine.
| ### Section 4.2: Decision-making, Voting, and/or Elections | ||
|
|
||
| Decision making and voting follow the practices adopted by the CPC and described in [Section 9](https://github.com/openjs-foundation/cross-project-council/blob/main/CPC-CHARTER.md#section-9-decision-making) and [Section 10](https://github.com/openjs-foundation/cross-project-council/blob/main/CPC-CHARTER.md#section-10-voting) of the CPC Charter respectively. |
There was a problem hiding this comment.
Pulled up from an outdated comment
@felixpalmer @ibgreen @Pessimistress,
After discussion with @tobie, it's more accurate to say use lazy consensus for decisions.
Lazy consensus is designed to be a fast-ish form of governance. Faster than full consensus (especially in large TSCs), and way faster than voting on every little thing.
Lazy consensus implies there's a reasonable amount of time between proposal and action so that objections can be made.
If we care about how much time, we can put this timing in our governance doc (e.g. 2 weeks for important decisions and a couple days for minor changes).
If we care about how many people need to agree, we put that in our governance doc (e.g. 4 members need to agree to adding a new TSC member, or sub-project).
The benefit to all here is that the TSC can edit their governance without approval from the CPC.
Last resort voting, as described by CPC in section 10, is fine.
Any objections to this?
There was a problem hiding this comment.
Sounds good, it describes how we are working already
| ## Section 0: Guiding Principles | ||
|
|
||
| > We believe that powerful visualization should be accessible to every developer. | ||
|
|
||
| We believe visualization tools should be declarative, composable, and interoperable—accessible to every developer and designed to work seamlessly within the broader ecosystem. | ||
|
|
||
| Power shouldn’t come from complexity: layers, not low-level rendering; clear abstractions, not siloed systems. Our libraries should fit naturally alongside the tools developers already use, while staying modular and focused so each part can stand alone or be combined into a coherent whole. |
There was a problem hiding this comment.
@felixpalmer @ibgreen @Pessimistress,
We previously had a copy/pasta under guiding principles and the CPC has requested (see #15 (comment)) we put something that we believe instead. Any objections to this wording?
|
Hey @felixpalmer, @ibgreen, @Pessimistress, I performed a TSC review with @tobie. Please take a look and raise objections, if any. To me, this new version is a lot simplier. If there is something you think should be included, consider where it can be worked into the governance.md doc - 90% of time time, that's where we're going to want to put it. If there are no objections, the only remaining task is for @tobie to review what should go into Section 3 with the CPC. We didn't have enough information, so he's going to go gather it from the CPC members and get back to me. |
| ## Section 0: Guiding Principles | ||
|
|
||
| > We believe that powerful visualization should be accessible to every developer. | ||
|
|
||
| We believe visualization tools should be declarative, composable, and interoperable—accessible to every developer and designed to work seamlessly within the broader ecosystem. | ||
|
|
||
| Power shouldn’t come from complexity: layers, not low-level rendering; clear abstractions, not siloed systems. Our libraries should fit naturally alongside the tools developers already use, while staying modular and focused so each part can stand alone or be combined into a coherent whole. |
| ### Section 4.2: Decision-making, Voting, and/or Elections | ||
|
|
||
| Decision making and voting follow the practices adopted by the CPC and described in [Section 9](https://github.com/openjs-foundation/cross-project-council/blob/main/CPC-CHARTER.md#section-9-decision-making) and [Section 10](https://github.com/openjs-foundation/cross-project-council/blob/main/CPC-CHARTER.md#section-10-voting) of the CPC Charter respectively. |
There was a problem hiding this comment.
Sounds good, it describes how we are working already
Co-authored-by: felixpalmer <[email protected]>
Reopens the vis.gl project charter for review with the OpenJS CPC. See #13 for maintainer discussion and more context.
Note
Adds a new vis.gl Charter and updates governance to reference it and align communications with OpenJS CPC marketing guidelines.
CHARTER.md): Introduces guiding principles, scope, CPC relationship, TSC governance, decision-making, and change-approval process.GOVERNANCE.md):Written by Cursor Bugbot for commit 84517c8. This will update automatically on new commits. Configure here.