Skip to content

CONTRIBUTING.md

Latest commit

 

History

History
105 lines (56 loc) · 3.95 KB

CONTRIBUTING.md

File metadata and controls

105 lines (56 loc) · 3.95 KB
Raw

Contributing Guide

Thank you for considering contributing to sparqlx!

This document outlines how to participate constructively. Please read these guidelines before opening Issues or Pull Requests.

Table of Contents

Vision

sparqlx aims to be a modern Sync/Async SPARQL 1.2 Protocol client based on httpx.

The library should be as simple as possible but no simpler.

This means e.g. that

  • sparqlx should do one thing well; i.e. the library shall provide solid core functionality and beyond that will prefer recipes and usage patterns over features

  • the implementation should be guided primarily by the SPARQL 1.2 Protocol specification

  • the library API aims to be simple and deep

I Have a Question

If you want to ask a question, we assume that you have read at least the README.

Before you ask a question, it is best to search for existing Issues that might help you. In case you have found a suitable issue and still need clarification, you can write your question in this issue. It is also advisable to search the internet for answers first.

If you then still feel the need to ask a question and need clarification, we recommend the following:

  • Open an Issue.
  • Provide as much context as you can about what you're running into.
  • Provide project and platform versions (nodejs, npm, etc), depending on what seems relevant.

We will then take care of the issue as soon as possible.

Styleguide

General

Please try to keep your commit changes focused on the change you want to implement - don't start fixing typos if your commit is actually about adding a feature.

sparqlx uses ruff for linting and code formatting.

sparqlx also uses the deptry dependency checker for detecting missing or unused dependencies.

Commit Messages

sparqlx uses conventional commits so please format your commit messages accordingly. The sparqlx repo runs a GitHub Action that uses the Gitlint linter to check commit messages for validity.

Consider using a scope when writing a commit message. See Commit message with scope.

Issues-Before-Pull-Requests Policy

To keep the project focused, maintainable, and aligned with its vision, sparqlx follows an Issue-first workflow.

All PRs should reference an existing issue.

If you want to propose a change - whether it’s a bug fix, refactor, feature, or documentation update - please follow this process:

  1. Open an Issue describing the problem/motivation/rationale and (optionally) a proposed approach towards Issue resolution.

Issues must be narrow in scope and focus on a single topic.

  1. Wait for maintainers to acknowledge or discuss the proposal.

Discussion should happen on the Issue and confirm scope, direction, and/or alternatives.

  1. Only after the Issue is acknowledged, open a Pull Request that explicitly references it

Pull Requests must be narrow in scope and focus on a single topic.

Git/Github Workflow

sparqlx uses a rebase workflow to keep history clean.

Please:

  • Base your branch off the latest main

  • Avoid merge commits in feature branches

  • Ensure each commit is logically focused

Anti-AI-Slop Policy

This project values clarity, maintainability, and human intent in contributions.

Submissions that appear to be AI output may be closed without review.

Please be a good Homo Sapiens and use your brain.