Templates and checklists#

Structured forms and checklists so contributors are never lost between the project and GitHub. Four touchpoints guide every contribution:

  1. Auto tier classification: every PR is risk-scored on opening from the diff; no manual tier labels. See CI automation and contribution tiers.

  2. CODEOWNERS routing: the right SME is auto-assigned from the files touched.

  3. Issue and PR templates: structured forms for every issue type and pull request (below).

  4. PR guidance comment: CI posts a sticky summary with tier, job status, and reviewers needed.

This page also lists help resources, learning links, and pre-submission checklists.

Table of Contents#

  • Getting Help

  • Templates

  • Resources

  • Checklist for Contributors

  • Recognition

Getting Help#

For complete information about communication channels and meetings, see the Communication page.

Quick reference#

Where

What for

GitHub Issues

Actionable items only: bug reports, feature requests, algorithm proposals, documentation issues, security reports. Use the matching template.

GitHub Discussions

Open ended questions, brainstorming, scientific discussions, governance, community.

Office Hours

Planned weekly open session for contributor questions (not scheduled yet).

Community Meetings

Planned regular community meetings (not scheduled yet).

The recommended place to ask a question is GitHub Discussions. The Q&A category is monitored by maintainers and contributors.

Before asking for help#

  1. Check the documentation.

  2. Search open and closed issues.

  3. Search Discussions.

  4. Review similar PRs.

Opening an issue#

Every issue must be filed through one of the five templates. The template chooser at /issues/new/choose walks you through the options.

Templates#

Issue templates#

Five issue templates are available at /issues/new/choose. Pick the one that matches what you want to report. Each template asks for exactly the information the maintainers need to triage and route the issue to the right reviewer.

Template

When to use

01 Bug report

A defect in a processor, the CI/CD pipeline, or the documentation.

02 Feature or enhancement request

A non-scientific feature, an enhancement to an existing component, or a tooling improvement.

03 Algorithm proposal

A new scientific algorithm, a methodological change, or any modification with a scientific impact on the processing chain. Scientific justification is required.

04 Documentation issue

An error, a gap, an outdated section, a broken link, or a request for clarification in the documentation.

05 Security report

A non-sensitive security concern, hardening recommendation, or supply-chain issue. Sensitive vulnerabilities go through a private security advisory instead.

Discussions categories#

Six categories on GitHub Discussions host the conversations that are not yet actionable issues.

Category

When to use

Announcements

Project announcements, releases, governance decisions. Posts restricted to maintainers.

Q&A

Ask anything about usage, installation, API, processing chain, data formats. Mark the helpful reply as the answer.

Ideas

Brainstorm a feature or a change before opening a tracking issue.

Scientific discussions

Algorithms, validation, methodology, ATBD interpretations, references.

Governance

Project governance, maintainer paths, policy questions, open source strategy.

Show and tell

Introductions, usage stories, downstream projects, papers, conference talks.

Pull Request template#

Every PR uses the standard template that ships with the repository. It is auto-filled when you open a PR from the GitHub UI. The template covers:

  • The linked issue and its approval label (status:approved, good-first-issue, or help-wanted).

  • A short description of what the PR changes (not the problem, that lives in the issue).

  • Notes for reviewers.

  • User-facing change flag and release-note sentence.

  • Documentation update flag.

  • Expected tier (computed automatically by CI, your declaration just helps reviewers spot a mismatch).

  • AI assistance disclosure.

  • A short checklist of items the CI cannot verify on its own (scope match, single issue, breaking change flagged, reviewer competence).

Licensing PR Description Template#

When adding external libraries or dependencies to your PR, include the following information in your PR description:

## Dependencies Added

- **library-name** (v1.2.3)
  - License: MIT
  - Purpose: [Brief description]
  - Compatibility: Compatible with Apache 2.0
  - License URL: [Link to license]

For complete licensing requirements, see the Licensing section.

Resources#

Documentation#

Learning Resources#

Git and Version Control:

Python Development:

Testing:

Scientific Python:

Code Quality:

External Resources#

Workshops and Training#

  • Onboarding Workshops: Monthly sessions for new contributors (2h)

  • Technical Training: Quarterly sessions on tools and processes

  • Hackathons: Annual community events

  • Intercomparison Exercises: Regular scientific validation activities

Checklist for Contributors#

Before Submitting a PR#

Issue and scope:

  • A tracking issue exists for this change.

  • The issue is labelled status:approved, good-first-issue, or help-wanted.

  • The PR closes exactly one issue, and the scope matches what was approved.

Code Quality:

  • Pre-commit hooks installed and passing (pre-commit run --all-files).

  • Code formatted with ruff format src/ test/.

  • Linting clean: ruff check --fix src/ test/.

  • Type hints present where appropriate; mypy passes.

  • All code follows the Code standards.

  • No secrets or sensitive data in code.

DCO and Licensing:

  • All commits carry a Signed-off-by: trailer (git commit -s).

  • New files include SPDX headers (SPDX-FileCopyrightText + SPDX-License-Identifier: Apache-2.0).

  • reuse lint passes locally (or the pre-commit reuse hook passes).

Testing:

  • Tests added or modified and passing (pytest -m baseline on test/baseline/).

  • Baseline reference outputs updated if the behaviour intentionally changed.

  • If targeting release, you understand that the CI gate will be red until a maintainer triggers the workflow with run_heavy=true.

Documentation:

  • Docstrings added or updated.

  • Documentation site updated if the change is user facing.

Pull Request:

  • PR template completed fully.

  • Clear description of what changes (not the problem, that lives in the issue).

  • Commit messages are clear and descriptive.

  • Scientific validation completed or summary included for Tier 1 and Tier 2 changes.

  • Branch up to date with develop, no merge conflicts.

  • All CI checks passing (CI gate green).

During Review#

  • Respond to comments promptly (< 3 days)

  • Address all points raised by reviewers

  • Update PR with corrections

  • Communicate clearly about changes

  • Re-run tests after changes

  • Update documentation if requested

Recognition#

Contributors are recognized in:

  • Release notes

  • Project documentation

  • Community communications

  • Annual contributor acknowledgments

Thank you for contributing to BIOMASS BPS! Your efforts help advance open science and Earth observation capabilities.

Questions? Ask on GitHub Discussions. The Q&A category is the recommended place for usage questions, and Scientific discussions for algorithm and methodology topics. Open issues are reserved for actionable items that match one of the five templates.

Last Updated: 2026

Previous: Practical workflow | Next: Becoming a maintainer