Skip to content

Latest commit

 

History

History
64 lines (47 loc) · 5.99 KB

CONTRIBUTING.md

File metadata and controls

64 lines (47 loc) · 5.99 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 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 conformance 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 committing 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.

To ensure smooth collaboration, we recommend starting with issues labeled "Contributor OK." These issues have been recently categorized based on difficulty:

  • Good first issue: These are beginner-friendly tasks, generally involving simple bug fixes or UX improvements.
  • Intermediate: These issues involve small feature development, simple pattern implementations, or bug/UI adjustments that may require a deeper dive into the codebase.
  • Advanced: These tasks require a thorough understanding of the project, often involving complex implementations, significant refactoring or just bugs that requires a deep dive into the codebase.

Please prioritize tasks marked as "Contributor OK." If you wish to work on an issue that isn't marked as such, reach out to a team member first to confirm if the task is available for contributors. This approach ensures that we avoid potential conflicts and maintain an organized workflow.

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.