These are informal guidelines intended to make contributing easier for everyone - both maintainers and contributors. They help save time, reduce friction, and outline the basic expectations and social contract for working on this project.
Contribution intentionally submitted for inclusion into this project, shall be licensed as MIT, without any additional terms or conditions.
The pbuildrs project adheres to the Rust Code of Conduct. This
describes the baseline behavior expected from all contributors.
Please do not use an LLM to generate bug reports, issues, discussions or PRs on your behalf. Feel free to get LLM assistance for parts where you need them, but do not simply tell an LLM to generate things and submit them. Make sure you actually verify everything, twice. This will help save everyone a lot of time, believe me.
There are a few ways one can contribute to this project:
- Submitting a bug report;
- Confirming a reported bug;
- Fixing a reported bug;
- Submitting a feature request;
- Implementing a feature request;
- Helping triage and resolve open issues;
- Improving documentation;
Found a bug? Great, maintainers will be glad to know about it!
First, check if this bug is already reported. Prefer 👍 reaction on the issue over the "affects me too message". Do provide any additional context however if you can, it helps immensely!
If no issue open issue exists for this bug, please open a new issue and provide a detailed description of the problem you are facing. Include reproduction steps, code examples, information about your environment, the expected outcome and what actually happens when a bug occurs. This helps maintainers, because they don't have to chase you for additional information and context, but also helps you as you don't have to go and collect extra information later.
If you see an open issue with a bug report and you are facing the same problem, or if you just want to help and verify that a bug is valid, please go through the information in the report, ensure it is complete and no context is missing, try reproducing the problem or add additional reproduction steps if you can. By doing so you either would ensure that the bug is actually legitimate and needs attention or you might even be able to discover some context that helps fixing it.
If you discovered a bug and opened an issue, or if you discovered an already reported bug that you know how to fix, feel free to open a pull request with a proposed fix and let's work together on fixing it. Make sure that the bug is actually confirmed though, so you don't waste your time writing code and maintainers' time reviewing and triaging it.
Got a cool idea for a feature? Awesome! Let's work together and see if we can make it happen.
First, please check any existing discussions and see if this idea or any similar ones were already or are actively discussed and what the outcome is. Do provide any feedback or extra context as needed.
If your idea is unique, and nobody has thought about it before - congratulations! Please open an issue and describe the feature request in detail. Doing so allows to make sure that the idea aligns with this project goals and its direction. If all goes well, the maintainers will turn this into an issue or ask you to do so. At this stage the feature is ready to be implemented.
Please note, not all feature requests will be accepted. This is the main reason to start the conversation first and avoid wasting effort writing any code.
Have you submitted an idea that was accepted by the maintainers and you want to implement? Or did you see an open issue for a feature request that is ready to be implemented but nobody works on and you want to do so? Excellent, we love to see external contributions!
Please, comment on the issue and mention that you are going to be working on it and feel free to open a PR with proposed implementation. Work with maintainers and other contributors to land the change into the default branch.
While creating and fixing bug reports, and submitting and implementing feature requests are primary forms of contribution, help with triaging and resolving issues and providing feedback on pull requests is always greatly appreciated.
If you see an issue or a pull request and you can contribute additional context to or can help drive to the resolution, please do os if time permits.
Adding new documentation, helping improve existing one, providing examples, clarifying any confusing parts is always welcome. Feel free to open a PR with proposed suggestions and work with other contributors and project maintainers to land your changes.
If you need help with this project, please start a new discussion, do not submit an issue.