CommentsGA

Additional / expanded comments

it will likely to be important to set a trunk date threshold for submissions to the committee - i.e. your new change will only be considered if it is based on trunk vXX or newer (say 6 months). The tighter that threshold, the more the onus is on users to update from the trunk, and the less work the committee (and particularly Jhan) will need to do to actually include proposed changes. It might be a mechanism to keep everyone in sync a little better.
clarifying what “improved” means is important - at very least the impact of a proposed change on metrics beyond the proposer’s interests (i.e. across C, water and energy at global scales, both offline and potentially AMIP) will be key to stability
we still need a mechanism to ensure relevant research is coordinated by the appropriate CABLE WG - that no-one is left out
we also currently have no formal mechanism to (a) decide when we change which parametrisations CABLE uses by default (either offline or in ACCESS), (b) reduce the number of switches / switchable sections in the code, and (c) formally map the compatibility or incompatibility of different switchable options within CABLE beyond the default settings. These are three separate but clearly related problems.