Skip to content

Latest commit

 

History

History
62 lines (46 loc) · 6.29 KB

CONTRIBUTING.md

File metadata and controls

62 lines (46 loc) · 6.29 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 firefox-ios/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.

Note that we try to mark "Contributor OK" tasks on work that can be easily picked up by contributors as much as we can. Please try to only pick "Contributor OK" tasks, or if you want to pick a task that isn't marked as such make sure to ask one of the team members if the work is available to be taken or not. There's multiple reasons behind this:

  • Sometimes the technical work is bigger than what it seems at first hand. We're often not looking for a quick band-aid fix, but rather a long term solution that requires tying into the other refactor project that we currently have ongoing, and without proper conversation with the rest of the team it would rather be difficult as a contributor to be aware of those. If you want to enable such work, it's always possible to discuss with the teammates on Element. But going forward without proper discussion means you risk your PR of being declined as it won't align with the direction we're working in.
  • Sometimes it's also possible someone is already working on it in our team, since the status of "in progress" isn't reflected in GitHub from Jira.

Hence, if you want to work on a "non contributor OK" task, it's entirely possible but please just ask on it if it's available to be worked on.

Contributor fix

We add the "Contributor Fix" label on tasks that have a PR opened for it, or if a PR has been merged to fix this task. This means if you see this label on a task it's probably fixed and cannot be picked up. Note that tasks still stay opened before we close them as it's the Quality Assurance people that will close those tasks with their final approval of the work.

Reaching out for help and questions

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

  • Chat: See Element channel #fx-ios for general discussion. You can also write DMs to specific teammates on it.
  • Open a Github discussion.