Welcome. The fastest path for a first contribution is one small, reviewable change with one clear user value. This 15-minute first contribution path helps you choose a lane, find an appropriately sized issue, and run a focused check before opening a pull request.
- Search the quick start, interfaces, and validation pages first.
- Ask for usage or documentation help with the question form.
- Report a reproducible regression with the bug report form.
- Propose one focused capability with the feature form.
- Report suspected vulnerabilities privately using SECURITY.md; do not put them in a public issue.
Good starting searches are good first issue and help wanted.
Pick one lane and keep the first change narrow. In every lane, finish with
git diff --check and describe the exact check in the pull request.
Edit the smallest page or example, then build the site strictly:
python3 -m mkdocs build --strict --site-dir /tmp/libgnsspp-siteInstall the pinned docs requirements from requirements-docs.txt first if
MkDocs is not available locally.
Keep the change focused on one CLI surface, helper, or pure-Python regression and run the small CLI UX suite:
python3 tests/test_cli_ux.pyFor a new pure-Python contract, add a stdlib-only test under tests/ and run
that file directly as well.
For a library, parser, or native CLI change, configure a Release test build and run the consolidated test target:
cmake -S . -B build -DCMAKE_BUILD_TYPE=Release -DBUILD_TESTING=ON -DGNSSPP_BUILD_PYTHON_BINDINGS=OFF
cmake --build build --target gnss_run_tests --parallel 2
ctest --test-dir build -R '^run_tests$' --output-on-failureUse a focused existing test or fixture when the full target is not needed, and state any dataset or credential requirement explicitly.
Keep the branch based on current develop, explain the user-visible value,
name non-goals, and include the smallest passing command. The longer
contributor guide covers PR boundaries and the broader CI
lanes.