Governance.

Preamble

This document outlines the governance structure, roles, responsibilities, and decision-making processes for the OpenProblems project (openproblems.bio). OpenProblems aims to accelerate progress in computational biology. This governance framework is intended to guide the project's development and community interaction in an open, transparent, and sustainable manner.

Mission and Goals

The mission of OpenProblems is to promote benchmarking and method development standards in the life sciences through community-driven open benchmarks of tasks and standardized datasets for computational methods in biology. Our goals include:

• Facilitating rigorous comparison and evaluation of computational methods.
• Promoting reproducibility and transparency in computational biology research.
• Accelerating the development of novel methods through community challenges.
• Building an inclusive and collaborative community around biological data science challenges.
• Providing high-quality, accessible resources (code, data, metrics) for researchers.

Core Values

• Openness: We are committed to open science. All code, datasets (where licensing permits), metrics, results, and discussions are publicly accessible.
• Collaboration: We believe progress is accelerated through teamwork. We foster a welcoming environment for contributions from researchers across different institutions and disciplines.
• Reproducibility: We strive for computational reproducibility in all benchmarks and analyses hosted on the platform. Standardized environments and workflows are key components.
• Standardization: We develop and maintain clear standards for data formats, APIs, evaluation metrics, and contribution processes to ensure fair comparisons and ease of use.
• Community: We aim to build a diverse, inclusive, and respectful community. We value contributions of all forms, not just code.
• Rigor: We are committed to scientific and technical rigor in the design of tasks, curation of datasets, and evaluation of methods.

Code of Conduct

OpenProblems adheres to the Contributor Covenant Code of Conduct. All participants, contributors, and leaders are expected to uphold this code. Reporting and enforcement guidelines are detailed in the Code of Conduct document itself.

Project Structure and Roles

OpenProblems is organized into several teams with distinct responsibilities. Decision-making generally follows a consensus-seeking approach within the relevant teams.

Core Team

• Responsibilities: Provides overall technical and scientific leadership, sets the project roadmap, coordinates across different teams, makes project-wide decisions (especially technical), manages core infrastructure strategy, and represents the project externally. Initially, the Core Team also handles strategic direction.
• Membership: Composed of individuals with significant, sustained contributions and a deep understanding of the project's goals and architecture. New members are typically nominated by existing Core Team members and confirmed by a simple majority vote within the Core Team.
• Decision Making: Operates by consensus. If consensus cannot be reached, a vote (simple majority) of Core Team members is used.

Infrastructure Team

• Responsibilities: Develops and maintains the core OpenProblems platform, website, CI/CD pipelines, container environments, and shared tooling. Ensures platform stability, scalability, and security.
• Membership: Individuals with expertise in software engineering, DevOps, and web development relevant to the project's stack. Reports to the Core Team.
• Decision Making: Consensus within the team for technical implementation details. Strategic decisions are made in consultation with the Core Team.

Task Teams

Each Task Team focuses on a specific benchmarking task (e.g., "Label Projection," "Modality Prediction").

• Responsibilities: Defining the task, selecting and adapting relevant datasets, implementing data loaders and task-specific metrics, maintaining evaluation code, and reviewing community contributions for that task.
• Membership: Researchers and developers interested in the specific biological problem or computational methods relevant to the task. Each team must have at least one Task Leader.
• Roles:
  • Task Leader: Responsible for day-to-day organization of the team, setting direction and scope, and managing pull requests and issues on the task repository.
  • Members: Contribute code, upload datasets, lead community discussions, etc.
• Decision Making: Consensus within the team, led by the Task Leader(s).

Decision Making Process

• Consensus: Most decisions within teams are made through consensus. Everyone is encouraged to voice opinions and concerns.
• Lazy Consensus: For routine changes or proposals with no objections after a reasonable period (e.g., 72 hours on a relevant GitHub issue or mailing list), consensus is assumed.
• Voting: If consensus cannot be reached within a team on a significant issue, the team lead (or the Core Team for project-wide issues) may call for a formal vote. Unless otherwise specified, a simple majority (>50%) is required for the proposal to pass.
• Escalation: Disagreements within teams that cannot be resolved internally can be escalated to the Core Team, which has final authority to resolve any dispute via voting. Conflicts relating to the Code of Conduct follow the process outlined in that document.
• Transparency: Significant decisions and, where appropriate, the supporting rationale are documented and publicly available (e.g., in GitHub issues, meeting minutes).

Conflict Resolution

• Conflicts should first be addressed privately and respectfully between the involved parties.
• If unresolved, the issue should be escalated to the relevant team lead(s) or Maintainer(s).
• If still unresolved, the Core Team should be involved for mediation.
• Code of Conduct violations follow the process outlined in the CoC document.

Changes to Governance

• Changes to this governance document require a formal proposal, typically as a pull request against this document in the project's repository.
• Proposals must be discussed publicly (e.g., via GitHub issues/discussions) for a minimum period of two weeks.
• Amendments are adopted or rejected by voting (as described above) within the Core Team.