1 System setup

1.1 Setting up a local fork of the bmm repository

Fork the bmm github repository. This will create a copy of the current development branch into your own github account
Clone your fork to your local machine
Create a new branch for your model off develop. Open an issue first and name the branch after it, as <issue-number>-short-description (for example 349-lba-model). That is what the branches in the main repository look like, and it makes the branch, the issue and the eventual pull request easy to line up.

1.2 Prerequisites

The bmm package requires R >= 4.1.0 (for native pipe |> support). The package works with both rstan and cmdstanr backends. cmdstanr is generally recommended for faster compilation and better error messages. You can install it with:

install.packages("cmdstanr", repos = c("https://stan-dev.r-universe.dev", getOption("repos")))
cmdstanr::install_cmdstan()

1.3 Package development with devtools

Development runs on the devtools package, and the steps below are the same whichever editor you work in. The repository ships a bmm.Rproj file, so opening it starts a session with the package root as the working directory in RStudio or Positron; opening the directory in any other editor, or starting R in it from a terminal, gets you to the same place. A great tutorial on package development can be found here. Below is a summary of the most important steps

Make sure you have the devtools package and a few others installed and loaded
```
install.packages(c("devtools", "roxygen2", "testthat", "knitr"))
library(devtools)
install_dev_deps()
```
Optionally, to avoid loading devtools in every session, you can add the following to your .Rprofile
```
if (interactive()) {
  suppressMessages(require(devtools))
}
```
As noted here, you can create and open an .Rprofile file, if you don’t already have one with
```
use_devtools()
```
Load the current version of the bmm package based on your local files
```
load_all()  # ctrl+shift+L in RStudio
```
you can use this command whenever you make changes to the package code to see the changes in action. You should not call library(bmm) or source the files manually, as this will load the installed version of the package, not the one you are developing.
Make any changes to the package code that you need to make (elaborated in the next section)
Use check() to check the package for errors and warnings
```
check()
```
you should always ensure that check() produces no errors before submitting a pull request
Use document() to update the documentation
```
document()
```

1.4 Untracked scratch work

Development produces files that belong on your machine rather than in the package: exploratory scripts, fitted model objects, scratch data. bmm’s .gitignore excludes local/ for this purpose — AGENTS.md describes it as machine-specific scratch that is neither synced nor shared — so anything you put there stays out of your commits. Nothing requires you to use it; any location git ignores will do.

Parameter recovery scripts are the main thing you will keep out of the package this way. What the study has to show, and how it reaches the reviewer given that it is not committed, is in Chapter 6.