# Guidelines for Collaboration

## Visibility Into Work and Productivity
* **Daily Standup** The `standup` channel on the Vac discord server is where core contributors share their daily stand up summarizing their daily planned tasks.
* **Weekly Standup**: In addition to the daily standups, weekly standups should be written every week before the vac PM calls in the following doc https://notes.status.im/vac-pm. A weekly standup is the summary of the past week's progress and the planned tasks for the coming week. Blockers should be indicated under the blocker section. Please make sure to share your blockers in the Vac PM calls and get help from your team members.
* **Track your work with Github issues**: Make sure to always have an open Github issue corresponding to your current task. Follow the following post for some [insights on how to write good Github issues](https://wiredcraft.com/blog/how-we-write-our-github-issues/).
* **Quality Github pull requests**: Github issues are (typically) followed by one or multiple Github pull requests (PR) to address the task(s) set out in the issue. PRs should be of *reasonable size* and with *proper documentation*. All commits within the PR [should be signed](https://docs.github.com/en/authentication/managing-commit-signature-verification/signing-commits). Do not forget to [request PR review](https://docs.github.com/en/pull-requests/collaborating-with-pull-requests/proposing-changes-to-your-work-with-pull-requests/requesting-a-pull-request-review) from your peers when your PR is ready. Before merging an open PR, all commits should be rebased on master and squashed into a single commit with a [semantic commit message](https://www.conventionalcommits.org/en/v1.0.0/). Use the following guides on how to make a good PR
* [Anatomy of a perfect pull request](https://opensource.com/article/18/6/anatomy-perfect-pull-request)
* [How to write a perfect pull request](https://github.blog/2015-01-21-how-to-write-the-perfect-pull-request/). This post expands on good PR documentation and communication.
* **PR Reviews:** Spend a portion (10-20%) of your daily work reviewing other team members' Pull requests. This will allow a swift and smooth development process.
* **Seek feedback** Do not hesitate to seek feedback from the senior members of the team, especially those who work closely with you.
* **Communicate effectively:** Know the team members that are relevant to your project and get their feedback and comments on your project when need be.
## Communication media
- **Basic principle:** Vac builds open-source protocols and software. We are part of a wider community. As such, your first instinct should be to communicate _as openly as possible_ in the forum/channel most suited to your query. That said, we have channels for team-internal communications that relate to project management, team travel or other more personal conversations.
- **Discord server:** it takes a while to get used to the bewildering number of channels on the Vac Discord server. Here are some guidelines to help you get started:
- `#introductions`: a good place to introduce yourself to the community once you've joined
- `#gm`: a quick "good morning" when you start your day adds to a friendly environment and shows other community members that you're online
- `#standup`: daily one-liners indicating what your focus will be for the day
- `#waku`: general discussions related to the Waku suite of protocols
- `#nwaku`, `#go-waku`, `#js-waku`: discussions related to the nim, go and JavaScript Waku v2 clients respectively
- `#vac-pm`(pvt): team-internal discussions related to the Vac organisation.
- `#waku-pm`: team-internal discussions related to Waku Product project management.
- **Examples:**
- _You're getting started and have a question related to the nwaku codebase:_ ask away in the open `#nwaku` channel. Feel free to tag specific people that you think may help, but don't be too surprised if other community members jump in with an answer.
- _While reading a Waku RFC you have a suggestion on how to improve the protocol:_ ping the team on the open `#waku` channel. You could also create a GH issue in the [vacp2p/rfc](https://github.com/vacp2p/rfc) repository.
- _You want to inform the team that you're off sick:_ use the team-internal `#vac-pm` channel.
## Autonomy and Motivation
- **Alignment with principles**: Vac follows a set of principles as described in https://status.im/about/, a good understanding of those is vital to making a meaningful contribution to the team. Should you have any questions regarding the principles, do not hesitate to reach out to your team members for more insights and explanations.
* **Familiarize yourself with relevant tools and tech** Your work involves knowledge of the basics of Git and [Github](https://docs.github.com/) e.g., creating issues, pull requests (PRs), branches, merging, rebasing, etc. Spend some time and familiarize yourself with these concepts.