PR merge order strategies

[pratikunterwegs]

This discussion is about PR merge order strategies and stems from my experience following the {epidemics} development day and subsequent contributions

Context: Multiple contributors opened PRs into {epidemics} main, with some conflicts between PRs (despite trying to avoid this by opening orthogonal issues - cannot account for everything). This is likely to recur as we have more such development days.

Goals: Find a strategy that minimises work and time spent for maintainers, PR contributors, and reviewers, while also minimising errors during rebases and conflict fixing.

After the {epidemics} development day I did not have a specific strategy for the order in which multiple PRs should be merged (see attached image for final merge order), and came up with the following general order:

1. Merge fixes for bugs that prevent package functioning first (to facilitate any further contributions);
2. Merge PRs targeting the documentation next as they rarely affect the source code;
3. Merge small, orthogonal PRs targeting single files in the source code, with corrections to any documentation affected (as these should ideally be bundled in the same PR);
4. Merge PRs affecting multiple files last.

My thinking around this is based on a weighted shortest task approach, where I (inverse) rank the tasks by the amount of work they would take in terms of rebasing and fixing conflicts and the time priority. To take a specific example from {epidemics}, a fix that allows users to install the package at all, such as epiverse-trace/epidemics#129, was both short and high priority. Then, PRs adding vignettes involved changes to a small number of files (not counting formatting; see e.g. epiverse-trace/epidemics#131), while a PR targeting the source code went last (epiverse-trace/epidemics#130).

Happy to kick off this discussion and hopefully work towards a PR merge order strategy or guidelines for Epiverse.