Skip to content

CONTRIBUTING.md

Latest commit

 

History

History
85 lines (62 loc) · 2.82 KB

CONTRIBUTING.md

File metadata and controls

85 lines (62 loc) · 2.82 KB

Contributing to FueledUtils

Setup

In order to properly clone the project and be ready to submit bug fixes/new features, please follow these steps:

  1. Clone the project:

    git clone https://github.com/Fueled/ios-utilities.git
cd ios-utilities

  2. Open the project in Xcode:

    open Package.swift

    Or open it directly in Xcode by double-clicking Package.swift.

  3. Build the project to ensure everything is set up correctly:

    swift build

  4. Run tests:

    swift test

  5. You're ready to go!

How to contribute

You can contribute by:

  1. Reporting bugs
  2. Enhance the existing features
  3. Introduce new features

Fueled team will generally accept bugs fixes, and discuss the benefits of integrating new features and enhancements within the codebase.

Guidelines

  1. All code must conform to Fueled Swift style guide. This conformance is largely ensured by our swiftlint configuration.
  2. Additionally, all public and open constructs must be documented unless their meaning is determined clearly and unambiguousy by types and naming.

Commit style

We're using semantic commit messages at all times when writing commit messages. Our semantic commit message format involves 4 distinct parts (1 is optional)

  1. A type
  2. A scope
  3. A short description
  4. A long description

The general format is:

<type>(<scope>): <short description>

<long description>

The type may be one of:

  • feat: a new feature
  • fix: a bug fix
  • perf: performance enhancement
  • docs: documentation update
  • refactor: code refactoring
  • test: add/change/remove unit tests
  • style: style change (update indentation, change spaces to tabs, …)
  • chore: configuration update, code signing change, …

The scope must reference what part of the library was changed, and can be made specific using slashes, for example combine/publisher-extensions or core/string-extensions. The scope can also reference one or multiple GitHub issues.
The short description must describe in as few words as possible what the commit does. It must be written in imperative tense and can reference a GitHub issue.
The long description may go further into explaining why some changes were necessary (e.g. if a feature is done through a refactoring).

For example, you may do something like:

git commit \
    -m "fix(combine/publisher-extensions/#123): fix issue in Publisher extension" \
    -m "This fixes a bug where the publisher would sometimes fail to emit values correctly."

You can find more info on our commit format and its purpose in this Medium article.