Thanks for your interest in contributing. Here are some common scenarios for what you may want to contribute to.
#### Do you have questions about the project?
* Feel free to post your question on our [Discourse][discourse] or join our [Matrix Support Channel][matrix-support].
#### Did you find a bug?
* **Ensure the bug wasn't already reported** by searching on GitHub under [Issues][issues].
* If you're unable to find an open issue addressing the problem, [open a new one][new_issue]. Be sure to use one of the templates we provide if your request applies to them. If not, use the 'Question / Other' template.
#### Did you write a patch that fixes a bug?
* Open a new GitHub pull request with the patch.
* Ensure the PR description is precise about the problem and your solution. Just fill out our template. That should cover the most important information.
#### Do you intend to add a new feature or change an existing one?
* Suggest your idea in the [HedgeDoc Dev Channel][matrix-dev] and start writing code. Our maintainers and other project developers can provide useful details about the architecture and show you relevant issues and discussions.
#### Do you want to work on translations?
If you want to improve a translation or add a new translation altogether, we handle those via [POEditor][poeditor].
HedgeDoc is a volunteer effort. We encourage you to pitch in and to help us making this project even better.
- be as short as possible while clearly communicating their purpose.
- not include technical details, if not necessary.
- avoid abbreviations.
:+1: Good:
```typescript=
const addTwo = (x: number): number => x + 2
```
:-1: Bad:
```typescript=
const doStuffWithX = (x: number): number => x + 2
```
:-1: Bad:
```typescript=
const incrementXTwoTimesButNotRecursive = (x: number): number => x + 2
```
:-1: Bad:
```typescript=
const clcX = (x: number): number => x + 2
```
### Documentation of functions
To make the code as clear as possible to everyone, who will try to understand it, every function must have an [ESDoc](https://esdoc.org/).
Please make sure that your documenation can be read in a standard text editor (hard line breaks at ~120 characters, etc.).
The documentation must
- explain what the function does. If the explanation is longer than one line, then write a short introdoctory first line, followed by a break and then the longer explanation.
- contain every parameter with the `@param name explaination` annotation, that explains the purpose of the parameter.
- contain a `@return description` annotation if the return type isn't `void`, that explains the meaning of the value.
- contain `@throws ErrorClass description` annotations if the function throws runtime errors or doesn't catch errors from other method calls.
- contain a blank line between the description and the annotation block.
The described annotations must appear in this order: `@param`, `@return`, `@throws`
Example:
```typescript=
/**
* Calculates the divison of the given divisor and divident.
const divide = (divisor: number, divident: number): number => {
if (divident === 0) {
throw new Error("Can not divide by zero")
}
return divisor / divident
}
```
### Documentation of types and interfaces
Every exported type and interface must have an [ESDoc](https://esdoc.org/). No special annotations are needed.
### React components
React components
- must be functional. Use the `React.FC` type.
- can omit the `@return` annotation in the ESDoc if it returns always the same React DOM.
- should use the [`useCallback`](https://reactjs.org/docs/hooks-reference.html#usecallback) hook where possible. Don't use inline functions.
- should use [custom hooks](https://reactjs.org/docs/hooks-custom.html) to extract long functions to reduce the number of lines in the component file.
- must be placed in files that have the same name as the component, but in [kebab-case](https://stackoverflow.com/a/17820138). This file can also contain the interface for the properties.
- should be named in [PascalCase](https://en.wikipedia.org/wiki/Pascal_case).
- Don't log directly to the console. Use our logging class `Logger` in "src/utils".
- Create one instance of `Logger` per file. Don't pass or share the instances.
- The first argument of the constructor is the scope. Use the name of the class or component whose behaviour you want to log or choose an explanatory name.
- If you want to add a sub scope (because e.g. you have two components that are similar or are used together, like the sub-classes of the iframe communicator), separate the main and sub scope with " > ".
- Scopes should be upper camel case.
- Log messages should never start with a lowercase letter.
- Log messages should never end with a colon or white space.