You can take a look at the community tools we use to communicate issues, features, etc.

• Read the documentation
• Join Licode developers mailing list
• Clone or fork the repository
• Take a look at open reviews and issues

We like the way other Open Source projects like Openstack define their Contributor Guides, so this one is mostly based on them.

There are different areas where a developer could contribute in Licode: bug fixing, maintain code quality, feature development and improving documentation.

The first area where you can help is bug fixing:

• Confirmed bugs: they are usually good targets. You can contribute ideas and tips on how to fix them, and set them to Triaged.
• Triaged bugs: they contain instructions and tips on how to fix a given bug. You can contribute to fix them: assign the bug to yourself, set it to In progress, branch the code, implement the fix, and propose your change for merging into trunk!
• Easy-to-fix bugs: These are Triaged bugs marked with the look-hanging-fruit tag, i.e should not take too much time to be fixed. They also make good targets for a beginner.

Maintaining good code quality is a never-ending effort that is shared across the development team. There are several always-ongoing efforts that need your help, for example: increasing code coverage, applying current code style guides. Those are usually nice ways to get involved in development: easy changes that will let you touch various areas of Licode code.

We adopt Airbnb style guide for all the Javascript based components (Nuve API, Nuve Client, Erizo Client, Erizo Controller, Erizo Agent and ErizoJS).

For Erizo and Erizo API we apply C++ Google style guide.

Once you get comfortable with the code, you can start to contribute new features. New features design should be proposed separately to discuss them in public. We could set virtual meetings to discuss the more relevant aspects of each feature.

This is the doc template (markdown) you should submit via Pull Request to the repository:

# [Feature Name] - Feature Review
You should add a general description of the feature in one short paragraph.


## Architecture
Here you should add a deep explanation about the proposed architecture.
If it involves changes in many components you can show the architecture following a top-down approach.

Figures are welcome to help others understand the solution.

## API Changes
If it involves changes in the client/server APIs this is a good section to show detailed info about them.

## Details
These subsections should give a detailed analysis of how this feature should be implemented in each
component (pseudo code is welcome).

### How does it affect Erizo Client?
Special comments of how the new feature affects the clients. You can give examples of use too.

### How does it affect Nuve?
Special comments of how the new feature affects Nuve.

### How does it affect Erizo Controller / Erizo Agent / Erizo JS?
Special comments of how the new feature affects Erizo Controller and sub-components.

### How does it affect ErizoAPI / Erizo?
Special comments of how the new feature affects the Erizo.

## Additional considerations
Comments related to other stuff (documentation, tests, CI, etc.)

The last step, once the design is accepted, code should be proposed via Pull Requests.

Documentation is one of the most important elements in an Open Source project. A good source code loses its value if developers cannot understand how it works! So we encourage you to also contribute here by fixing typos and improving the quality of our documents.

But it is also crucial to keep the documentation up to date with every code update. So when when you contribute a pull request that changes the APIs it is mandatory to also update the corresponding documentation.

To make these things easier, our APIs documents are written using Markdown, a very light markup lenguage that uses plain text combined with some tags to add format and style. In Licode's documentation folder (licode/doc/) you will find the two main markdown files you would have to modify to introduce changes in the APIs, client_api.md and server_api.md for client and server APIs respectively.

To preview these documents while you are editing them you can use any markdown editor. However, if you want to see them as they are rendered in our website you have to serve them using Mkdocs. There you will find installation and usage instructions. Please, take into account you have to install version 15.0 in order for it to be compatible with Licode custom theme.

We have configured a Licode account in ReadTheDocs to automatically compile every change in Licode master branch. And this page is linked in Licode website. So when your PR is accepted, your API changes are automatically published in Licode documentation page. Cool, right?

Every patch submitted to Licode gets reviewed before it can be approved and merged.

We get a lot of contributions and everyone can - and is encouraged to! - review existing patches.

Pick an open review and look at it, test it if possible, and leave a comment with approval or rejection. If you're planning on submitting patches of your own, it's a great way to learn about what the community cares about and to learn about the code base.

If you're hoping to contribute in another way, let us know! Contact one of the Licode people and float your idea.