BIOMASS PROCESSING SUITE
Open Source &
Open Science
Second Developer Meeting
Yoann Rey-Ricord
ACRI-ST · 2 November 2026
Today's plan
Four acts · ~45 minutes · demo and Q&A at the end
Open Source & Open Science · Second Dev Meeting · 2026
02
I
Introduction & INTENT
Open Source & Open Science · Second Dev Meeting · 202603
THE PROCESSOR SUITE
BIOMASS BPS Transforming P-band SAR Data into Global Forest Biomass (AGB) Maps
Open source under Apache 2.0. Developed by Aresys for ESA. Maintained as an open-science project by ACRI-ST and the BioPAL community.
github.com/BioPAL/BPS
Python processors
3
Product levels
L1 · L2A · L2B
14
Scientific algorithms
5
AGB · Forest Height · Forest Disturbance · Tomography · Interferometry
FOUNDATION · VOCABULARY
What is Open Source / Open Science?
THE TECHNICAL LAYER · OPEN SOURCE
The code is open.
Source available to anyone who can:
READ
Understand how it works
MODIFY
Improve or adapt it
In Practice
The whole project must adapt
THE CULTURAL LAYER · OPEN SCIENCE
The science is open.
Knowledge, data, methods, publications: transparent and reusable.
F
Findable
persistent IDs, rich metadata
A
Accessible
standard protocols
I
Interoperable
shared vocabularies
R
Reusable
clear licences, full provenance
DOCUMENTATION · where both meet two concepts, one mission
STRATEGIC RATIONALE
Why open source for an ESA processor suite?
Scientific reproducibility
Any published result can be re-run, audited, challenged from the code that produced it.
Community contributions
Scientific algorithm work, and equally welcome non-scientific contributions: bug fixes, performance improvements, documentation, and tooling.
Full audit trail
Every change is signed, tracked, reviewed. ESA can trace any line of code to its rationale.
No vendor lock-in
The methodology, the tooling, and the data formats are all open. Continuity guaranteed beyond any single contractor.
THE PROCESS WE FOLLOW ON BIOMASS
Five pillars, one open project.
01
Document
The project. Write the contract between the project and its contributors.
02
Adapt
The code. Prepare an operational codebase for open-source contribution.
03
Automate
The verification. Risk-score every pull request (PR) before any human reviews it.
04
Empower
The contributor. No one gets lost. Templates, bots, and clear guides.
05
Gather
The community. Meetings, discussions, governance in the open.
THE PROCESS WE FOLLOW ON BIOMASS
Document the project
01READY
The social contract
▪ README
▪ CONTRIBUTING
▪ CODE_OF_CONDUCT
▪ CONTRIBUTING
▪ CODE_OF_CONDUCT
02READY
Governance & decisions
▪ GOVERNANCE
▪ RELEASE_PROCESS
▪ COMMUNICATION
▪ RELEASE_PROCESS
▪ COMMUNICATION
03READY
Technical standards
▪ CODE_STANDARDS
▪ DOCUMENTATION_STANDARDS
▪ ARCHITECTURE
▪ DOCUMENTATION_STANDARDS
▪ ARCHITECTURE
04READY
Getting started
▪ GETTING_STARTED
▪ HELP_FLOWCHART
▪ HELP_FLOWCHART
05READY
Practical guides
▪ USER_GUIDE
▪ TUTORIALS
▪ ABOUT
▪ TUTORIALS
▪ ABOUT
06DOING
Scientific documentation
▪ SCIENCE_GUIDE (ATBD/DPM in Markdown, one per processor)
07
Documentation WEBSITE· THE UNIFIED PUBLIC FACE
Everything above, rendered as one navigable, searchable, FAIR-compliant site.
50+
PAGES
10+
SECTIONS
Sphinx
THEME
APACHE 2.0 | MIT
REUSE COMPLIANT
MD / SVG / YAML
EDITABLE ON GIT
TRACKED IN GIT
II
WHAT'S LIVE TODAY
Open Source & Open Science · Second Dev Meeting · 202609
One site. Every resource. One click away.
biomass-disc.info/docs/50+pages
8top sections
Sphinx+ PyData theme
GETTING STARTED
Get started
Use BPS
Run processors, understand data, read the science.
User Guide (SUM)
Science Guide (ATBDs)
Tutorials
Applicable documents
Ask or discuss
Questions, ideas, science. Not yet an actionable issue.
Q&A usage, API, processing chain
Ideas brainstorm before opening an issue
Scientific discussions
Show and tell
Contribute
Details in Act III. No code before the issue is approved.
01Open or pick an issue · wait for approval
02Act III: fork, draft PR (claim), then code
03Act III: CI and maintainer review
Software User Manual v4.4.1
PDF download on the ESA dissemination portal
Installation, configuration, execution
Applicable & reference documents linked
The online web version is not available yet. The authoritative SUM remains PDF-only for now.
BPS_SUM_v4_4_1.pdf
Run BPS on your own computer.
7 chapters. Full chain L1F → L1 → STA → L2A. Companion notebooks, helper scripts, JobOrder templates all ship in-tree.
A
Bundle
All processors via Aresys conda bundle
B
Source (developer)
pip install -e + native binaries
MAAP platform
ESA's hosted JupyterLab
On MAAP Coding, git clone over SSH or HTTPS to GitHub does not work. Create a GitHub PAT (PAT) and use it to authenticate clone and push.
MAAP access: ESA Member State nationals or participating states (see MAAP policy).
ATBDs AFD & PFDs catalogue
Index table of all algorithm documents
L2 AGB: first full web conversion
FH and FD ATBDs scheduled next
For now, only one ATBD is available as a web version. We hope to publish more conversions over time.
.../science-guide/
Five steps, no code before approval.
01Open or pick an issue
02Wait for status:approved
03Code on a fork / branch
04Open a pull request
05Review → merge → release
Roles, stewards, processor leads.
Maintainers, stewards, processor leads
Issues for actions, Discussions for ideas
Public decisions, open meeting notes
DOCUMENTATION ARCHITECTURE
One repo. One site. One reference.
›
Sphinx build
GitHub Action
+ GitLab trigger
›
Edit the documentation. The world sees your changes within minutes.
III
HOW YOU CONTRIBUTE
Open Source & Open Science · Second Dev Meeting · 202618
HOW YOU CONTRIBUTE
What is GitHub?
The de facto home of open source and the platform that makes BIOMASS BPS public, traceable, and collaborative.
DEFINITION
GitHub is a web platform built around Git. It hosts code, manages contributions, runs automation. Used by 100M+ developers and most major open-source projects worldwide.
→ WHAT IT BRINGS TO OPEN SOURCE
01READY
Public repository
Clone, fork, read, and audit the code from anywhere in the world.
02READY
Issues & Pull Requests
Track bugs, discuss ideas, propose changes, and review them collaboratively.
03READY
GitHub Actions (CI/CD)
Run tests, build documentation, validate quality automatically on every push.
04READY
Pages & integrations
Host documentation and releases at biopal.github.io
IN BIOMASS BPSprocessors · docs · CI/CD pipeline · Governance · discussion.
Everything in one place. Forkable, citable, auditable by anyone.
HOW YOU CONTRIBUTE
How BIOMASS runs on GitHub
WHO
WHERE
HOW
WHO DECIDES
WHAT SHIPS
PROPOSE
→
EVERY PR
→
CLASSIFY
+ ROUTE
+ ROUTE
→
APPROVE
→
SPECS
external devs
Scientists
ESA partners
maintainers
Scientists
ESA partners
maintainers
SPECS
1 public repo
code + docs
issues / PRs
discussions
code + docs
issues / PRs
discussions
SPECS
tests · lint
REUSE · DCO
tier 0|1|2
auto-classify
REUSE · DCO
tier 0|1|2
auto-classify
SPECS
CODEOWNERS SME
routing
maintainers
approve|reject
routing
maintainers
approve|reject
SPECS
squash · merge
release tag
changelog
back to main
release tag
changelog
back to main
LOOP · continuous delivery; every merge ships
HOW YOU CONTRIBUTE
Before the PR
CONTRIBUTOR
Has an idea,
found a bug,
wants to help
found a bug,
wants to help
PATH A
Pick an existing issue
Browse labels:
good-first-issue
help-wanted
bug
scientific-feature
→ comment to self-assign
PATH B
Propose a new issue
01
Open issue
Use a template
→
02
Scientific Module Expert (SME) assigned
CODEOWNERS routing
→
03
Sci. review
For algorithm proposals
→
04
Go / no-go
Approved to implement
Both paths end with an approved, assigned issue, ready to code.
HOW YOU CONTRIBUTE
Five issue templates · pick yours
Every issue must use a template. Blank issues are blocked (for maintainers only)
HOW YOU CONTRIBUTE
Inside a Bug report
1 [TYPE] Title
2 Affected Component
3 Severity
4 Version or commit reference
5 Environment
6 Observed Behavior
7 Expected Behavior
8 Steps to reproduce
9 Logs and traceback
10 Additional Context
HOW YOU CONTRIBUTE
Inside a Feature request
1 [TYPE] Title
2 Scope of the proposal
3 Most affected components
4 Problem statement and motivation
5 Proposed solution
6 Alternatives considered
7 Expected impact on delivery & operations
8 Additional context
HOW YOU CONTRIBUTE
Inside an Algorithm proposal
1 [TYPE] Title
2 Target processor or processing stage
3 Type of proposal
4 Scientific context and motivation
5 Proposed algorithm or method
6 Scientific justification
7 Validation plan
8 Expected impact on science & operations
9 Additional references
HOW YOU CONTRIBUTE
Branches & release governance
How contributions flow through GitHub once merged. Your day-one clicks (fork, draft PR) are on the next slides.
Key rules
External contributors
PR into develop only
Promotion to release
→ main reserved for maintainers
ESA approval required
for final merge to main
Hotfix branches for
urgent release patches
HOW YOU CONTRIBUTE
Your contributor path
Draft PR early so BioPAL/BPS sees you own the issue. Next slides: UI for steps 01 and 02.
ISSUE
IN HAND
IN HAND
approved
→
01
Fork
From BioPAL/BPS · next slide
→
02
Draft PR
Into develop + linked issue · claim visible immediately (next slide).
→
03
Work locally
Clone YOU/BPS, push to the draft branch, commit -s, tests. MAAP: GitHub PAT.
→
04
Ready for review
When the PR matches the issue scope
Then CI classifies the PR and maintainers review (following slides). Governance diagram: previous slide.
Fork the repository on GitHub
Branch and open a draft pull request (claim early)
HOW YOU CONTRIBUTE
The CI/CD pipeline
After you mark a PR ready for review: one block for checks, tiers, and merge rules.
PR opened
→
10 baseline checks
→
Auto tier triage
→
Tier-appropriate review
→
Merge
HOW YOU CONTRIBUTE
Tier policy
T0BASELINE
No risk-elevating change
Routine code or docs
No locked paths touched
Baseline outputs unchanged
1 reviewer required
T1EXTENDED
Locked or SME paths modified
Touches locked paths
Baseline marker differs
Dependabot major bump
2 reviewers (incl. SME)
T2HEAVY
Release / explicit upclass
PR targets release branch
run_heavy=true
All large datasets tested
3 reviewers (incl. ESA)
Judge from base, never from PR.Policy and baseline refs always read from the base branch SHA; the PR cannot rewrite its own judge.
HOW YOU CONTRIBUTE
Branch protection & approvals
fork / feature/*
PERSONAL
Free editing: your sandbox
0 approvals
→
develop
INTEGRATION
Maintainer + SME review
1-2 approvals
→
release
PRE-RELEASE
Maintainer + SME · GPG-signed
2 approvals
→
main
PRODUCTION
Maintainer + SME + ESA
3 approvals
Dismiss stale approvals on new commits
Require linear history (squash-only)
Block force-pushes
Require Code Owner review
HOW YOU CONTRIBUTE
After the PR
PR MERGED
into develop
→
The CI/CD pipeline triggers automatically…
Tests re-run
Full baseline + extended suite on the merged result
Docs rebuild
Sphinx builds and deploys to the documentation site
Release tag
Semantic version bump, changelog generated automatically
DOI minted
Zenodo integration: citable, FAIR-compliant artifact
Promotion to main
Maintainer opens a PR from develop → main · requires ESA approval · triggers final release
RELEASED
Tagged · GitHub Release · DOI · citable
No contributor
is ever lost.
FOUR TOUCHPOINTS BETWEEN THE PROJECT AND THE CONTRIBUTOR
Auto tier classification
Risk-scored
Every PR is risk-scored on opening. No labels to set, no debates.
CODEOWNERS routing
Right reviewer
The right SME is auto-assigned based on which files were touched.
PR and Issue templates
Guided contribution
Structured forms for every issue and PR, routed automatically.
Sticky CI bot
Plain English
A sticky comment explains the verdict and the next action.
IV
JOIN US
Open Source & Open Science · Second Dev Meeting · 202635
A project lives
by its community.
FOUR PRACTICES THAT KEEP THE PROJECT ALIVE
Open meetings
Regular · Documented
Periodic community meetings, agenda and minutes published in the open.
Communication channels
Multi-modal
Issues for tasks, Discussions for ideas, mailing list for announcements.
Workshops & training
Onboarding
Periodic sessions to onboard new contributors and align on conventions.
Public decisions
Traceable
Every important choice discussed in public, recorded, citable later.
JOIN US
Channels and meetings
COMING SOON
COMMUNITY MEETING
Public agenda · Public minutes
MAILING LIST
Subscribe for releases & governance news
OFFICE HOURS
Walk in with any question see Announcements
LIVE
Demo
01
Open a Documentation Issue
File a docs bug on GitHub
02
Fork & Fix as External
Fork the repo, create a branch, commit the fix
03
Open PR → Review → Merge
PR into develop, CI runs, maintainer merges
Live replay of Act III (issue → fork → draft PR → CI). On MAAP Coding: GitHub PAT for git (slide 13).
After the demo · MAAP Hackathon (12-16 Oct 2026)
Community work lives in github.com/BioPAL/biomass-hackathon-2026 (topics + shared resources/). Reusable loaders and processors can be promoted into BioPAL/BPS through the normal issue → PR → tiers workflow.
Questions?
Status update
Yoann Rey-Ricord
ACRI-ST · 2 November 2026
1st meeting recording · biomass-disc.info/docs/communication/developer-meeting