docs: Clarify documentation gaps across the project

[jmuzina]

Done

I'm leaving the project shortly, so I'm taking the opportunity to clarify some details and best practices that are mostly in my head or have become unspoken practice amongst Vanilla maintainers.

Check if PR is ready for release

If this PR contains Vanilla SCSS or macro code changes, it should contain the following changes to make sure it's ready for the release:

• [x] PR should have one of the following labels to automatically categorise it in release notes:
  • Feature 🎁, Breaking Change 💣, Bug 🐛, Documentation 📝, Maintenance 🔨.
• [ ] Vanilla version in package.json should be updated relative to the most recent release, following semver convention
  • if existing APIs (CSS classes & macro APIs) are not changed it can be a bugfix release (x.x.X)
  • if existing APIs (CSS classes & macro APIs) are changed/added/removed it should be a minor version (x.X.0)
  • see the wiki for more details
• [ ] Any changes to component class names (new patterns, variants, removed or added features) or macros should be listed on the what's new page.

[webteam-app]

Demo

Jenkins

demos.haus