Skip to content

Contributor workflow

Jump to bottom
Joel B edited this page May 12, 2026 · 1 revision

This page covers how we work together on Pynventory: the contributor workflow, collaboration rules, and communication.

For Git command reference, see Git commands.

Before you start

To configure your Git identity:

git config --global user.name "Your Name"
git config --global user.email "your-email@example.com"

Use a private email if you want to keep your address hidden. GitHub provides one: GitHub private email.

How we work

Branch-based development

All work happens on branches. Never code directly to master.

Recommended flow:

  1. Check if an issue already exists.
  2. If no issue exists, create one.
  3. Add the correct label.
  4. Link the issue to the project board.
  5. Create the branch from the issue's Development section.
  6. Work on that branch.
  7. Open a pull request back to master.

No direct pushes to master

Every change goes through a pull request.

Before you start coding

Open a GitHub issue before writing code. This keeps work visible and avoids wasted effort. Describe:

  • what you want to change
  • why it should be changed
  • your rough idea for the approach

Then add the appropriate label and link the issue to the project board.

Pull requests

Opening a pull request

Before opening a PR:

  • git status only shows files that belong to your change
  • data/products.db is not included
  • the app starts with python -m pynventory.main
  • you manually tested the behavior you changed
  • Ruff has been run
  • the pull request links to the relevant issue

Go to the repository on GitHub. You will see a banner suggesting you open a pull request. Fill in the template and select a reviewer.

Addressing review feedback

Make changes on the same branch, commit, and push again. The pull request updates automatically.

Definition of done

Once a pull request is approved, the author merges it and deletes the old branch.

git checkout master
git pull origin master

Code review

At least one other contributor must review your pull request before it can be merged. See the Code review page for the full review process, checklist, and how to use GitHub's review UI.

Communication

  • Ideas, bugs, and feature requests -> GitHub Issues
  • Pull request discussions -> keep them on the PR page
  • Quick questions -> open an issue with the question label
  • Team discussion -> Discord

Common labels:

  • bug - something is broken
  • new feature - new feature or improvement
  • documentation - docs or wiki changes
  • question - clarification needed
  • good first issue - suitable for new contributors
  • help wanted - extra attention is needed

Keep the project board updated so it matches the status of your work.

Database note

The project uses SQLite at data/products.db. This file contains local development data and must never be committed. If it appears in git status, leave it unstaged. See Troubleshooting for help.

Clone this wiki locally