Skip to content

Fork & Upstream Synchronization Policy

[!NOTE] For the latest implementation status, please refer to Functional Implementation Status (Remaining Functionality).

Purpose: Define how forked subprojects (e.g. space_debris_management) are managed to maintain shared code quality and supply chain integrity.

Key points:

  • Cases where forks are acceptable:
  • Experimental rapid prototyping (non-production) where independent short-term modifications are required.

  • If the license allows and the team can clarify who is responsible for the fork.

  • Fork steps (recommended):

  • Register the fork proposal in Issues and clearly state the purpose, period, and person in charge.
  • Cut out changes to shared code into shared/ or privately packaged modules.

  • Propose important API changes to the original repository on a PR basis (synchronization policy).

  • Synchronization and merge operations:

  • Merge upstream main weekly or after each feature is completed and perform a differential review.

  • Be sure to report security/license-related changes to upstream and redirect them as much as possible.

  • Long-term maintenance policy:

  • For forks that are expected to continue operating for more than 90 days, package shared code and manage dependencies with pip/pyproject.

  • Notify upstream of critical bug fixes or apply emergency patches within 72 hours (as per policy).

  • Code review and security:

  • Forks require automated testing and basic security scanning (such as Bandit).

  • When handling external data/models, specify the handling policy (TOS, data license).

  • Documentation:

  • Forked projects clearly state "FORKED FROM" and the upstream commit hash in the README.

Appendix: Fork management template and simple checklist will be added as Docs/FORK_POLICY_TEMPLATE.md.