Many people seem to enjoy editing CVE entries directly to demonstrate what they'd like to see changed -- this is especially true for people who disagree with ADP opinions on CPEs, CWEs, and CVSS scores. And, while we definitely want to hear about these other opinions, PRs tend to see this kind of workflow:

• External contributor forks and edits and pull requests, all in the usual way
• Maintainer sees the PR, might have a little discussion, and possibly agrees with the external assessment.
• If agreed, maintainer might land the PR, or might not, because the actual change needs to happen to the relevant metric on the backend, and publish that fix.
• If the provided PR doesn't land, the contributor doesn't get the nice little dopamine hit from having a successfully merged PR.
• If the provided PR does land, it ends up being kind of meaningless in a practical sense, since it'll be overwritten by the next scheduled push from the backend. So, at best, this is a NOP workflow. At worst, merge conflicts happen.

The easy answer is to reject all PRs to CVEs, but that kind of sends a message of "thanks, don't care."

Perhaps some guidance in a CONTRIBUTING.md doc about how to use PRs? Basically, we should outline that we definitely can accept PRs to pretty much anything that's not a CVE entry, and cannot practically accept PRs to CVEs.(but can perform edits and push)

Up for discussion. I don't want to rob people of internet points, but I also don't want to encourage broken and risky workflows.