We want to make contributing to this project as approachable and transparent as possible. ARIA-AT App is maintained by Bocoup and designed and developed with the W3C ARIA-AT Community Group.
This project is governed by the Bocoup and W3C Codes of Conduct.
We use GitHub to host code, track issues and feature requests, and accept pull requests.
We use GitHub issues to track bugs, feature requests, and implementation proposals. Report a bug by opening a new issue.
If your issue relates to a specific ARIA-AT test plan or the behavior of the ARIA-AT test renderer, please open an issue in the aria-at repository.
Pull requests are the best way to propose changes to the codebase. We use GitHub Flow, and Conventional Commits as development methodologies.
If the pull request is not a bug fix, an implementation proposal should first be submitted via a new issue, in order to reach consensus with the maintainers on scope, technical approach, and design implications.
Implementation proposals and pull requests that affect the overall design or user experience of the app may require a design review before implementation.
Pull requests should be small and granular, ideally addressing one issue or feature at a time. Try to keep each pull request independently mergeable. Multiple dependent PRs should only be used when absolutely necessary to land a longer-term change.
In order to open a pull request:
- Fork the repository and create your branch from
development. - If you've added code that should be tested, add tests. See below for some additional guidance on testing.
- If you've changed APIs, update the documentation.
- Ensure the test suite passes.
- If the pull request is not a bug fix, please link to the related implementation proposal and consensus issue.
- Submit a pull request!
Maintainers with write access to the repository will create branches directly within the repository.
All pull requests, including pull requests opened by maintainers, require code review from two maintainers before merging.
The second maintainer who reviews is responsible for merging the pull request into the protected development branch.
Maintainers will periodically deploy the main and development branches to the live environments.
Additional details on facilitating the release process can be found in docs/release.md
We expect PRs for all features to include enough tests to give confidence that new features are working and will continue to work.
100% test coverage is not the expectation. We do not expect contributors to comprehensively test every esoteric failure state. We do expect the happy path and common failure states to be tested.
We provide capabilities for unit testing, integration testing and end-to-end testing. Unit or integration testing every component is not the expectation, since trivial components will be covered by end-to-end tests (for example, the router). On the other hand, non-trivial components should be integration tested (For example, a modal or other application flow control components).
We expect contributors to use the type of testing which corresponds to the architecture of their code. For example, in the case of a utility function, unit tests are preferable to end-to-end testing, because of the complexity of end-to-end which runs a full browser, server and database. On the flipside, attempting to unit test a major set of features like the overall function of the data management page would require so many mocks that end-to-end testing would be the only efficient option.
The project maintainers keep a record of the technical problems which cause unforeseen interruptions to the service provided by the application in production. These incident reports document the aberrant behavior, the investigation process, and the technical resolution. They are available in the project wiki.
When you submit code changes, your submissions are understood to be under the same W3C Document License that covers the project.