Facebook has adopted a Code of Conduct that we expect project participants to adhere to. Please read [the full text](https://code.fb.com/codeofconduct/) so that you can understand what actions will and will not be tolerated.

- Simply start using React Native. Go through the [Getting Started](http://facebook.github.io/react-native/docs/getting-started.html) guide. Does everything work as expected? If not, we're always looking for improvements. Let us know by [opening an issue](http://facebook.github.io/react-native/docs/contributing.html#reporting-new-issues).

- Look through the [open issues](https://github.com/facebook/react-native/issues). Provide workarounds, ask for clarification, or suggest labels. Help [triage issues](http://facebook.github.io/react-native/docs/contributing.html#triaging-issues-and-pull-requests).

- If you find an issue you would like to fix, [open a pull request](http://facebook.github.io/react-native/docs/contributing.html#your-first-pull-request). Issues tagged as [_Good first issue_](https://github.com/facebook/react-native/labels/Good%20first%20issue) are a good place to get started.

- Read through the [React Native docs](http://facebook.github.io/react-native/). If you find anything that is confusing or can be improved, you can make edits by clicking "Edit" at the top of most docs.

- Browse [Stack Overflow](https://stackoverflow.com/questions/tagged/react-native) and answer questions. This will help you get familiarized with common pitfalls or misunderstandings, which can be useful when contributing updates to the documentation.

- Take a look at the [features requested](https://react-native.canny.io/feature-requests) by others in the community and consider opening a pull request if you see something you want to work on.

- Before opening your pull request, make sure you have fully tested your changes. Test your changes locally and by running the various tests provided.

- For information on how to build the React Native project locally with your changes, make sure to read through the [Building React Native from source guide](https://facebook.github.io/react-native/docs/building-from-source.html).

- Check out the [Testing your changes guide](https://facebook.github.io/react-native/docs/testing.html) to find out about the numerous tests which has been provided to help ensure that any new changes wont cause a regression.

Core contributors to React Native meet monthly and post their meeting notes on the [React Native blog](https://facebook.github.io/react-native/blog). You can also find ad hoc discussions at [https://discuss.reactjs.org/](https://discuss.reactjs.org/).

- Ask for more information if the issue does not provide all the details required by the template.

- Suggest [labels](https://github.com/facebook/react-native/labels) that can help categorize issues.

- Flag issues that are stale or that should be closed.

- Ask for test plans and review code.

The [`facebook/react-native`](https://github.com/facebook/react-native) repository on GitHub contains a mirror of the React Native library used internally at Facebook. The GitHub repository is linked to Facebook's internal source control, and all changes made to the internal React Native project [get synced to the `master` branch on GitHub](https://github.com/facebook/react-native/commits/master) on an ongoing basis. Having Facebook's internal source control serve as the source of truth allows engineers at Facebook outside of the React Native team to move fast and contritube from an environment they are comfortable in.

React Native is also contributed to by a core team of engineers from several companies outside of Facebook, as well as many other open source [contributors](https://github.com/facebook/react-native/graphs/contributors). The core team coordinates open source releases through the [`react-native-releases`](https://github.com/react-native-community/react-native-releases) repository on GitHub.

- **One issue, one bug:** Please report a single bug per issue.

- **Provide a Snack:** The best way to get attention on your issue is to provide a reduced test case. You can use [Snack](https://snack.expo.io/) to demonstrate the issue.

- **Provide reproduction steps:** List all the steps necessary to reproduce the issue. Provide a Snack or upload a sample project to GitHub. The person reading your bug report should be able to follow these steps to reproduce your issue with minimal effort.

- **Try out the latest version:** Verify that the issue can be reproduced locally by updating your project to use [React Native from `master`](http://facebook.github.io/react-native/versions.html). The bug may have already been fixed!

1. Fork [the repository](https://github.com/facebook/react-native) and create your branch from `master`.

2. Add the copyright notice to the top of any new files you've added.

3. Describe your [**test plan**](contributing.html#test-plan) in your pull request description. Make sure to [test your changes](testing.html)!

4. Make sure your code lints (`npm run lint`).

5. If you haven't already, [sign the CLA](https://code.facebook.com/cla).

- If you've added code that should be tested, add tests!

- If you've changed APIs, update the documentation via an additional PR to the [react-native-website](https://github.com/facebook/react-native-website) repo.

- If you've updated the docs, verify the website locally and submit screenshots if applicable (see the [react-native-website](https://github.com/facebook/react-native-website) README).

- **Most important: Look around.** Match the style you see used in the rest of the project. This includes formatting, naming things in code, naming things in documentation.

- Add trailing commas,

- 2 spaces for indentation (no tabs)

- "Attractive"

- Use semicolons;

- ES6 standards

- Prefer `'` over `"`

- Do not use the optional parameters of `setTimeout` and `setInterval`

- 80 character line length

- Prefer `"` over `'` for string literal props

- When wrapping opening tags over multiple lines, place one prop per line

- `{}` of props should hug their values (no spaces)

- Place the closing `>` of opening tags on the same line as the last prop

- Place the closing `/>` of self-closing tags on their own line and left-align them with the opening `<`

- Space after `@property` declarations

- Brackets on _every_ `if`, on the _same_ line

- `- method`, `@interface`, and `@implementation` brackets on the following line

- _Try_ to keep it around 80 characters line length (sometimes it's just not possible...)

- `*` operator goes with the variable name (e.g. `NSObject *variableName;`)

- If a method call spans multiple lines closing bracket is on the same line as the last argument.

- If a method header doesn't fit on one line each argument goes on a separate line.

- 100 character line length

- Do not wrap lines at 80 characters - configure your editor to soft-wrap when editing documentation.