Governance for the Vega Organization

[domoritz]

Corresponding updates to the Altair organization vega/altair#3277.

[binste]

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 altair-viz which we merged in vega/altair#3139. How about just linking to the https://github.com/altair-viz/altair/tree/main/governance folder for all things related to Altair? Steering committee members are already listed here and maintainers here.

[domoritz]

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.

[binste]

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

• move some of the governance documentation over to this repo
• adapt the same role definitions for maintainers and admins which are slightly different to what we have now

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.

[jonmmease]

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!

[domoritz]

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.

• Contributor (anyone who makes any contribution, needs to adhere to CoC)
• Maintainer (maintain project, merge PRs etc, appointed by maintainers)
• Admin (maintainer who can also make a release, appointed by existing admins, may only exist if this is a separate role from maintainers)
• Steering committee (Vega Project wide, can have subcommittee if desired, responsible for technical and policy oversight)

Maintainers and admins directly correspond to the roles in GitHub.

[mattijn]

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.

[joelostblom]

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.

[domoritz]

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.

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.

[kanitw]

via Slack reactions

Is this slack reaction private within the maintainer channel? (Otherwise, I doubt if anyone will feel comfortable "thumbing down" in public.)

[domoritz]

Yes, it's in the private channel.

[kanitw]

• 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.

[domoritz]

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).

[arvind]

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

[domoritz]

Done in vega/vega-lite#9187

[jonmmease]

Thanks for pulling this together @domoritz, looks great

[ChristopherDavisUCI]

Thank you for assembling this so quickly! I just left one minor comment.

[jheer]

Typo? “Project approval and oversight” Should it be “project approval oversight”?

[domoritz]

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.

[jheer]

Should we amend to state 1-2 chairs to allow for co-chairs? Or a chair and a vice-chair?

[domoritz]

Updated to allow 1 or 2 chairs.

[jheer]

Org for jheer: University of Washington

[domoritz]

Done

[binste]

Thanks again @domoritz ! Only added one small comment.

[joelostblom]

Looks great, thank you for putting it together!

[arvind]

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.

[arvind]

Just want to double check a couple of things here:

• Do these two lines mean that we'll be switching the -dev channels 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.

[domoritz]

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.

[keckelt]

Looks great, thank you!

[domoritz]

Waiting for last review from @kanitw before merging.