Welcome to the updated Open Problems documentation. If you need the legacy docs, you can find them here.

Governance

Version: 0.1
Date: 2025-04-11

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

The OpenProblems community adheres to the following 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. A dedicated Safety Team may be established in the future to handle CoC enforcement and related matters.

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, continuous integration/continuous deployment (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

  • Responsibilities: Each Task Team focuses on a specific benchmarking task (e.g., "Label Projection," "Modality Prediction"). Responsibilities include defining the task, selecting/adapting relevant datasets (in coordination with the Datasets Team), implementing data loaders and task-specific metrics, maintaining evaluation code, and reviewing community contributions (new methods) for that task. Each task team should have a task maintainer, with separate responsibilities defined below.
  • 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: The Task Leader is the head of the Task Team, and is responsible for day-to-day organization of the team and setting the direction and overall scope of the task. The Task Leader is responsible for managing pull requests and issues on the repository corresponding to the task.
    • Members: Team members contribute to the development of the tasks including contributing code, uploading datasets, leading community discussions, etc.
  • Decision Making: Consensus within the team, led by the Task Leaders(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. The electorate consists of the members of the relevant team (e.g., Core Team members vote on Core Team decisions).
  • Escalation: Disagreements within Task Teams, Infrastructure, or Datasets teams that cannot be resolved internally can be escalated to the Core Team who has final decision to resolve any dispute via Voting, as described above. Other conflicts relating to the Code of Conduct follow the process outlined in that document.
  • Transparency: Significant decisions and, where apppropriate, the supporting rationale are documented and public 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.
  1. Edit this page
  2. Report an issue with this page