Governance for the Vega Organization #2
Conversation
|
Thanks @domoritz for putting this together! I like the descriptions of the different roles. I'm wondering how we can best integrate this with the existing governance structure for |
|
Ah, I missed that. Thanks for the pointer. I think we have two options. One, leave the governance documents mostly separate and link to the Altair governance from the Vega governance but don't say that the Vega governance governs Altair. Altair could still delete its own CoC and refer to the Vega one to reduce redundancy but otherwise we keep things separate. Two, merge and move the parts we like about governance from Altair into this new governance. I'm open to either option and leave it up to the current Altair steering committee to decide. |
|
We just had an Altair steering committee meeting yesterday where we also discussed governance and how interactions could look like with the other Vega projects (I'll try to add the minutes soon here. Your PR went live during the meeting so we unfortunately did not yet discuss it. :) A change in the Altair governance should happen based on a committee vote. I'll try to set up the next committee call in ~1 month. If you already want to go ahead and merge, I'd suggest to simply link to https://altair-viz.github.io/about/governance.html for Altair. In that call we could discuss if we want to
I'd be very curious to hear if there are any plans to set up a similar governance body to the Altair steering committee for Vega/Vega-Lite. In a second step, maybe even incl. Altair? We discussed in our call yesterday that for the next Altair committee meeting, we'll extend invites to the broader Vega maintainer/contributor community in case there is interest to discuss the collaboration and overlap in governance between Vega/VL and Altair. |
There was a problem hiding this comment.
Thanks for writing this up @domoritz, I'm happy with the Vega project governance info, and would agree with linking to Vega-Altair's governance documents for the purpose of this PR, and then the Vega-Altair steering committee can discuss the possibility of moving our steering committee documents upstream to this repo.
One thing we need to decide is whether there is still a need for a Vega-Altair specific steering committee once we have a larger Vega steering committee. As @binste mentioned, we decided to invite the Vega and Vega-Lite maintainers to our next steering committee meeting so that we can discuss these things together.
Really glad to be having these conversations!
|
Re the steering committee. I like the idea of an overall Steering Committee but we could have sub-committees. If we do that, we definitely want a single charter document and I'd be happy to just adopt the one from Altair with some modifications. Maintainers should be separate. I haven't quite figured out a lightweight way to define maintainers for all the various Vega projects (tooltip, embed, etc). My current thinking is that they all share the same maintainers. I would also propose that a project may define separate admins that are allowed to make releases. This way we would have four roles/levels.
Maintainers and admins directly correspond to the roles in GitHub. |
|
Great to see that this is being pushed forward @domoritz! I like the idea of sub-committees with a single charter document. One question, within the Vega organization there are more repositories than currently mentioned in this governance model. Could you reflect a bit on this? Most notably, vl-convert, which is crucial for Altair nowadays. |
There was a problem hiding this comment.
Thanks for putting this together and for everyone's helpful comments! I think this looks good overall and I'm ok either merging and updating in another PR once we have had the call everyone together or keeping this PR open until we have had that call and made the updates.
I think the four levels of roles sounds good; "contributor" requires no management from our side, "maintainer/admin" is something we already have in the GitHub roles and it is great that there is now a formal description of these roles, "steering committee" is really the only new role and I think it will be an important one to coordinate things across the vega ecosystem so I'm excited to see that added here.
I forgot to include Vega-Lite-convert. I'll add it. Yes, there are more but many are not active (voyager, compassql) or have very specific purposes (typescript-json-schema). One thing I like about the charter is that it explains how to add projects, which we will want for Vega. |
GOVERNANCE.md
Outdated
|
|
||
| Maintainers belong to all or some subset of Vega projects. Maintainers are responsible for organizing activities around developing, maintaining, and updating the project. Maintainers have write access and can push directly to branches on GitHub. Maintainers also have access to specific developer channels on Slack. | ||
|
|
||
| To become a Maintainer, a contributor must be nominated by an existing Maintainer and approved by a majority of Maintainers via Slack reactions within 7 days (simple majority of responses). A new Maintainer should be added to 1) the GitHub team, 2) the Slack channel, and 3) the [maintainers.md file](MAINTAINERS.md). We want more people to become Maintainers and lower the barrier the enter. If you are interested in becoming a Maintainer, please reach out to an existing Maintainer. |
There was a problem hiding this comment.
via Slack reactions
Is this slack reaction private within the maintainer channel? (Otherwise, I doubt if anyone will feel comfortable "thumbing down" in public.)
There was a problem hiding this comment.
Yes, it's in the private channel.
GOVERNANCE.md
Outdated
|
|
||
| ## Decision-making process | ||
|
|
||
| Major technical decisions should be made in public using GitHub discussions or GitHub issues. While we use [Slack](https://bit.ly/join-vega-slack-2022) for more direct discussions, any results should be documented on GitHub where they are accessible to everyone. Note that we don't pay for Slack and so any discussions disappear after 90 days. |
There was a problem hiding this comment.
- I think we need some RFC template so people know to enumerate alternative design etc.
Github issue is generally quite ineffective to enumerate such options.
There was a problem hiding this comment.
Slack is even worse for it and doesn't even have templates. And yes, I agree having some template would be useful but it should be lightweight. I honestly think our pull request templates are not as useful as we had hoped (people don't fill it out and it clutters the pull request description).
There was a problem hiding this comment.
I agree that our PR template hasn't worked well because it's heavyweight (lots of checkboxes). I think one other reason is because the wording/structure makes it a little unclear how to actually fill things out (e.g., reads like instructions, with links to advice that need to be deleted; some checkboxes, some bullet points; and, unclear where one should add a description of the PR, etc.).
So, we could use something more lightweight like:
## PR Description
## Checklist
- [ ] This PR is atomic (i.e., it fixes one issue at a time).
- [ ] The title is a concise [semantic commit message](https://www.conventionalcommits.org/) (e.g. "fix: correctly handle undefined properties").
- [ ] `yarn test` runs successfully
... etc
There was a problem hiding this comment.
Done in vega/vega-lite#9187
CHARTER.md
Outdated
|
|
||
| ### Purpose | ||
|
|
||
| The Steering Committee will be responsible for all technical oversight, project approval and oversight, policy oversight, and trademark management for the Organization. |
There was a problem hiding this comment.
Typo? “Project approval and oversight” Should it be “project approval oversight”?
There was a problem hiding this comment.
I copied this from Altair. I think it means approving projects and overseeing projects. The steering committee is responsible for approving projects and not just overseeing the approval. Makes sense? We could shorten this to "project approval" since we have a separate point for "policy oversight". I'll change it for now.
CHARTER.md
Outdated
|
|
||
| ### Composition | ||
|
|
||
| The Steering Committee voting members are listed in the [STEERING-COMMITTEE.md file](STEERING-COMMITTEE.md). Voting members may be added or removed by no less than 3/4 affirmative vote of the Steering Committee. The Steering Committee will appoint a Chair responsible for organizing Steering Committee activity. |
There was a problem hiding this comment.
Should we amend to state 1-2 chairs to allow for co-chairs? Or a chair and a vice-chair?
There was a problem hiding this comment.
Updated to allow 1 or 2 chairs.
STEERING-COMMITTEE.md
Outdated
| | --- | --- | --- | | ||
| | Stefan Binder (Chair) | @binste | - | | ||
| | Dominik Moritz (Chair) | @domoritz | - | | ||
| | Jeffrey Heer | @jheer | - | |
There was a problem hiding this comment.
Org for jheer: University of Washington
Co-authored-by: Stefan Binder <[email protected]>
There was a problem hiding this comment.
This looks really fantastic!! HUGE thank you @domoritz for driving this, and to everyone else for contributing.
I just updated my affiliations throughout and left one comment about potential dynamics issues of voting on people's roles as part of Slack channels that they may subsequently join. Not sure it needs to be addressed as part of the governance documents, but just wanted to make sure it was on our radar so it doesn't catch us unawares the first few times we need to run the process through.
project-docs/GOVERNANCE.md
Outdated
|
|
||
| Maintainers have write access and can push directly to branches on GitHub. Maintainers also have access to specific developer channels on Slack. | ||
|
|
||
| To become a Maintainer, a contributor must be nominated by an existing Maintainer and approved by a simple majority of Maintainers via Slack reactions within 7 days (simple majority of responses). A new Maintainer should be added to 1) the GitHub team, 2) the Slack channel, and 3) the [MAINTAINERS.md file](MAINTAINERS.md). We want more people to become Maintainers and lower the barrier the entry. If you are interested in becoming a Maintainer, please reach out to an existing Maintainer. |
There was a problem hiding this comment.
Just want to double check a couple of things here:
- Do these two lines mean that we'll be switching the
-devchannels from public to private on the Vega slack? - Will votes for maintainers (and actually any membership level) occur on these private channels? If so, there is some potential for awkward power dynamics—eg person A is nominated; there is an up/down vote, they're ultimately added as a Maintainer and join the private channel and can now see who voted against their membership. I imagine this will be a relatively rare event, so I don't think we need to overengineer it. I'm also on the fence about how much of an issue this actually is. But, one lightweight approach might be for whomever is chairing the nomination process to announce the result at the conclusion of the vote (eg as number for/against), and then delete the Slack post corresponding to the vote.
There was a problem hiding this comment.
For channels, I made new ones just to now kick people out of channels but we can basically "archive" the existing ones at some point.
Hm, right, I hadn't thought about the awkwardness of being able to see who voted against you. @jheer suggested in the steering committee meeting that we could use Google forms for anonymous voting. We could switch to that for votes on people. I would suggest that we restrict access to the results to the chairs and they should delete the form after the vote has passed similar to what you suggest for Slack votes.
I'd say for now let's do what you suggested and delete the vote post after the vote.
Co-authored-by: Arvind Satyanarayan <[email protected]>
Co-authored-by: Arvind Satyanarayan <[email protected]>
Co-authored-by: Arvind Satyanarayan <[email protected]>
Co-authored-by: Arvind Satyanarayan <[email protected]>
|
Waiting for last review from @kanitw before merging. |
As suggested by @arvind in vega/.github#2 (comment)
Corresponding updates to the Altair organization vega/altair#3277.