Kedro's Technical Steering Committee¶

Kedro is a graduate-stage project within LF AI & Data.

The term "Technical Steering Committee" (TSC) describes the group of Kedro maintainers, committers, and advisors. We list Kedro's current and past TSC members on this page.

The TSC is responsible for the project's future development; you can read about our duties in our Technical Charter. We accept new members into the TSC to fuel Kedro's continued development.

On this page we describe:

• Kedro TSC roles
• Responsibilities of a maintainer
• Process to become a maintainer
• Responsibilities of a committer
• Process to become a committer
• Responsibilities of an advisor
• Process to become an advisor
• Current TSC members
• Past TSC members
• Voting process
• Adding or removing TSC members

Kedro TSC roles¶

The Kedro TSC is responsible for the project's future development. The TSC is made up of the following roles:

Maintainers¶

Maintainers form the core of the TSC and hold the right to vote on both code modifications and TSC membership changes. They are expected to make significant contributions to the strategy, direction, and governance of the project. Their primary responsibility is to ensure the long-term success of Kedro.

Committers¶

Committers have repository access and full participation rights in discussions but do not hold voting privileges. They are active contributors who focus on different areas of the project. Committers are responsible for maintaining the health of the project, participating in planning and (technical) design decisions, and otherwise acting as part of the core Kedro development team.

Advisors¶

Advisors are individuals who are not actively contributing to the codebase or attending regular meetings but provide valuable expertise, feedback, and strategic guidance to the Kedro project.

Responsibilities of a maintainer¶

• Defining and maintaining the product vision and roadmap
• Supporting key technical and strategic initiatives
• Providing input on complex or high-impact technical decisions
• Advising and mentoring contributors
• Representing Kedro within the broader community
• Attend regular team meetings to discuss the project plans and roadmap

Voting rights¶

Maintainers take part in four types of votes:

• Membership additions – new maintainers must receive majority approval (≥50%) from existing maintainers (see more details below)
• Membership removals – existing maintainers can be removed by a majority vote of the TSC
• Code modifications – follows the KEP process
• Core dataset additions or removals – follows the kedro-datasets contribution guide

Process to become a maintainer¶

Just contributing does not make you a maintainer. You need to show commitment to Kedro's long-term success by being an advisor or committer on the TSC for at least six months.

We look for people who can do at least some of the following on top of the responsibility of a maintainer:

• Steer the direction of the project to ensure it retains relevance, including by bringing awareness of industry trends to the team and connecting the project to complementary initiatives
• Give talks about the project at conferences and online events, write blog posts, or other forms of advocacy
• Show excitement about the future of Kedro

Any current maintainer may nominate a new candidate and will serve as their advocate, responsible for initiating and managing the voting process. The nominating member should open a pull request and formally call for a vote on the candidate, posting the announcement in the #kedro-tsc channel on the Kedro Slack organisation.

The voting period should remain open for at least two weeks, and the proposal will pass with a majority approval. Once voting concludes, the #kedro-tsc channel should be updated with the final results.

Inactivity and removal¶

Maintainers may be automatically removed after 6 months of inactivity, without requiring a formal vote. Inactivity is defined as:

• Not participating in any votes for 6 consecutive months (if any votes were required)
• Not joining regular technical design meetings or roadmap discussions for more than 6 months

A former maintainer may rejoin in the future, provided they secure an advocate among current maintainers who will sponsor their nomination for a new vote.

Responsibilities of a committer¶

Depending on the role of the committer in the team, they are responsible for some of the following:

• Driving implementation, technical quality, and code excellence
• Be proactive about project maintenance including security, updates, CI/CD, builds and infrastructure
• Leading work on user experience, interface design, and information architecture
• Improve the aesthetics and usability of the project, including its documentation, website, and user interfaces (graphical and textual)
• Conducting product research, gathering user feedback, and shaping feature priorities
• Give priority to the work following the product roadmap to move the project forward

Community management¶

• Ensure that ongoing pull requests are moving forward at the right pace or closing them
• Guide the community to use our various communication channels:
  • GitHub issues for feature requests and bug reports
  • GitHub discussions to discuss the future of the Kedro project
  • Slack for questions and to support other users

Process to become a committer¶

Any current maintainer may nominate a new candidate and will serve as their advocate, responsible for initiating and managing the voting process. The nominating member should open a pull request and formally call for a vote on the candidate, posting the announcement in the #kedro-tsc channel on the Kedro Slack organisation.

The voting period should remain open for at least two weeks, and the proposal will pass with a majority approval. Once voting concludes, the #kedro-tsc channel should be updated with the final results.

The new committer should then be added to the kedro-developers team on the Kedro GitHub organisation, the kedro-tsc channel on the Kedro Slack organisation, the regular TSC meetings, and the CITATION.cff file.

Inactivity and removal¶

Committers who do not contribute code, documentation, or attend regular meetings for 6 months will be automatically removed from the current TSC members list, kedro-developers team, and CITATION.cff file. They may be invited to join the advisor role if they are interested in continuing to support and contribute to the project in a different capacity.

Responsibilities of an advisor¶

• Providing ongoing, high-level guidance on direction, governance, and technical topics (rather than ad-hoc support)
• Acting as external ambassadors or thought partners
• Sharing lessons learned and best practices from adjacent domains

Process to become an advisor¶

Any current maintainer may nominate a new candidate and will serve as their advocate, responsible for initiating and managing the voting process. The nominating member should open a pull request and formally call for a vote on the candidate, posting the announcement in the #kedro-tsc channel on the Kedro Slack organisation.

The voting period should remain open for at least two weeks, and the proposal will pass with a majority approval. Once voting concludes, the #kedro-tsc channel should be updated with the final results.

Inactivity and removal¶

Advisors may be automatically removed after 6 months of inactivity. Inactivity is defined as a lack of any engagement with Kedro during this period.

Current TSC members¶

Past TSC members¶

Kedro was originally designed by Aris Valtazanos and Nikolaos Tsaousis at QuantumBlack to solve challenges they faced in their project work. Their work was later turned into an internal product by Peteris Erins, Ivan Danov, Nikolaos Kaltsas, Meisam Emamjome and Nikolaos Tsaousis.

Former core team members with significant contributions include Ahdra Merali, Amanda Koh, Andrew Mackay, Andrii Ivaniuk, Anton Kirilenko, Antony Milne, Cvetanka Nechevska, Dmitrii Deriabin, Gabriel Comym, Gordon Wrigley, Hamza Oza, Ignacio Paricio, Jannic Holzer, Jo Stichbury, Juan Luis Cano, Jiri Klein, Kiyohito Kunii, Laís Carvalho, Liam Brummitt, Lim Hoang, Lorena Bălan, Mehdi Naderi Varandi, Nasef Khan, Nero Okwa, Richard Westenra, Susanna Wong, Vladimir Nikolic and Zain Patel.

Voting process¶

Voting can change TSC members and decide on the future of Kedro. The maintainers of the TSC lead the process. The voting period is two weeks and through a GitHub discussion or through a pull request.

Other issues or proposals¶

Kedro's GitHub discussions section is used to host votes on issues, proposals and changes affecting the future of Kedro. This includes amendments to our ways of working described on this page. These follow the KEP voting process.

Adding or removing core datasets¶

The addition or removal of core datasets is done through a vote by the TSC. The voting process is described in the kedro-datasets contribution guide.

Adding or removing TSC members¶

Voluntary step-out¶

Any member may choose to step out of their current role at any time by communicating their decision to the TSC. No vote is required.

Voluntary step-down¶

Any member may request to step down to a non voting category at any time if they believe they can contribute more effectively in that role. This change does not require a vote.

Step-up procedure¶

Members who wish to move up to a category that requires a higher commitment (advisor to maintainer or committer, or committer to maintainer) must receive formal approval through a TSC vote. The member must also have an active TSC maintainer advocate to support their nomination.

Automatic removal and transition option¶

If a member is automatically removed from their current category (due to inactivity), they can request placement in the next lower level within two weeks of their removal. If no request is made within that time frame, the member will be removed from the TSC entirely.