Skip to content

Latest commit

 

History

History
183 lines (119 loc) · 9 KB

contributing.md

File metadata and controls

183 lines (119 loc) · 9 KB
Raw

Contributing to React Native Boilerplate

👍🎉 First off, thanks for taking the time to contribute! 🎉👍

We would love for you to contribute to React Native ThemBoilerplatee and help make it even better. As a contributor, here are some guidelines which will help you to understand the project:

About Project

This project is a React Native boilerplate that provides an architecture optimized for building solid cross-platform mobile applications through separation of concerns between the UI and business logic to help you kickstart your new app

Project Management

We use Github issues to track all the features and bug. We follow this project management strategy.

  1. Each new feature or bug, first get listed in Github issues.
  2. The issue card is imported into Github Project board.
  3. By default, card is imported into To do column of the project board.
  4. If a feature/bug is being worked on, the card is moved into In progress column, and a corresponding feature/awesome-feature-title or hotfix/terrible-bug-title branch is created.
  5. Once completed
    • The branch is merged into master branch
    • Card is moved into Done column of the project board
    • Issue is finally closed.

Branch Organization

We follow Git branch strategy. The master branch is the default and base branch for the project. It is used for development and all Pull Requests should go there. Follow this naming convention for your branches.

How Can I Contribute?

Reporting Bugs

  • Ensure the bug was not already reported by searching all issues.
  • If you're unable to find an open issue addressing the problem, open a new one. When you are creating a bug report, please include as many details as possible. Fill out the required template, the information it asks for helps us resolve issues faster.

You can help the team even more and submit a Pull Request with a fix.

Suggesting Enhancements

Feature suggestions are tracked as GitHub issues. Feature requests are welcome. But first, already open issues marked as Type: enhancement will take priority. So take a moment to find out whether your idea fits with the scope and aims of the project. Please provide as much detail and context as possible.

Your First Code Contribution

To help you get your feet wet and get you familiar with our contribution process, we have a list of good first issues that contain small functionality/bug that have a relatively limited scope. This is a great place to get started.

If you are familiar with the codebase, checkout Help wanted issues

If you decide to fix an issue, please be sure to check the comment thread in case somebody is already working on a fix. If nobody is working on it at the moment, please leave a comment stating that you intend to work on it so other people don’t accidentally duplicate your effort.

Pull Requests

If you never created a pull request before, welcome 🎉 😄 Here is a great tutorial on how to send one :)

Good pull requests - patches, improvements, new features - are a fantastic help. They should remain focused in scope and avoid containing unrelated commits.

Please ask first before embarking on any significant pull request (e.g. implementing features, refactoring code), otherwise you risk spending a lot of time working on something that the project's developers might not want to merge into the project.

  1. Search GitHub for an open or closed PR that relates to your submission. You don't want to duplicate effort.

  2. Fork the project, clone your fork, and configure the remotes:

    # Clone your fork of the repo into the current directory
git clone https://github.com/<your-username>/<repo-name>
# Navigate to the newly cloned directory
cd <repo-name>
# Assign the original repo to a remote called "upstream"
git remote add upstream https://github.com/alexakasanjeev/react-native-boilerplate.git

  3. If you cloned a while ago, get the latest changes from upstream:

    git checkout master
git pull upstream master

  4. Create a new topic branch (off the main project development branch) to contain your feature, change, or fix: follow this naming convention for branch

    git checkout -b <topic-branch-name>

  5. Commit your changes using a descriptive commit message that follows our commit message conventions.

  6. Push your branch to GitHub:

    git push origin <topic-branch-name>

  7. Open a Pull Request using your branch and fill the required template.

IMPORTANT: By submitting a patch, you agree to license your work under the same license as that used by the project.

Styleguides

To ensure consistency throughout the source code, keep these rules in mind as you are working:

Git Branch Naming

If you are working on an enhancement(feature) issue, start you branch name like this feature/short-descriptive-title.

If you are working on a bug fix issue, start your branch name like this hotfix/issue-title

Example

Suppose you are working on add to cart feature, name your branch

feature/add-to-cart

Suppose you are working on issue Navigation drawer render multiple times, name your branch

hotfix/navigation-multiple-render

Commit Message Convention

A commit message consists of a header, body and footer. The header has a type and subject:

<type>: <subject>
<BLANK LINE>
<body>
<BLANK LINE>
<footer>(optional)

Example

Suppose your commit adds a feature, which is listed under Github issue #7

feat: added add to cart functionality in ProductDetailPage

description: in ProductDetailPage, added a button, which on click add the product to the cart.

close #7

Commit messages can have the following types:

  • build: Changes that affect the build system or external dependencies
  • chore: Changes to readme, etc
  • ci: Changes to our CI configuration files and scripts
  • docs: Documentation only changes
  • feat: A new feature
  • fix: A bug fix
  • perf: A code change that improves performance
  • refactor: A code change that neither fixes a bug nor adds a feature
  • style: Changes that do not affect the meaning of the code (white-space, formatting, etc)
  • test: Adding missing tests or correcting existing tests

Footer: The footer should contain any information about Breaking Changes and is also the place to reference GitHub issues that this commit Closes.

JavaScript Styleguide

All JavaScript must adhere to Airbnb's JS Style Guide and Airbnb's React Style Guide.

Community

If you have any questions or if you would like to get involved or just want say Hi!, you can check out: