Please at the start of each new task, ping in the Maxi Chatty chat group so everyone knows what you are working on. Also please give Kyra or Svits/Josh a daily update on your current progress. This will ensure we are all working on the correct issues and we are all rowing in the same boat.

1. Fix the assigned issues by priority.
2. Tag the bugs you're adding to GitHub.
3. Review PRs first thing in the morning.
4. Comment and share information about the tasks' status on GitHub or the chat.
5. Ensure clean code and healthy tests.
6. Follow the requested actions on the chat.
7. Keep an understandable environment using the proper tags and projects.

1. Ensure the bug is in themasterand not other branches.
2. Ensure there's no duplicate issue, or related issue.
3. Set a concrete and short title easy to understand.
4. Write clear descriptions; complement it with video if necessary. Make sure others can understand and replicate the issue.
5. If necessary, share the steps of how to reproduce it.
6. Link to other issues/PRs if it has any relation.
7. Tag and assign the issue; if not sure about the correct tag, or to whom to assign it, comment it in the chat.
8. Add code editor if it can help in identifying the bug.
9. Add a brief of how to fix it in case we've got any idea.
10. Make sure you have NO stuck PR's. Always fix current PR's before starting new ones. No PR wants to be left alone in unapproved-ville.

1. Before starting fixing an issue, it is important to ensure no other actions are required prior to fixing; for example, some changes requested in a PR pushed before already.
2. Find an assigned issue and sort it by priority. The priority can be set by the tag or by the order into the respective project.
3. Create a branch from master with the name issue-#${number of the issue}
4. Fix the issue. If you start struggling with the issue, draft the PR, and expose the issues/blocks found. That way, the rest of devs can help out with it; make sure to tag with the "Need Code Help - Code Hinting" tag.
5. Please, use a great description on the commits. Few and good documented commits help a lot when we need to debug or understand the reason why some code is there, especially when the implementation was done a long ago.
6. When the issue is fixed, create a PR or make it reviewable if it was a draft.

1. Ensure the branch is updated with master.
2. Add a corresponding title following this structure: Issue ${number of the issue} - ${short title about the PR}
3. Description must start with: fixes. Example Fixes ${number of one issue} and fixes ${number of other issue}. This way, GitHub will automatically link the PR to the issue/s, and will automatically change the state of the issue (ie close it).
4. Description must contain all the actions taken. It is easy to do it if the commits were organised and were done in order.
5. Write steps we must follow to test, and the changes we should find in the backend/frontend.
6. If necessary, instruct on any additional actions needed to be taken (for example to reset DB or SC), or future issues that could be caused from the current implementation.
7. If you figure out that the implementation will need new e2e tests or to modify any, add it into the description and tag Alejandro to have it in mind.
8. Add reviewers and assign it. Also add the necessary tags.

The review of PRs is done in 4 phases relative to its state, and represented in the corresponding tags:

1. Back/front testing: first round of testing where front and back/editor are tested. No code is tested.
2. Pre-code Testing: first round of code testing before an intensive review. Please read the code carefully to see if you can spot any possible bugs/problems.
3. Final code testing: the last and detailed review of the code done by Svitlana or Josh.
4. Test review (optional): when tests haven't been updated yet, and PR needs one last look before updating.

Some notes about reviewing a PR:

1. No need to reduce or to save time reviewing the PR, fast and good are not normally synonyms; be detailed and spend as much time as necessary. Every bug we prevent on merging into master means lots of time after. Preventing bugs is even more productive than fixing them 👍
2. Read and understand the issue the PR is aiming to fix and the comments of the issue/PR. Understanding the context will help to know what to test and what we should be expecting from the fix.
3. Hummer style: test deep, break and look for every combination of situations.
4. Once finished, ensure the correct tag related to the PR state is set.