OpenStack SIGs

The OpenStack SIGs (Special Interest Groups) are a form of working group in OpenStack that is an emanation of the community as a whole and is not directly tied to a specific governance body.

SIGs are a good match for an activity that centers around a topic or practice that spans all the community (developers, operators, end users...), by forming a guild of people with a shared interest.

Name Chairs Scope
Chris Dent
Ed Leafe
Michael McCune
Formerly known as the API-WG, the API SIG scope is to improve the developer experience of API users by converging the OpenStack API to a consistent and pragmatic RESTful design. The working group creates guidelines that all OpenStack projects should follow for new development, and promotes convergence of new APIs and future versions of existing APIs.
Adrien Lebre
Paul-Andre Raymond
The goal of the FEMDC SIG (formerly Fog/Edge/Massively Distributed Clouds Working Group) is to debate and investigate how OpenStack can address Fog/Edge Computing use-cases (i.e. the supervision and use of a large number of remote data centers through a collaborative distributed OpenStack system).
Kendall Nelson
To provide a place for new contributors to come for information and advice. This group will also analyze and document successful contribution models while seeking out and providing information to new members of the community.
Chris Hoge
David Lyle
Robert Morse
Community-local counterpart to the k8s-sig-openstack group, focused on cross community communication and collaboration. Where k8s-sig-openstack spends a good deal of time managing upstream provider code, sig-k8s would likewise be focused on code to support and enable K8s deployments within the OpenStack community. This SIG is directly intertwined with k8s-sig-openstack within the Kubernetes community, with the same sig leadership and meetings.
Melvin Hillsman
Thierry Carrez
A SIG for SIGs so to speak. A SIG to discuss OpenStack SIGs themselves, to encourage workgroups to become SIGs, accompany them along the way, give them tools and processes to be efficient. More generally, this SIG will discuss how to best close the loop between users and developers of OpenStack.
Howard Huang
Chris Dent
Jay Pipes
The Resource Management SIG provides a gathering of similar interested parties and establish an official channel cross different communities, such as Kubernetes (Resource Management WG), Apache Mesos, Open Compute Project and so forth, to focus on alignment of resource management related functionalities.
Blair Bethwaite
Stig Telfer
Martial Michel
The Scientific SIG (formerly Scientific Working Group) is dedicated to representing and advancing the use-cases and needs of research and high-performance computing atop OpenStack. It’s also a great forum for cross-institutional collaboration. If you are (or would like to) run OpenStack to support researchers/scientists/academics and/or HPC/HTC, then please join!
Adam Spiers
Eric Kao
Coordinate the use and development of several OpenStack projects which can be combined in various ways to manage OpenStack infrastructure in a policy-driven fashion, reacting to failures and other events by automatically healing and optimising services.
James Page
Lee Yarwood
Lujin Luo
The objective of the Upgrade SIG is to improve the overall upgrade process for OpenStack Clouds, covering both offline ‘fast-forward’ upgrades and online ‘rolling’ upgrades, by providing a forum for cross-project collaboration between operators and developers to document and codify best practice for upgrading OpenStack.

SIG communications


Asynchronous communication between SIG members happens on the openstack-sigs mailing-list, using a subject [prefix] matching the SIG name. SIG work output can of course be posted to other mailing-lists as needed to reach other groups.

Instant Messaging

IRC is the preferred method of communication as it aligns with historical and current OpenStack community best practices for simple messaging, and is also required for TC governed projects.

It is understood that for some IRC does not come with enough features by default and programming a bot to offer additional features is beyond some; skill or patience to create/maintain. If a SIG does decide to use an alternative to IRC, we ask that in keeping with the Four Opens, in particular Open Community, that you do so by ensuring meeting logs are stored/archived.


Free team accounts with Slack are not sufficient enough to meet archiving/storage of logs alone. A great alternative is to connect Slack with IRC and then follow the instructions for logging an IRC channel. Refer to for a Slack+IRC connector; a docker image is also available at

Bi-weekly Newsletter/Summary

We are suggesting to follow a great tradition started for the openstack-dev mailing list, by sending out a newsletter summarising SIG activity on a bi-weekly basis. In order to reduce the work on individuals writing and/or reading summaries for SIGs, we have an etherpad which will be compiled bi-weekly and sent to the openstack-sigs mailing list and other relevant places. We ask that SIG leaders provide updates as they see fit to the etherpad; this is not a requirement.

Process to create a SIG

To propose creation of a SIG, please propose a change to the sigs.yaml file in the openstack/governance-sigs repository. That change will be reviewed by members of the Meta SIG. If you have questions, please ask them on the openstack-sigs mailing-list with prefix [meta].

Table Of Contents

This Page