Contributing to Rails Accessibility Testing
Thank you for your interest in contributing to Rails Accessibility Testing! This document provides guidelines and instructions for contributing.
π€ Code of Conduct
This project adheres to a code of conduct that all contributors are expected to follow. Please be respectful and constructive in all interactions.
π Getting Started
Prerequisites
- Ruby 3.0+ installed
- Bundler installed
- Git installed
- A GitHub account
Setting Up Development Environment
- Fork the repository
# Fork on GitHub, then clone your fork git clone https://github.com/your-username/rails-accessibility-testing.git cd rails-accessibility-testing - Install dependencies
bundle install - Run tests
bundle exec rspec
π Making Changes
Development Workflow
- Create a branch
git checkout -b feature/your-feature-name # or git checkout -b fix/your-bug-fix - Make your changes
- Write code
- Add tests
- Update documentation
- Test your changes
bundle exec rspec - Commit your changes
git add . git commit -m "Add: descriptive commit message" - Push to your fork
git push origin feature/your-feature-name - Open a Pull Request
- Go to the original repository on GitHub
- Click βNew Pull Requestβ
- Select your branch
- Fill out the PR template
π Commit Message Guidelines
We follow conventional commit message format:
type: short description
Longer description if needed
- Bullet point 1
- Bullet point 2
Types:
Add:- New featureFix:- Bug fixUpdate:- Update existing featureRefactor:- Code refactoringDocs:- Documentation changesTest:- Test additions/changesChore:- Maintenance tasks
Examples:
Add: support for custom accessibility rules
Allows users to define custom accessibility checks
beyond the default 11 checks.
- Add configuration for custom rules
- Add validation for custom rule format
- Update documentation
π§ͺ Testing
Running Tests
# Run all tests
bundle exec rspec
# Run specific test file
bundle exec rspec spec/path/to/spec.rb
# Run with coverage
COVERAGE=true bundle exec rspec
Writing Tests
- Write tests for all new features
- Ensure existing tests still pass
- Aim for good test coverage
- Test edge cases
π Documentation
Updating Documentation
- Update README.md for user-facing changes
- Update CHANGELOG.md for all changes
- Update inline code documentation
- Update setup guides if needed
Documentation Standards
- Use clear, concise language
- Include code examples
- Explain the βwhyβ not just the βwhatβ
- Keep examples up-to-date
π Reporting Bugs
Before Submitting
- Check if the bug has already been reported
- Check if itβs fixed in the latest version
- Try to reproduce the issue
Bug Report Template
**Describe the bug**
A clear description of what the bug is.
**To Reproduce**
Steps to reproduce:
1. ...
2. ...
**Expected behavior**
What you expected to happen.
**Actual behavior**
What actually happened.
**Environment**
- Ruby version:
- Rails version:
- RSpec version:
- Gem version:
**Additional context**
Any other relevant information.
π‘ Suggesting Features
Feature Request Template
**Is your feature request related to a problem?**
A clear description of the problem.
**Describe the solution you'd like**
What you want to happen.
**Describe alternatives you've considered**
Other solutions you've thought about.
**Additional context**
Any other relevant information.
π Code Review Process
- All PRs require at least one approval
- Maintainers will review your code
- Address any feedback
- Once approved, maintainers will merge
π¦ Releasing
Only maintainers can release new versions. The process:
- Update version in
lib/rails_accessibility_testing/version.rb - Update CHANGELOG.md
- Create git tag
- Build and push gem to RubyGems
β Questions?
- Open an issue for questions
- Check existing issues and discussions
- Email: imregan@umich.edu
π Thank You!
Your contributions make this project better for everyone. Thank you for taking the time to contribute!