Skip to content

Kedro team norms & ways of working ⭐️

Jo Stichbury edited this page May 4, 2023 · 2 revisions

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
Clone this wiki locally