PR label "Input Data Changes" is ambiguous

[DeniseWorthen]

Description

Currently a single PR label w/rt input-data is available (I believe previously there were additional labels, but they have been removed). The label is "Input Data Changes" with the definition: This PR requires changes to input data and to be sync'd across platforms.

In fact, there are two possible scenarios for input-data changes:

1. new input data is added (eg, a new test requiring new input-data). No existing data is changed.
2. existing input data is changed (eg, a change is required to a file(s) already present in the input-data)

For the first case, input-data can safely be added to the existing input-data directory used by the RTs.

For the second case, a new input-data directory needs to be created with any changes needed. When the PR that requires the changed data is committed, the date of the input data directory in rt.sh will be changed. This ensures that all previous hashes of the model can still run on the older input-data.

The current single label is ambiguous as to whether it applies to case 1 or case 2.

To Reproduce:

Additional context

Output

[gspetro-NOAA]

@DeniseWorthen There were indeed previously two separate labels. I believe @BrianCurtis-NOAA may have suggested consolidating, but perhaps I'm mistaken. In general, I think each PR makes clear whether it just requires an input file to be added or whether existing data is changed, necessitating a new input data directory. We therefore didn't feel that separate labels were needed for code management purposes. In other words, the "Input Data Changes" label can be applied in both case 1 and case 2 above. However, it wouldn't be a bad thing to mirror the language of the PR template and have two labels for the two cases you mention.

If we create new labels, I'll have to update the automation that's getting put in w/PR#2913 today to automatically update the project board status based on the labels, but that's not hard now that the infrastructure is in place. It does mean that creating/deleting labels could have downstream impacts.

[DeniseWorthen]

@gspetro-NOAA Thanks. I know from (hard) experience that the two cases have in fact been misunderstood and that explanation in the PR was in fact not sufficient to ensure that the correct action would be taken.

[BrianCurtis-NOAA]

@gspetro-NOAA @DeniseWorthen I've been torn on both sides of this. I would, though, even argue that "new baselines" and "baseline updates" could be consolidated into one label.

What's most important in my opinion, is that code managers are taking their time reading and understanding PRs and PR authors are taking their time filling out the PR template as best as they possibly can.

If we can't understand clearly what is happening to the input data, or what is happening with the baselines based on taking the time to read the PR description, then we need to make adjustments to the PR template to make it easier for PR authors and CMs to understand better what they need to put in the PR.

If I'm browsing GitHub PRs, i don't need 2 input data and 2 baseline labels. I need to know which are changing inputs and which are changing baselines, and I'll read the PR to find out the specifics.

[DeniseWorthen]

@BrianCurtis-NOAA The consequences of not understanding what is written in the PR is so consequential for the input-data (breaking every previous hash of the UWM), that anything we can do to indicate what should NOT be done is good, imho.

Experience teaches best---I've been burned by someone sync'ing new input-data to the old input-data, so am less forgiving of relying on 'just read the PR'.

[BrianCurtis-NOAA]

@BrianCurtis-NOAA The consequences of not understanding what is written in the PR is so consequential for the input-data (breaking every previous hash of the UWM), that anything we can do to indicate what should NOT be done is good, imho.

Experience teaches best---I've been burned by someone sync'ing new input-data to the old input-data, so am less forgiving of relying on 'just read the PR'.

I hear you! It worries me more, if the people in charge of PR's (us) don't understand the code we're managing enough that we wouldn't understand the scope of the changes well enough to not mess up input-data.

(also highlighting the importance of backing up input-data to HPSS)