Kjell Tore Guttormsen 00830b3b85 docs(repo): align the public contribution text with the forge's actual doors

CONTRIBUTING.md told strangers to fork and "open a Pull Request". Measured
against the forge itself, that door is shut: the API reports
has_pull_requests=false / has_issues=true for open/portfolio-optimiser, and
the org's published CONVENTIONS.md states the position -- "Issues velkommen
som signaler. PRs ikke akseptert. Fork-and-own er anbefalt adopsjonsmodell."

Replaces the PR workflow with the two routes that are actually open (issues
as signals, fork-and-own), and keeps the engineering standards the section
carried -- load-bearing tests, blocking validator, ruff/mypy, Conventional
Commits -- reframed as what the project holds itself to, which is what a
forker needs and what an issue is weighed against.

Also points CLAUDE.md's commons link at open/portfolio-optimiser-commons
(published 2026-08-04). The `commons` git remote still resolves via ktg/ and
is deliberately left alone.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01GWsexbQjPo9rsV3aUE54ZS

2026-08-05 08:29:43 +02:00

2.3 KiB

Raw Blame History

Contributing to portfolio-optimiser

Thank you for your interest in contributing! This document provides guidelines and instructions for contributing.

Code of Conduct

Please read and follow our Code of Conduct.

How to Contribute

Reporting Issues

Check existing issues before creating a new one
Provide clear reproduction steps
Include relevant environment details (OS, Python version, backend profile)

Pull requests are not accepted

The pull-request tab is switched off on this forge, across every repository in the organisation. That is a published position, not an oversight: this project is solo-maintained, and an enabled-but-permanently-empty PR queue would promise a review capacity that does not exist.

Two routes are open instead:

Issues — welcome, and read as signals. A well-argued issue carries the same information as a patch and costs you less to write.
Fork-and-own — the recommended adoption model. The licence is MIT: fork it, take it in your own direction, and you owe nothing back.

Standards this project holds itself to

These are the conventions the code is written against. They are worth knowing if you fork, and they are what an issue about the code will be weighed against:

Follow the existing code style (ruff enforced)
Type hints everywhere; mypy-clean where possible
Commit with Conventional Commits (type(scope): description)
New functionality comes with tests — this project uses load-bearing tests: a test that covers a seam must fail when that seam is detached, not merely pass while wired
The deterministic validator is mandatory and blocking — never make it an optional plugin
Documentation is updated in the same change

Development Setup

Requires Python ≥ 3.10 and uv.

# Clone (upstream, or your own fork)
git clone https://git.fromaitochitta.com/open/portfolio-optimiser.git
cd portfolio-optimiser

# Install dependencies
uv sync

# Run tests
uv run pytest

# Lint and format
uv run ruff check .
uv run ruff format .

# Type-check
uv run mypy src

Develop primarily on the local backend profile (free); reserve the Azure/Foundry profile for targeted, minimal verification.

Questions?

Feel free to open an issue for any questions about contributing.

2.3 KiB Raw Blame History