We welcome contributions of all kinds, whether it’s fixing a bug, improving documentation, or adding new functionality.
If you discover issues, have ideas for improvements, or would like to propose new features, please open an issue in the relevant repository or submit a pull request.
Please follow the guidelines below when contributing.
This project is part of The Lupaxa Project.
Organisation-level structure and decision-making are defined centrally in the .github repository:
Please review these documents for details on how decisions are made, who the maintainers are, and how repositories are grouped across the ecosystem.
Before submitting an issue:
- Check the latest code: the issue may already be fixed.
- Check for duplicates: search existing issues to ensure it hasn’t already been reported.
- Be clear and concise: describe the problem precisely and completely.
- Use a descriptive title: fill in all issue form fields in complete sentences.
- Include details: specify the version, environment, or configuration used.
- Provide examples: minimal code samples or reproduction steps help us diagnose faster.
If you have an idea for a new feature or improvement that you’d like to see but don’t plan to implement yourself, please open an issue using the Feature Request template.
Explain why the feature is valuable and include use cases or examples where possible.
- Read How to Properly Contribute to Open Source Projects on GitHub.
- Fork the project and create a feature branch (not
master). - Write Good Commit Messages.
- Follow existing code style, documentation, and testing conventions.
- Include or update tests for any new code.
- Ensure all tests pass before submission.
- Squash Related Commits Together before opening your PR.
- Open a Pull Request focused on a single, clear change, with a descriptive title and full sentences.
Important
We reserve the right to request changes or reject pull requests that don’t meet these standards. We will always provide constructive feedback to help you align with our practices.
All commits must be GPG- or SSH-signed to verify the developer’s identity.
To sign your commits:
git commit -S -m "Your descriptive commit message"For details, see GitHub’s Guide to Signing Commits.
Important
Unsigned commits will be rejected automatically.
To maintain consistency across all repositories in The Lupaxa Project, we use a structured label system based on four categories:
Choose one label to describe the nature of the issue or PR:
| Label | Description |
|---|---|
| type: bug | Something is broken. |
| type: feature | New functionality. |
| type: enhancement | Improve existing functionality. |
| type: documentation | Documentation-only changes. |
| type: maintenance | Internal housekeeping. |
| type: security | Security-related issue or fix. |
| type: tests | CI/testing changes. |
| type: refactor | Internal code restructure. |
| type: performance | Speed or efficiency improvement. |
| type: breaking change | Backwards-incompatible change. |
| type: question | General inquiry. |
| type: good first issue | Friendly for newcomers. |
| type: duplicate | Duplicate of an existing issue. |
| type: dependencies | Dependency updates. |
Choose one label indicating severity or urgency:
| Label | Description |
|---|---|
| impact: critical | Causes complete failure of the system, major security breach, or data loss. Immediate action required. |
| impact: high | Seriously degrades functionality or security. Work cannot continue without a workaround or fix. |
| impact: medium | Noticeable issue that affects usability or reliability, but system remains functional. |
| impact: low | Minor problem with limited effect on users or functionality; cosmetic or localized. |
| impact: informational | No direct impact, useful for tracking ideas, questions, clarifications, or non-actionable findings. |
| impact: none | Does not affect functionality, security, or user experience; administrative or meta-only change. |
Use these labels to track workflow state:
| Label | Description |
|---|---|
| state: triage | Needs evaluation. |
| state: confirmed | Verified and reproducible. |
| state: accepted | Approved for work. |
| state: work in progress | Being actively worked on. |
| state: complete | Work done but not released. |
| state: blocked | Blocked by dependency or external factor. |
| state: stale | Inactive for a long period. |
| state: keep | Explicitly not to be auto-closed. |
| state: help wanted | External assistance welcome. |
Added only when closing issues or PRs:
| Label | Description |
|---|---|
| resolution: released | The issue has been fixed and the change is included in a released version. |
| resolution: closed | The issue has been addressed or is no longer relevant; no further action needed. |
| resolution: invalid | The issue does not represent a problem (e.g., user error or misunderstanding). |
| resolution: can't replicate | The reported problem cannot be reproduced with available information. |
| resolution: won't fix | The issue is acknowledged but will not be resolved due to design choice, low value, or planned deprecation. |
A well-labelled issue or PR typically has:
- 1× type
- 1× impact
- 1× state
- 1× resolution (added when closing)
Example
| Category | Label |
|---|---|
| Type | type: bug |
| Impact | impact: high |
| State | state: confirmed |
| Resolution | resolution: released |
This organisation follows a Code of Conduct. By participating in any repository, discussion, or community under The Lupaxa Project, you agree to uphold these principles.
© The Lupaxa Project.
Where exploration meets precision.
Where the untamed meets the engineered.