Kedro team norms & ways of working ⭐️

This is how we reach alignment 🤝

• Through technical design sessions for larger technical topics.
  • Issues will be prioritised on the tech design board https://github.com/orgs/kedro-org/projects/2/views/19.
  • Issues should be fully detailed before discussion.
  • There should be space for disagreement in the session.
  • We aim to find broad agreement between everyone in the group: 2/3 majority or more, before we make a decision.
  • Tech Design sessions are open for everyone in the Technical Steering Committee.
  • Decisions and follow up actions are captured on the GitHub issues discussed.
• Through discussions on PRs or pair-programming sessions for smaller and specific technical topics.
• Through vision/goal sessions for broad product direction.
• Through 1-on-1 sessions for personal or small topics.

This is how we confront conflicts 🧐

• Through technical design sessions for technical topics.
  • Focus on what we agree on and leave some time for the contentious parts to crystallise before re-visiting the topic in a follow up session.
  • Bring pros and cons for the suggested implementation and allow opinions to be shared.
• We will always communicate honestly even if sometimes it means disagreement. As long as it's not personal or unkind it is ok!
• By giving each other regular constructive feedback.
• By making time to discuss conflict with the relevant parties. Not everything needs to be discussed with the full team. It's ok to take a discussion out in a safe space and in a relevant group size.
• In retrospectives for general conflict regarding work practices.

This is how we look back on and celebrate achievements 🥳

• Through bi-weekly Sprint demos.
• Through quarterly Kedro showcase sessions to show our work to the community.
• By giving praise to our teammates:
  • In retrospectives
  • In the shoutout Slack channel
  • On their pull requests
  • In 1-on-1 feedback sessions
• Through Sprint Reviews and office hours with the community
• By publicly showing our work:
  • In social media posts
  • In blog posts
• Through Kedro social events.

This is how we talk and share ideas 💡

• We have daily standup meetings, bi-weekly sprint planning, retrospective, backlog grooming and sprint demo meetings. These team meetings take priority and we all aim to attend.
• We aim to share information publicly unless it’s really not possible
• We have in-person meetings for important topics such as:
  • vision/goal setting
  • technical workstreams that benefit from whiteboard brainstorming
  • conflict resolution
• We use the #kedro-team Slack channel on QB for:
  • letting others know if you are unavailable for e.g. holiday, illness, training
  • sharing fun or useful information/links/code-snippets that cannot be shared on the #kedro-TSC Slack channel on the Kedro Slack organisation.
• We use the #kedro-TSC Slack channel on the Kedro Slack organisation for:
  • internal TSC discussions that don't need to happen in real time
  • sharing fun or useful information/links/code-snippets that are helpful within the TSC but not relevant more broadly
• We use Zoom for team meetings and 1-1 sessions that don't require us to be in the office.
  • We'll strive to turn on cameras for zoom meetings as much as possible.
• We use e-mail for scheduling meetings and communicating meeting preparations.
• We use Confluence and GitHub wikis to document team norms, processes, and other things we need to be able to find easily.
  • We will use Confluence only for internal information that cannot be shared with the open-source community.
• We use GitHub issues for sharing technical ideas or issues.
  • Keeping notes on technical (conflict) resolutions
  • Where necessary we will take conversation offline to Slack/Zoom/in-person but make sure to keep notes on the relevant GitHub issues