Contributions are welcome. Contributors can file issues and pull requests on GitHub at https://github.com/btrettel/blastersim. Pull requests must meet the following requirements:
The scope of the change must be small enough for me to easily review. Keep the size of pull requests below about 400 new/changed lines, ideally less than 100 new/changed lines. Split large changes into multiple pull requests. If this is not possible, contact Ben Trettel before filing a pull request.
All commit messages must be descriptive. Use Conventional Commits prefixes. For bug fixes, if possible, refer to the issue ID number or commit introducing the bug with Fixes: #[issue ID] or Fixes: [commit hash] ("[commit message first line]").
Do not squash your commits before sending a pull request. That can make git bisect work poorly.
Contributed code must pass all existing tests. Contributed code with new functionality must add and pass new tests for the new functionality. Existing tests can be run with make check on Linux and macOS and jom check on Windows as discussed in § 3. The tests themselves are in the test directory and are Fortran code. Contributors should examine existing tests to understand the testing system.
Add assertions as appropriate to new code.
New features must be documented. See the docs directory for this documentation’s source code in LaTeX.
BlasterSim uses trunk based development. In other words, there are no release branches and instead releases are noted with tags. Temporary feature branches are used as necessary.
Contributing validation data would be particularly welcome. To contribute validation data, recreate the experimental conditions in BlasterSim and file an issue with the BlasterSim inputs, file a pull request, or contact Ben Trettel directly.
A note on generative AI: To date, all BlasterSim code and documentation are written by a human. AI was used in BlasterSim’s development only as a research and learning tool, not to write code or documentation. I am willing to accept LLM-written code and documentation that meets the pull request requirements listed above, with two additional requirements:
The prompts used to generate the code will need to be provided in the pull request. This allows me to get a better sense of what was focused on so I can focus my own checking in the most productive spots.
The new/modified parts of the documentation must not be in a LLM writing style or be rated as likely coming from a LLM from any of the LLM writing detectors like Pangram. I personally find “Claudish” to be annoying and difficult to read. This is also a trust issue, as many people do not trust writing by LLMs.