Standardize an approach to documenting implementation/project plan changes

[zackkrida]

Often in the project lifecycle we uncover problems which require alterations to our original planning documents. We want to update the documents to reflect the actual work that needs to happen, but we also want to preserve the original approach and make others aware that the document has changed.

We should develop a standardized method for addressing these updates. I would propose we add a changelog section to the plans like so:

## Changelog

- [Date of changes](Link to changeset PR diff) - Summary of changes made to the plan

I am open to alternative suggestions! I'll mark this as blocked until at least one @WordPress/openverse-maintainers has reviewed the proposal.

[sarayourfriend]

Idea is fine to me, I don't have any reason to block it, and it accomplishes a minimal level of visibility. It's kind of frustrating that it's just duplicating the git history for the file on main, but I don't have any easy ideas that would have this level of visibility whilst avoiding that duplication.

Some questions need to be answered, though: Should this section go at the top of the IP whenever a change is made? Does it exist when the document is made first-off and include the "Add whatever document" as the first entry? Does it matter? If visibility is important, I guess it does?

An alternative that is not an explicit changelog is to expect authors to note where plans have changed as footnotes with links to the relevant PRs and discussions. That's a bit more natural, and leaves less room for out-of-context confusion looking at the changelog at face value.

[dhruvkb]

Seems fine to me as well. I like that it's separate from the commit history as a change to the plan can be spread across multiple commits, and there can also be commits in the Git history that are associated with smaller inconsequential things (like typo fixes) that do not need to go in a changelog.

[AetherUnbound]

I think this is a great idea! To give some opinions on @sarayourfriend's thoughts:

• I don't think it should be included by default (because thus far, it's been a small minority of IPs that have required changes)
• I think it should be included at the end, since someone reading the updated document from top to bottom won't have the context needed for understanding what's described in the changelog when first reading the document.
• I also like the footnote approach but given that the changes could be numerous throughout the document/appear in a few places, summarizing that as a single point and linking to the relevant PR(s) which would show the changes feels like it would result in a more approachable document for someone trying to see the changes.

On formatting, because we automatically link PR numbers already, I think the format could be:

## Changelog

- Date-of-changes - (#ChangesetPRNumber) Summary of changes made to the plan