Added changelog

[roll]

No description provided.

[cloudflare-workers-and-pages]

Deploying datapackage with    Cloudflare Pages

Latest commit:	abae671
Status:	✅  Deploy successful!
Preview URL:	https://968c8771.datapackage.pages.dev
Branch Preview URL:	https://changelog.datapackage.pages.dev

View logs

[peterdesmet]

While the subheadings make sense to organize content, they do create a very long page and long navigation that is hard to scan: https://datapackage.org/standard/changelog/#v200-draft1

Can I suggest to:

1. Keep the organization per spec (Data Package, Data Resource, etc.) but list the changes as bullet points.
2. Start the sentences in the same way (New, Deprecated, etc.): makes it easier to scan.
3. Not repeat "Please read more about ...", but rather include a link in the text.
4. Include the related pull request in parenthesis at the end.

Example:

Data Package

• New properties contributor.given and contributor.familyName: these contributor properties will make it easier to generate a citation (#20).
• New property contributor.roles: allows to indicate multiple roles for a contributor, replacing contributor.role (singular) (#10).
• Deprecated property contributor.role: deprecated in favour of contributor.roles (plural), see above (#10).

@roll let me know if you prefer me to take a stab at it.

Guidance: https://style.tidyverse.org/news.html

[roll]

@peterdesmet
I started with this classical software-based template like yours and during the work, run into a few thoughts:

• some changes might require more extensive description rather than a single line e.g. software implementation notes, migration notes etc. Currently, I haven't filled it to this extent but I think we might need to extend some sections. We can have a separate document Migration for it but I thought what if we can stick to not duplication and have one source of truth for all changes
• opposite to software my guess that the standard won't have a lot of changes that needs to be mentioned in the Changelog, now we're doing a lot, but I expect like 2-3 new feature per year going forward, so it might be more important to have full human-readable description for all of them
• I tried to use PRs as a main source of truths if I were a user and realized that they just not clean enough way of presenting information for external user/reader/implementor (of course, super useful for contributors)
• using headings make every change linkable so e.g. if a software implementation needs to create a v2 checklist they can just use links to individual changes like https://datapackage.org/standard/changelog/#added-contributorgivenfamilyname
• and regarding scanning my thinking was that TOC is the cleanest way to present list of changes as it doesn't have any additional textual noise (similarly how we use e.g. API references):

---

Do you mind trying alternative with a small PR (maybe just for subset of changes to showcase the template). The deployment system will automatically publish a PR website so we can e.g. decide what works better on the next community call or in an issue