Document formatting expectations and supported Prettier workflow

CONTRIBUTING.md

@@ -5,34 +5,43 @@ First off, thank you for considering contributing! It’s people like you who ke
 ## How Can I Contribute?
 
 ### 1. Adding a New Conference
-The most common way to help is by adding a conference that isn't on the list yet or updating one that is. 
+
+The most common way to help is by adding a conference that isn't on the list yet or updating one that is.
+
 - Search the current list to make sure it isn't already there.
 - Open a Pull Request (PR) adding the conference to the relevant data file.
 - Ensure you follow our data schema (see the `README.md` for field requirements).
 
 Use official sources for conference updates whenever possible:
+
 - Prefer the conference website or the organizer's official registration, CFP, or schedule page.
 - Use official social accounts only when the website is stale or incomplete.
 - When sources conflict, prefer the most specific current-year event page over a generic homepage or archived page.
 - Do not guess dates, locations, prices, CFP deadlines, or registration status.
 - If useful for visitors, preserve uncertainty in the `status` field rather than presenting unclear information as confirmed.
 
 ### 2. Reporting an Issue
+
 If you find a broken link, an incorrect date, or a bug on the site:
+
 - **Check the Footer:** Find the **Site Version** in the footer of the website.
 - **Open an Issue:** Include the version number and a description of the error.
 
 ### 3. Improving the Site (DX/Quality)
+
 We are currently working through our [ROADMAP.md](./ROADMAP.md) to improve site quality and developer experience. If you want to help with Lighthouse scores, build scripts, or automation, please check the roadmap for "Open" tasks.
 
 ### 4. Adding or Updating Site Pages
+
 If your PR adds a new page or updates page-level navigation:
+
 - **Main/Sub Navigation:** Do not automatically add new pages to `_includes/nav.html`. Confirm with a maintainer first, since not every page belongs in the main or sub navigation.
 - **Superfooter:** Add all pages to the superfooter in `_includes/footer.html` so they can always be discovered from the site footer.
 
 ---
 
 ## Pull Request Guidelines
+
 To help us review your changes quickly, please follow these steps:
 
 1. **Fork the repo** and create your branch from `main`.
@@ -48,8 +57,42 @@ ruby tools/validate_data.rb
 
 Do not edit files in `_site/` directly. That directory is generated by Jekyll; make changes in the source files and regenerate the site instead.
 
+## Formatting and Linting
+
+This repository intentionally keeps formatting simple and tool-light. The project already includes a minimal Prettier configuration in `.prettierrc` and a narrow ignore rule in `.prettierignore`:
+
+- `tabWidth: 2`
+- `useTabs: false`
+- `_includes/*.html` (ignored): hand-authored template partials are intentionally excluded to avoid churn
+
+Use Prettier on the files you touch before opening a PR. The supported workflow is:
+
+```bash
+npx prettier --write path/to/file.md
+```
+
+To validate formatting locally, run:
+
+```bash
+npx prettier --check path/to/file.md
+```
+
+This is intentionally scoped to the files changed in a PR rather than a full repository reformat. We do not currently add ESLint, markdownlint, yamllint, or pre-commit hooks unless they clearly add value without slowing down contributors or conflicting with the existing Jekyll and validator checks.
+
+### Formatting Expectations by File Type
+
+- Markdown: keep headings, lists, and links readable; let Prettier handle wrapping and list formatting.
+- YAML: preserve two-space indentation, keep `_data/*.yml` order chronological, and quote values only when YAML parsing would be ambiguous.
+- HTML: keep templates readable and do not edit generated `_site/` output by hand.
+- CSS/SCSS: use two-space indentation and keep related selectors grouped logically.
+- JavaScript: format with Prettier defaults and avoid unrelated refactors in the same change.
+
+The main validation path remains the repo's existing checks: `ruby tools/validate_data.rb`, the valid-data tests, and the Jekyll/htmlproofer build. Additional linting tooling should only be added if it catches real issues without overhead or conflicts with the current workflow.
+
 ## Community Guidelines
+
 We strive to maintain a welcoming and inclusive environment for everyone who contributes to this project.
 
 ---
+
 **Need help?** If you have questions about how to contribute, feel free to [open an issue](https://github.com/TestingConferences/testingconferences.github.io/issues/new/choose) and we'll help you get started!