Skip to content

Latest commit

 

History

History
53 lines (40 loc) · 4.61 KB

CONTRIBUTING.md

File metadata and controls

53 lines (40 loc) · 4.61 KB
Raw

Contribution guidelines

We encourage you to participate in this open source project. We love Pull Requests, Issue Reports, Feature Requests or any kind of positive contribution. Please read the the following guidelines and our Firefox for iOS contributing guidelines first.

Submitting an Issue

If you find a bug in the source code or a mistake in the documentation, you can help us by submitting an issue to our repository. Before you submit your issue, search open and closed issues, as it's possible that your question was already answered, or a ticket for the issue already exists.

Coding Rules

Swift style

  • iOS engineers at Mozilla are still in the process of defining Mozilla's Swift guidelines. Currently, we're working through Swiftlint rules that members on the team agree should be enabled. Then we will pursue further rules we'd like to implement.
  • In general, as of 2023, Swift code should follow the conventions listed at Swift style guide, with the understanding that this is a loose standard.
    • Exception: we use 4-space indentation instead of 2.
  • We use Swiftlint rules in both local and CI builds to ensure comformance to accepted rules. You can run Swiftlint locally by installing it locally with Homebrew. Swiftlint will then be run through Xcode Build Phases on the Client target.

Pull Requests

  • All pull requests must be associated with a specific Issue. If an issue doesn't exist, please first create it.
  • Before you submit your pull request, search the repository for an open or closed Pull Request that relates to your submission. We don't want to duplicate effort.
  • PR's should be made from a branch on your personal fork to the mozilla-mobile:main branch. Please see the PR Naming Guidelines for how to name PRs.
  • For commiting in your Pull Request, You can checkout Commits for more info.

Commits

  • All of a PR's commits will be squashed to keep a clean git history in main. This means that technically, individual commit names are not particularly relevant. However, for an easier review process, we should keep the following rules of thumb in mind:
    • Each commit should have a single clear purpose. If a commit contains multiple unrelated changes, those changes should be split into separate commits.
    • If a commit requires another commit to build properly, those commits should be squashed.

Commenting Etiquette

  • Please remember that all comments should adhere to the Mozilla Community Guidelines
  • If a comment does not apply to the code review on the PR, please post it on the related issue.

Building the code

  • Fork and clone the project from the repository.
  • Use the provided build instructions in the Readme of the repository to build the project.

Run on a Device with a Free Developer Account

Only follow these instructions if you are using the free personal developer accounts. Simply add your Apple ID as an account in Xcode.

Since the bundle identifier we use for Firefox is tied to our developer account, you'll need to generate your own identifier and update the existing configuration.

  1. Open Client/Configuration/Fennec.xcconfig
  2. Change MOZ_BUNDLE_ID to your own bundle identifier. Just think of something unique: e.g., com.your_github_id.Fennec
  3. Open the project editor in Xcode.
  4. For the 'Client' target, in the 'Capabilities' section, turn off the capabilities 'Push Notifications' and 'Wallet'.
  5. For each target, in the 'General' section, under 'Signing', select your personal development account.

If you submit a patch, be sure to exclude these files because they are only relevant for your personal build.

Looking for issues

Want to contribute on the codebase but don't know where to start? Here is a list of issues that are contributor friendly.

Reaching out for help and questions

If more information is required or contributors have any questions then we suggestion reaching out to us via: