Add documentation about how to handle closely related packages
Some packages are designed to work well together, or one package may not have any use at all without the other (e.g., {targets} and {tarchetypes}). There should be formal guidance on how to treat such packages during code review (under what circumstances should they be included in a single review vs. split, etc.)
cf https://github.com/ropensci/software-review/issues/401
we'd need guidance for the author guide (I'd probably recommend opening a pre-submission inquiry to help figure things out on a case by case basis) and the reviewer guide. Also maybe the editor guide (how exactly do you recruit reviewers for a probably more complex + time-consuming review process).
We'd also need to check how the infrastructure would handle this (cc @mpadge)
this comment https://github.com/lifewatch/mregions2/issues/17#issuecomment-1429545477 by @salvafern reminded me of this