# Adding types

## Decision
Use these guidelines when writing docs for components:

### General
* Use British English for docs, US English for code.

### Titles
* Use sentence case.
* Keep titles to the singular form.

_e.g. 'Bar chart’ over ‘Bar Charts’._

### Intros
* Use plain English.
* Describe the component and its broad purpose - do not go into detail.
* Keep descriptions to no more than 100 words.
* Do not talk about the configurations.
* Keep the descriptions platform agnostic unless the component is strictly for
one platform and will never apply to others _e.g. Touchable Native Feedback is
strictly for Android._
* Should you need to reference the component name mid sentence, use lowercase.

## Thinking
We want to ensure components are documented consistently and consumers have the
right amount of information.

# Writing docs

## Decision
Use these guidelines when writing docs for components:

### General
* Use British English for docs, US English for code.

### Titles
* Use sentence case.
* Keep titles to the singular form.

_e.g. 'Bar chart’ over ‘Bar Charts’._

### Intros
* Use plain English.
* Describe the component and its broad purpose - do not go into detail.
* Keep descriptions to no more than 100 words.
* Do not talk about the configurations.
* Keep the descriptions platform agnostic unless the component is strictly for
one platform and will never apply to others _e.g. Touchable Native Feedback is
strictly for Android._
* Should you need to reference the component name mid sentence, use lowercase.

## Thinking
We want to ensure components are documented consistently and consumers have the
right amount of information.

Fix title in writing docs decision
[skip ci] Fix title in writing docs decision