Contributing to Application Services

Anyone is welcome to help with the Application Services project. Feel free to get in touch with other community members on Matrix or through issues on GitHub.

Participation in this project is governed by the Mozilla Community Participation Guidelines.

Bug Reports

You can file issues on GitHub. Please try to include as much information as you can and under what conditions you saw the issue.

Building the project

Build instructions are available in the building page. Please let us know if you encounter any pain-points setting up your environment.

Finding issues

Below are a few different queries you can use to find appropriate issues to work on. Feel free to reach out if you need any additional clarification before picking up an issue.

good first issues - If you are a new contributor, search for issues labeled good-first-issue
good second issues - Once you've got that first PR approved and you are looking for something a little more challenging, we are keeping a list of next-level issues. Search for the good-second-issue label.
papercuts - A collection of smaller sized issues that may be a bit more advanced than a first or second issue.
important, but not urgent - For more advanced contributors, we have a collection of issues that we consider important and would like to resolve sooner, but work isn't currently prioritized by the core team.

Sending Pull Requests

Patches should be submitted as pull requests (PRs).

When submitting PRs, We expect external contributors to push patches to a fork of application-services. For more information about submitting PRs from forks, read GitHub's guide.

Before submitting a PR:

Your patch should include new tests that cover your changes, or be accompanied by explanation for why it doesn't need any. It is your and your reviewer's responsibility to ensure your patch includes adequate tests.
- Consult the testing guide for some tips on writing effective tests.
Your code should pass all the automated tests before you submit your PR for review.
- Before pushing your changes, run ./automation/tests.py changes. The script will calculate which components were changed and run test suites, linters and formatters against those components. Because the script runs a limited set of tests, the script should execute in a fairly reasonable amount of time.
  - If you have modified any Swift code, also run swiftformat --swiftversion 5 on the modified code.
Your patch should include a changelog entry in CHANGELOG.md or an explanation of why it does not need one. Any breaking changes to Swift or Kotlin binding APIs should be noted explicitly.
If your patch adds new dependencies, they must follow our dependency management guidelines. Please include a summary of the due diligence applied in selecting new dependencies.
After you open a PR, our Continuous Integration system will run a full test suite. It's possible that this step will result in errors not caught with the script so make sure to check the results.
"Work in progress" pull requests are welcome, but should be clearly labeled as such and should not be merged until all tests pass and the code has been reviewed.
- You can label pull requests as "Work in progress" by using the Github PR UI to indicate this PR is a draft (learn more about draft PRs).

When submitting a PR:

You agree to license your code under the project's open source license (MPL 2.0).
Base your branch off the current main branch.
Add both your code and new tests if relevant.
Please do not include merge commits in pull requests; include only commits with the new relevant code.
We encourage you to GPG sign your commits.

Code Review