-
Notifications
You must be signed in to change notification settings - Fork 186
docs: Clarify documentation gaps across the project #5701
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: main
Are you sure you want to change the base?
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Pull request overview
This PR enhances project documentation by clarifying best practices, workflows, and conventions for Vanilla Framework maintainers. The documentation consolidates previously undocumented practices into accessible GitHub guides, supporting better onboarding and consistency across the team.
Key Changes
- Introduced new documentation files for language policy and CI overview
- Enhanced Percy workflow and hacking guides with additional context about examples, testing, and naming conventions
- Documented class name prefixes, patterns vs components terminology, and standalone/combined example conventions
Reviewed changes
Copilot reviewed 4 out of 4 changed files in this pull request and generated 3 comments.
| File | Description |
|---|---|
| guides/percy-workflow.md | Added cross-reference to hacking guide and tip about appending to combined.html files |
| guides/language.md | New file documenting en-US writing policy and mdspell usage |
| guides/hacking.md | Expanded with sections on examples relationship, combined examples, CI overview, patterns vs components, class prefixes, and language policy; fixed typo "name" → "named" |
| guides/ci.md | New comprehensive guide covering local checks, Percy, Jest, Parker, Cypress, and spelling |
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
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:
Feature 🎁,Breaking Change 💣,Bug 🐛,Documentation 📝,Maintenance 🔨.package.jsonshould be updated relative to the most recent release, following semver convention