Get involved

Contributing to uBixSys.

uBixSys is built by people who like building tools — small, sharp, standards-committed software they'd actually want to run. If that sounds like you, there's a place to help, whether or not you write code.

Why contribute

Good tools are a shared effort.

Every project under uBixSys is open source and self-hosted on purpose: software you can read, run, and depend on without handing your data to someone else. Keeping tools like that honest — correct, documented, and genuinely dependable — is more than any one maintainer can do alone.

We hold the work to a high bar: strong standards, real tests, and clear documentation. Contributing here means caring about that bar as much as we do — and you don't have to be a developer to make a real difference. Reporting a clear bug, reproducing a failing test, or fixing a stale doc all move the projects forward.

For everyone

Best ways to contribute.

The most useful help, in roughly the order it tends to matter — none of it requires commit access.

01
Run the test suites on release candidates and releases

Put each RC and release through its paces on your own hardware, OS, and configuration. Real-world coverage catches what CI can't, and a passing run on your setup is a data point that matters.

02
Help find and diagnose failing tests

When a test goes red, help track down why. A clear diagnosis — the conditions, the trigger, the likely cause — is often more than half the fix, and it's some of the highest-leverage help you can give.

03
File and resolve bug reports

Open clear, reproducible bug reports — minimal steps, expected vs. actual, versions and environment — and help work existing ones toward resolution. A good report is a gift to the next person who hits it.

04
Maintain and translate documentation

Keep the docs accurate as the tools change, sand down the rough edges that tripped you up, and help make them available in more languages so more people can use these tools.

For developers

Development.

Anyone hoping to help develop and maintain our applications should be able to meet the bar we hold ourselves to. It's demanding on purpose — it's what keeps the tools dependable.

Fluency in the stack
Comfortable in the primary languages of whatever you're touching — PHP 8.3+ and TypeScript/JavaScript (Svelte / SvelteKit) on the platform side, Python where it's used, and Go for the infrastructure tools.
Type-safe by default
Write strictly-typed code. Validate every input at its boundary, and model domain values as typed primitives rather than passing raw strings and ints around.
Green before you push
Every change passes the full automated review gate with zero violations — static analysis, coding-standard checks, unit tests, spell-check, linting, dead-code and type checks. A pre-push hook refuses a red push; bypassing it is an emergency-only, flag-it-to-a-maintainer exception.
Tests are not optional
Every concrete class ships with a test, and new behavior arrives with the tests that prove it. "It works on my machine" isn't the standard; a passing suite is.
Standards are the source of truth
Read and follow the documented architecture and coding conventions, not just what the linters happen to catch. The docs define the bar; the tooling only enforces the machine-checkable part of it.
Clean git history
Work on feature branches off dev, land through reviewed no-fast-forward merges, and keep commits coherent and self-explanatory.
Don't loosen the bar
Don't disable or weaken a standard, a check, or a rule to make something pass. If a standard is genuinely wrong for the situation, raise it with a maintainer — don't quietly route around it.