Skip to content

Latest commit

 

History

History
183 lines (120 loc) · 6.7 KB

CONTRIBUTING.md

File metadata and controls

183 lines (120 loc) · 6.7 KB

Contributing to kwx

Thank you for your consideration in contributing to this project!

Please take a moment to review this document in order to make the contribution process easy and effective for everyone involved.

Following these guidelines helps to communicate that you respect the time of the developers managing and developing this open source project. In return, and in accordance with this project's code of conduct, other contributors will reciprocate that respect in addressing your issue or assessing patches and features.

Contents

Development environment

Please follow the steps below to set up your development environment for kwx contributions.

Clone repository

# Clone your fork of the repo into the current directory.
git clone https://github.com/<your-username>/kwx.git
# Navigate to the newly cloned directory.
cd kwx
# Assign the original repo to a remote called "upstream".
git remote add upstream https://github.com/andrewtavis/kwx.git
  • Now, if you run git remote -v you should see two remote repositories named:
    • origin (forked repository)
    • upstream (kwx repository)

Environment

Create a virtual environment for kwx (Python >=3.12), activate it and install dependencies.

Note

First, install uv if you don't already have it by following the official installation guide.

uv venv

uv sync --all-extras  # create .venv and install all dependencies from uv.lock

# Unix or macOS:
source .venv/bin/activate

# Windows:
.venv\Scripts\activate.bat # .venv\Scripts\activate.ps1 (PowerShell)

Conda

Download Anaconda if you don't have it installed already.

conda env create --file environment.yaml
conda activate kwx-dev
uv pip install -r <(uv export --format requirements-txt)  # install all dependencies from uv.lock

Note

If you change dependencies in pyproject.toml, regenerate the lock file with the following command:

uv lock  # refresh uv.lock for reproducible installs

pre-commit

After activating the virtual environment, set up prek for pre-commit hooks by running:

# In the project root:
prek install

# Then test the pre-commit hooks to see how it works:
uv run prek run --all-files

Note

If you are having issues with prek and want to send along your changes regardless, you can ignore the pre-commit hooks via the following:

git commit --no-verify -m "COMMIT_MESSAGE"

Back to top.

Using the issue tracker

The issue tracker for kwx is the preferred channel for bug reports, features requests and submitting pull requests.

Back to top.

Bug reports

A bug is a demonstrable problem that is caused by the code in the repository. Good bug reports are extremely helpful - thank you!

Guidelines for bug reports:

  1. Use the GitHub issue search to check if the issue has already been reported.

  2. Check if the issue has been fixed by trying to reproduce it using the latest main or development branch in the repository.

  3. Isolate the problem to make sure that the code in the repository is definitely responsible for the issue.

Great Bug Reports tend to have:

  • A quick summary
  • Steps to reproduce
  • What you expected would happen
  • What actually happens
  • Notes (why this might be happening, things tried that didn't work, etc)

Again, thank you for your time in reporting issues!

Back to top.

Feature requests

Feature requests are more than welcome! Please take a moment to find out whether your idea fits with the scope and aims of the project. When making a suggestion, provide as much detail and context as possible, and further make clear the degree to which you would like to contribute in its development.

Back to top.

Pull requests

Good pull requests - patches, improvements and new features - are a fantastic help. They should remain focused in scope and avoid containing unrelated commits. Note that all contributions to this project will be made under the specified license and should follow the coding indentation and style standards (contact us if unsure).

Please ask first before embarking on any significant pull request (implementing features, refactoring code, etc), otherwise you risk spending a lot of time working on something that the developers might not want to merge into the project. With that being said, major additions are very appreciated!

When making a contribution, adhering to the GitHub flow process is the best way to get your work merged:

  1. Fork the repo, clone your fork, and configure the remotes:

    # Clone your fork of the repo into the current directory
git clone https://github.com/<your-username>/<repo-name>
# Navigate to the newly cloned directory
cd <repo-name>
# Assign the original repo to a remote called "upstream"
git remote add upstream https://github.com/<upsteam-owner>/<repo-name>

  2. If you cloned a while ago, get the latest changes from upstream:

    git checkout <dev-branch>
git pull upstream <dev-branch>

  3. Create a new topic branch (off the main project development branch) to contain your feature, change, or fix:

    git checkout -b <topic-branch-name>

  4. Commit your changes in logical chunks, and please try to adhere to Conventional Commits. Use Git's interactive rebase feature to tidy up your commits before making them public.

  5. Locally merge (or rebase) the upstream development branch into your topic branch:

    git pull --rebase upstream <dev-branch>

  6. Push your topic branch up to your fork:

    git push origin <topic-branch-name>

  7. Open a Pull Request with a clear title and description.

Thank you in advance for your contributions!

Back to top.