- Issues should only be created for things that are definitely bugs. If you are not sure that the behavior is a bug, ask about it on GitHub Discussions. GitHub Issues should not be used as a help forum.
- Ensure the bug was not already reported by searching on GitHub under Issues.
- If you are sure it is a bug, then post a complete description of the issue, the simplest possible self-contained example showing the problem, and the full backtrace of any exception.
- Issues are generally closed as soon as the problem is considered fixed. However, discussion can still happen after the issue is closed, and the issue will be reopened if additional evidence is provided showing the issue still exists.
- Ensure the PR description clearly describes the problem and solution. Include the relevant issue number if applicable.
- Try to include tests for all new features and substantial bug fixes.
- Try to include documentation for all new features. In most cases this should include RDoc method documentation, but updates to the documentation site are also appropriate in some cases.
- Follow the style conventions of the surrounding code. In most cases, this is standard ruby style.
- All code in pull requests is assumed to be MIT licensed. Do not submit a pull request if that isn't the case.
- Please do not submit pull requests for code that is not ready to be merged. Pull requests should not be used to "start a conversation" about a possible code change. If the pull request requires a conversation, that conversation should take place on GitHub Discussions.
- Pull requests are generally closed as soon as it appears that the branch will not be merged. However, discussion about the code can still happen after the pull request is closed, and the pull request can be reopened if additional commits to the branch or other changes make it likely that it will be merged.