Principles

The Thoth Station community adheres to the following principles:

• Open: Project Thoth is open source. See repository guidelines, below.
• Welcoming and respectful: See Code of Conduct, below.
• Transparent and accessible: Work and collaboration should be done in public. See SIG governance, below.
• Merit: Ideas and contributions are accepted according to their technical merit and alignment with project objectives, [scope], and [design principles].

Code of Conduct

The Thoth Station community abides by [out code of conduct]:

As contributors and maintainers of this project, and in the interest of fostering an open and welcoming community, we pledge to respect all people who contribute through reporting issues, posting feature requests, updating documentation, submitting pull requests or patches, and other activities.

As a member of the project, you represent the project and your fellow contributors. We value our community tremendously and we’d like to keep cultivating a friendly and collaborative environment for our contributors and users. We want everyone in the community to have [positive experiences].

Community groups

The project is comprised of the following types of subgroups:

• Special Interest Groups, SIGs
  • Subprojects

SIGs

The project is organized primarily into Special Interest Groups, or SIGs. Each SIG is comprised of members from multiple companies and organizations, with a common purpose of advancing the project with respect to a specific topic, such as Observability or Documentation. Our goal is to enable a distributed decision structure and code ownership, as well as providing focused forums for getting work done, making decisions, and onboarding new contributors. Every identifiable subpart of the project (e.g., github org, repository, subdirectory, API, test, issue, PR) is intended to be owned by some SIG.

SIGs must have at least one and ideally two SIG chairs at any given time. SIG chairs are intended to be organizers and facilitators, responsible for the operation of the SIG and for communication and coordination with the other SIGs, the Steering Committee, and the broader community.

Each SIG must have a charter that specifies its scope (topics, subsystems, code repos and directories), responsibilities, areas of authority, how members and roles of authority/leadership are selected/granted, how decisions are made, and how conflicts are resolved.

A primary reason that SIGs exist is as forums for collaboration. Much work in a SIG should stay local within that SIG. However, SIGs must communicate in the open, ensure other SIGs and community members can find notes of meetings, discussions, designs, and decisions, and periodically communicate a high-level summary of the SIG’s work to the community.

Subprojects

Specific work efforts within SIGs are divided into subprojects. Every part of the code, data and documentation must be owned by some subproject. Some SIGs may have a single subproject, but many SIGs have multiple significant subprojects with distinct (though sometimes overlapping) sets of contributors and [owners], who act as subproject’s technical leaders.

Subprojects for each SIG are documented in [sigs.yaml].