Skip to content

CONTRIBUTING.md

Latest commit

 

History

History
98 lines (61 loc) · 4.69 KB

CONTRIBUTING.md

File metadata and controls

98 lines (61 loc) · 4.69 KB
Raw

Contributing to testingconferences.org

First off, thank you for considering contributing! It’s people like you who keep this list accurate and useful for the testing community.

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.

  • 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 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.
  2. Test your changes locally to ensure the build passes.
  3. Reference Issues: If your PR fixes a bug, include Closes #123 in the description.
  4. Style: Please match the existing formatting. The repo includes a Prettier config, but there is not currently an ESLint setup.

For conference data changes, run:

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:

npx prettier --write path/to/file.md

To validate formatting locally, run:

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 and we'll help you get started!