Contributing - Venom VNV Docs

Core Rules

fork first, then develop in your own repository
use Pull Requests by default
one branch should focus on one task
one PR should solve one clear problem

First Collaboration Cycle

Each new contributor should complete at least one full cycle:

fork -> clone -> branch -> commit -> push -> Pull Request -> review -> merge

Before that cycle is complete, direct write access to the main repository should not be assumed.

Branch Naming

Suggested names:

feat/<topic>
fix/<topic>
docs/<topic>
refactor/<topic>

Do not work directly on master.

Commit Message Style

Recommended prefixes:

feat:
fix:
docs:
refactor:
chore:

Examples:

docs: update developer onboarding guide
fix: unify point lio published frame ids

Pull Request Expectations

A good PR description should state:

what changed
why it changed
how it was verified
whether topics, TF, parameters, launch files, or docs were affected

Documentation Sync

Docs usually need updating when you:

add or remove a module
change launch commands
move parameter files
rename topics, TF frames, or frame IDs
change submodule URLs or repository structure

Submodule Workflow

If you modify a submodule:

fork the submodule repository
make and submit the submodule PR first
once that change is stable, update the submodule pointer in the main repository
then submit the main-repo PR

Avoid pointing the main repository at a submodule commit that exists only in a personal fork unless the team explicitly agreed on it.

Pre-Merge Checklist

only task-related files are included
no generated files from build/, install/, or log/ are included
no unrelated submodule pointer changed accidentally
the work is on your own branch
required documentation updates are included