Baseline status regressions should be more obvious on review

[ddbeck]

It'd be nice if PRs that change a feature's Baseline status from high or low to false get more scrutiny. I'm imagining a GitHub Actions workflow that leaves a comment or appends to the PR description when this happens.

I didn't notice that popover regressed when I upgraded BCD in #1797. Discovered via GoogleChrome/webstatus.dev#739

[ddbeck]

The calculation is correct with respect to the data, so it's not a bug. But I believe this is the first time that we've moved a recent feature's status backwards solely on a BCD upgrade, which changes many files. Without a little more attention, we might allow an unintended status change to take place (e.g., from a later addition being tagged in BCD).

[jcscottiii]

Hey @ddbeck!

Thoughts on this one too?

GoogleChrome/webstatus.dev#740

[ddbeck]

Thoughts on this one too?

GoogleChrome/webstatus.dev#740

I've updated that issue with more information and a link to my related BCD PR: mdn/browser-compat-data#24720

Also, for anyone else following along with regards to the inciting popover feature. I shared my commentary (see GoogleChrome/webstatus.dev#739 (comment)) with the WebDX chat and—so far—there's agreement that popover's status is correct. I think that one will stand, but explicitly affirming that fact before releasing an update would've been nice.