BMM Developer Notes

Overview

Last update: 16.10.2026

These notes are for developers who want to add a model to bmm. They explain how the package is put together and walk through the steps of contributing a model, from setting up your system to opening the pull request.

bmm covers five kinds of tasks: continuous reproduction (mixture models, IMM, SDM), categorical recall and n-AFC decisions (M3), processing-tree models (MPT), detection, recognition and confidence judgments (the signal detection models), and choices with response times (DDM, EZDM, Censored-Shifted Wald). bmm_models() lists them. The package requires R >= 4.1.0 and uses the native pipe |> throughout.

This guide describes bmm at the v1.4.1 tag. Anything merged after that tag may not be reflected here yet. If you run into problems, open an issue on GitHub.

From idea to merged model

  1. Open an issue with the new_model template and agree with the maintainers on the model and the release it targets.
  2. Fork bmm, set up your system and create a branch named after the issue (1  System setup).
  3. Generate the model file with use_model_template() and fill it in (5  Adding a new model). Write the distribution functions first and the prediction functions after.
  4. Add the model’s tests and its test cases, and run document(), test() and check().
  5. Run a parameter recovery study, and add an example dataset, an article and a NEWS bullet.
  6. Open the pull request against the branch you started from and fill in the template (5  Adding a new model has the checklist).

How to read these notes

  1. System setup and Git workflow get you a working fork.
  2. Code structure explains what happens when a user calls bmm(), and Example models shows two real model files.
  3. Adding a new model is the step-by-step guide, ending with a checklist for the pull request.
  4. Coding conventions lists what review will check your code against.

The appendix, Reference, collects details you need only when you hit a particular problem, such as within-chain threading or a parameter name that collides with brms.

The rules for contributing

Which branch to target, what a pull request must contain, how many reviews it needs and how model fits for articles are handled are set out in bmm’s CONTRIBUTING.md. These notes do not repeat those rules. For a new model, two things matter from the start:

  • Open an issue with the new_model template first, so that you agree with the maintainers that the model fits the package and in which release it will appear.
  • Make the model easy to check. The reviewer reads your likelihood against its published source and looks at your parameter recovery. Include a short, runnable example with a small simulated dataset, and say in the pull request how long it takes to fit and what output to expect.