# General/Collaboration

## Collaboration

### Definition of Done

We suggest you use a Definition of Done for your project. This gives everyone in the team an understanding when a task is *really* done.

You can find the CorrelAid Definition of Done here: 

{% embed url="<https://github.com/CorrelAid/definition-of-done>" %}

## General best practices

Those general best practices should help you with implementing the items of the Definition of Done.

### **How to document code**

Documenting your code should always be less about the "what" and more about the "why". However, if you are writing code which might be a bit more advanced/complex, adding some comments about *how* it works is also useful, especially for the less experienced team members.

### **Peer review**

Peer reviewing someone else's code involves three things:

1. test the code on your machine
2. provide feedback (possibly suggesting changes)

Whenever the skills of the team allow for it, you should use [branches](https://docs.github.com/en/pull-requests/collaborating-with-pull-requests/proposing-changes-to-your-work-with-pull-requests/about-branches) and [pull requests](https://docs.github.com/en/pull-requests/collaborating-with-pull-requests/proposing-changes-to-your-work-with-pull-requests/about-pull-requests) for this. [Pull request reviews](https://docs.github.com/en/pull-requests/collaborating-with-pull-requests/reviewing-changes-in-pull-requests/about-pull-request-reviews) are a great way to directly suggest changes.

If a team member is still quite new to Git, a file-driven "review process" (e.g. `data_cleaning_jack.R`) is also acceptable as to not overwhelm them with Git. You can leave comments in the file and commit it back to Git or discuss your feedback in a GitHub issue. Always be kind to team members with less experience.