Communication and teamwork#

Good technical work is not enough — what also counts is how we work together.

Working in Git#

• Every change goes through a Pull Request — main is protected.
• Small, frequent PRs > one giant one. They are easier to review.
• The PR description says what and why, not just "fix".

git checkout -b feat/krotki-opis
# ...changes + commit (Conventional Commits: feat:, fix:, docs:)
git push -u origin feat/krotki-opis
gh pr create --fill

Code review#

• A review is a learning experience for both sides — not criticism of the person.
• Comment on the code, not the person ("this function could...", not "you did it wrong").
• As the author: respond to comments, don't ignore them.

The ProfessNet standard: a "no blame" culture. A bug in the code caught in review is a success of the process, not a failure of the author.

Communication channels#

• Teams — day-to-day communication, team channels.
• GitHub — everything code-related (issues, PRs, technical discussions).
• Meetings — short and to the point; if it can be done by email/chat, even better.

Ask questions#

• First try on your own (the documentation, this platform, a search engine).
• Stuck for more than 30 min? Ask. The team's time is valuable, but so is yours.
• A question + what you've already tried = the best way to get fast help.

Asynchronously and respectfully#

We work in different hours and locations. Write so that it can be answered later. Respect other people's time — and your own.

---

Congratulations — you've completed onboarding! Test your knowledge in the quiz below, and then head off to the ZEUS — from zero to operator track. Good luck! 🚀