From 0c710c910aacedfca229270c51d47a8871555c5a Mon Sep 17 00:00:00 2001 From: "copilot-swe-agent[bot]" <198982749+Copilot@users.noreply.github.com> Date: Mon, 7 Sep 2026 00:25:11 +0000 Subject: [PATCH 1/2] Initial plan From f0ef7855f3ad4a765402a78af01ff638e9a880b1 Mon Sep 17 00:00:00 2001 From: "copilot-swe-agent[bot]" <198982749+Copilot@users.noreply.github.com> Date: Mon, 7 Sep 2026 00:28:13 +0000 Subject: [PATCH 2/2] Apply remaining changes Co-authored-by: ckenst <6896787+ckenst@users.noreply.github.com> --- CONTRIBUTING.md | 45 ++++++++++++++++++++++++++++++++++++++++++++- 1 file changed, 44 insertions(+), 1 deletion(-) diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md index 0850ddab..6c2c1a08 100644 --- a/CONTRIBUTING.md +++ b/CONTRIBUTING.md @@ -5,12 +5,15 @@ 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. @@ -18,21 +21,27 @@ Use official sources for conference updates whenever possible: - 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!