mirror of
https://github.com/pumpitupdev/pumptools.git
synced 2026-09-29 10:18:14 +03:00
58 lines
3.6 KiB
Markdown
58 lines
3.6 KiB
Markdown
# Contributing
|
|
|
|
Please have a look at the issue board about what's currently going on. If you see an issue that is not assigned yet and
|
|
that you can and want to work on, please leave a comment to reach out to one of our developers. You can also ask
|
|
questions and discuss the issue.
|
|
|
|
# Bug reports
|
|
|
|
Please check if the bug was already reported by searching the existing issues. If it does, feel free to leave a comment
|
|
that you also have this issue. Add additional information, screenshots, log files etc. The more information and details
|
|
we have, the easier it might get to solve the issue.
|
|
|
|
When creating new issues, use our template for reporting bugs. It tells you what kind of information we need.
|
|
|
|
# Use of LLM tools
|
|
|
|
Using large language models and other generative tools is allowed. The person using the tool remains responsible for
|
|
the contribution and its communication.
|
|
|
|
LLMs should assist with work that the contributor understands well enough to direct, review, and validate. They may
|
|
perform implementation, research, analysis, documentation, or other leg work, but the contributor must check their
|
|
output before submitting it to maintainers. The usual requirements for correctness, testing, documentation, security,
|
|
and compatibility apply regardless of how the work was produced.
|
|
|
|
An exception may be made when the maintainers have agreed in advance to receive an explicitly unvetted or deliberately
|
|
rough prototype. Its purpose, limitations, and verification status must be clear.
|
|
|
|
Interactions with maintainers in issues and pull requests must be actively driven by a human. Reviewed LLM-generated
|
|
material may be included directly when it usefully communicates code analysis, technical explanations, test results,
|
|
or similar evidence; rewriting it solely to conceal its origin is not required. However, a human must decide what is
|
|
relevant, provide the surrounding context, initiate and guide the discussion, and respond to maintainer feedback.
|
|
|
|
Do not use an LLM or automated agent to autonomously post comments, reviews, or replies, or to flood maintainers with
|
|
unfiltered output. Contributions and discussions should present concise, relevant, human-reviewed information rather
|
|
than transferring the burden of reviewing raw LLM output to the maintainers.
|
|
|
|
# Pull requests: bugfixes, new features or other code contributions
|
|
|
|
Pull requests are welcome! May it be a PR to an already known issue or a new feature that you consider as a valuable
|
|
contribution, please open a PR. If you want to start working on a new feature that was proposed in an issue, yet, it
|
|
is recommended to reach out to the developers about this, first, to discuss if this contribution is valuable to the
|
|
project. Otherwise, you might waste your time on implementing something that won't make it into master.
|
|
|
|
Please read our [development guidelines](doc/development/development.md) as they contain valuable information that your
|
|
contribution meets our standards.
|
|
|
|
Fork the upstream repository and start developing on your personal fork. Make sure to test your changes with games that
|
|
are affected by them. Pay attention to the target platform/hardware you are testing on! This is valuable information
|
|
that should be included in the PR.
|
|
|
|
Once you completed your implementation, open a pull request on the upstream repository to propose your changes. We will
|
|
review your contribution and get back to you about any changes or when we merge them to our upstream repository. Your
|
|
changes, once approved, will be included in the next release.
|
|
|
|
# Roadmap
|
|
|
|
No concrete roadmap or timeline exists. When the time is right, we continue adding support for newer games as well.
|