This is the default project governance for the Vega Projects. Our goal is to encourage a diverse community of contributors and users to participate in the development of the Vega projects.
Each project may override the specific roles and development guidelines in a GOVERNANCE.md and CONTRIBUTING.md file. However, all projects have to adhere to the code of conduct, the general principles outlined in this document, and the charter.
We define three levels of roles in the Vega projects: Contributors, Maintainers, and Admins. We expect everyone to adhere to our Code of Conduct.
Contributors are anyone who makes a contribution to a Vega project via GitHub. This includes filing issues, sending pull requests, and participating in discussions. There are no requirements to participate and we encourage everyone to contribute. You do not have to be a Maintainer to send a pull request.
Maintainers belong to all or some subset of Vega projects. Maintainers are responsible for organizing activities around developing, maintaining, and updating the project. Maintainers are also responsible for determining consensus.
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. The details of the vote should be deleted before the new maintainer is added to the channel. 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.
Maintainers who are inactive for more than six months may be removed from the Maintainer list by 3/4 vote of the existing Maintainers.
Admins are maintainers who can make and are responsible for releases. Admins are owners of the GitHub organization.
To become an Admin, a Maintainer must be nominated and approved by the existing Admins using the same process as for Maintainers. Admins are listed in the ADMINS.md file.
Admins who are inactive for a year may be removed from the Admin list by 3/4 vote of the existing Admins.
Major technical decisions should be made in public using GitHub discussions or GitHub issues. While we use Slack 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.
Projects make decisions through consensus of the Maintainers. While explicit agreement of all Maintainers is preferred, it is not required for consensus. Rather, the Maintainers will determine consensus based on their good faith consideration of a number of factors, including the dominant view of the Contributors and nature of support and objections. The Maintainers will document evidence of consensus in accordance with these requirements.
Decisions may be appealed by opening an issue and that appeal will be considered by the Maintainers in good faith, who will respond in writing within a reasonable time. If the Maintainers deny the appeal, the appeal may be brought before the Organization Steering Committee, who will also respond in writing in a reasonable time.
Each Vega project may have its own development guidelines in a CONTRIBUTING.md file. For example, Vega-Lite's contributing guide describes design and development principles.
Openness. Participation is open to anyone who is directly and materially affected by the activity in question. There shall be no undue financial barriers to participation.
Balance. The development process should balance the interests of Contributors and other stakeholders. Contributors from diverse interest categories shall be sought with the objective of achieving balance.
Coordination and Harmonization. Good faith efforts shall be made to resolve potential conflicts or incompatibility between releases in this Project.
Consideration of Views and Objections. Prompt consideration shall be given to the written views and objections of all Contributors.
Written procedures. This governance document and other materials documenting this project's development process shall be available to any interested person.