Please open an issue if you have a bug to report.
The more detailed your report, the faster it can be resolved and will ensure it is resolved in the right way. I personally appreciate it when people not only open issues, but attempt to resolve them on their own by submitting a pull request. I am always open to constructive feedback, and I am by no means an expert, so guidance should always be considered welcome.
If you would like to help with documentation, please remember to update any and all module headers with the appropriate copyright dates, ranges, and authorship.
Expansions to the documentation are welcome, and appreciated. Every contribution counts.
If you would like to contribute code to fix a bug, add a new feature, or
otherwise improve group-theory
, pull requests are most welcome. It's a good idea to
submit an issue to
discuss the change before plowing into writing code.
If relevant, any and all claims of "performance" should be backed up with benchmarks. You can add them to the existing benchmark suite in your PR, as long as you do not make unjustifiable changes to the existing code.
The group-theory
project intends to focus on integration and usability,
balanced with maintainability. Please keep in mind that for a foundational
library like this, usability, portability, and API are what matters before
elegance.
All new code should be covered by tests. Additionally, if you find uncovered material in the existing codebase, tests are always appreciated as pull requests.