/community

Istio Community events and related information such as meeting notes, etc.

Apache License 2.0Apache-2.0

Istio Community

Welcome to the Istio community!

This is the starting point for becoming a contributor - improving docs, improving code, giving talks etc.

Table of Contents

  1. Community Meeting
  2. Working Groups
  3. How can I help?
  4. General Developer Communication Information

Community Meeting

We have PUBLIC and RECORDED bi-weekly community meetings every Thursday at 11am US Pacific Time.

Map that to your local time with this timezone table.

Working Groups

Istio is a set of components, each shepherded by dedicated working groups.

Each group's material is in its subdirectory in this project.

A first step to contributing is to pick from the list of istio working groups below:

Name Leads Mailing List Example Topics
Core Sven Mawson (Google), Louis Ryan (Google), Martin Taillefer (Google), Shriram Rajagopalan (IBM), Dan Berg (IBM) istio-core@ Configuration, Performance, Stability
Security Wencheng Lu (Google), Etai Lev-Ran (IBM), Michael Elder (IBM) istio-security@ Service-to-service Auth, Identity/CA/SecretStore plugins, Identity Federation, End User Auth, Authority Delegation, Auditing
Networking Andra Cismaru (Google), Kuat Yessenov (Google), Shriram Rajagopalan (IBM), Christopher Luciano (IBM) istio-networking@ Pilot integration, TCP Support, Additional L7 protocols, Proxy injection
Environments Costin Manolache (Google), Laurent Demailly (Google), Jose Ortiz (IBM) istio-environments@ Raw VM support, Hybrid Mesh, Mac/Windows support, Cloud Foundry integration
Integrations Martin Taillefer (Google), Todd Kaplinger (IBM) istio-integrations@ Mixer Adapter Model, Rate Limiting, Tracing, Monitoring, Logging
API Management Wencheng Lu (Google), Jason Allor (Google), Tony Ffrench (IBM) istio-api-management@ API Keys, Content Mediation, Content Translation, OpenAPI Ingestion

How Can I Help ?

Documentation (like the text you are reading now) can always use improvement!

There's a list of issues that should not need deep knowledge of the system.

To dig deeper, read a design doc, e.g. architecture.

There's always code that can be clarified and variables or functions that can be renamed or commented.

There's always a need for more test coverage.