Internal employees can reach out to the team on slack to get github permissions to contribute to bacom. External community members who want to contribute can fork the repo.
Once you've pulled down the repo, follow the local setup instructions included in the README.
We strongly recommend reaching out to the milo community for feedback on your prospective authoring experience (AX) before beginning development. This will help avoid AX issues being flagged in code review which could necessitate a lengthy rewrite. You can post your AX ideas in slack to receive feedback. Screenshots are always appreciated.
When your code is ready, please make sure all of these items are accounted for prior to creating a PR:
- Unit Tests are included for any new features and existing tests pass. We aim for 100% code coverage.
- Linters pass.
- Performance has been considered. We aim for an upper-90s lighthouse score.
- Pre-QA testing has been completed:
- Should meet accessibility standards for: keyboard navigation, screen reader, and zoom to 200%.
- Functionality should work on major browsers for desktop, tablet and mobile devices.
- Layout should match designs on major browsers for desktop, tablet, and mobile breakpoints.
- See wiki for full guidance.
Push your branch up to the remote and create a PR into main
. Please follow the PR template.
Your PR should have all of the following:
- Description.
- Ticket or issue number linked.
- Test URLs.
- Reviewers. Please add the bacom owners as reviewers. You can also add the milo core team.
- Labels. Please add labels if appropriate. If your code doesn't affect the frontend of the site (e.g. updating lint rules), it should be marked "trivial".
- Assignee. If a PR isn't trivial, it needs to be tested by the bacom QE. Please add them as the assignee. (Note: This is different from the milo process. For bacom, developers shouldn't be performing verification.)
The reviewers you added on your PR should provide feedback in a timely manner. You can also tag them on slack for additional visibility.
Reviewers will evaluate the PR based on all of the items previously listed (i.e. AX, unit tests, code quality, performance, accessibility) as well as best practices.
Once the code has been approved, please notify the assignee that they can begin verification testing.
If the code won't affect the production site, it should have the "trivial" label and can skip verification.
A PR can be merged once all of these items are complete:
- PR has at least one approver.
- Comments are resolved.
- Unit tests pass.
- Lighthouse test passes (or a valid justification has been provided about why it doesn't pass).
- Code has been tested by QE (if applicable) and PR has either "verified" or "trivial" labels.
Please notify a bacom owner when the PR is ready to be merged.