Requirements for new OpenStack User Committee Working Groups and Teams

The OpenStack user community is global and use OpenStack clouds to meet a diverse and broad range of use cases. The User Committee working groups and teams aim to help these users represent and achieve their needs through collaboration in the upstream community. The working groups and teams can be created as-needed and grow organically.

To help these groups and teams achieve their goals, the User Committee has established criteria that working groups and teams should adhere to in order to be considered an official working group or team. By becoming an official OpenStack User Committee Working Group/Team, the team places themselves under the governance of the OpenStack User Committee. The criteria is provided below and aims to foster collaboration, transparency, and accessibility of the teams for new community members.

The first step is to determine whether you want to establish a Working Group or Team.

  • Working Groups are temporary with short or medium term goals and exist until they have achieved such goals(e.g. proposing logging enhancements, discussing how to increase the scalability of OpenStack clouds, etc.).

  • Teams are permanent addressing areas that require ongoing collaboration and iteration to execute their objective (e.g. representing enterprise needs in the community, performing product management like functions in the community, etc.) as long as they maintain a meaningful mission in order to help the UC to achieve its mission.

When considering new working groups/teams for addition, the UC will check that:

  • The working group/team aligns with the User Committee mission

  • The group must have a clear and defined scope and duration of the effort

  • The group follows the OpenStack way (“the 4 opens”):

    • Open Source:

      • Follows the OpenStack project definition of Open Source.

    • Open Community:

      • The leadership is chosen by the contributors to the group

      • The group has regular public meetings on IRC (at least once a month during those months in which the group is actively working on items) and those meetings are logged, published in the OpenStack meeting calendar via Eavesdrop, and held in an official official OpenStack meeting channels once the project’s application is accepted, if they’re not held there already.

      • If the team uses alternative methods of communication to augment public meetings on IRC then they should provide a summary of their meetings on the User Committee mailing list.

      • The group shall provide a level and open collaboration playing field for all contributors. The group shall not benefit a single vendor, or a single vendor’s product offerings; nor advantage contributors from a single vendor organization due to access to information, resources or other proprietary resources available only to those contributors.

    • Open Development:

      • The group uses etherpads for all meetings

      • If the group is using other content collaboration tools, those artifacts should be linked in an etherpad and be publicly accessible.

      • Where it makes sense, the group cooperates with existing official User Committee working groups and teams to facilitate further collaboration and avoid duplication.

      • If the group requires a repository, it should be created under the governance of the UC.

    • Open Design:

      • The group direction is discussed at the Forum and/or on public forums, and mailing lists.

      • The group uses the user-committee ML and UC IRC meetings to discuss issues.

  • The group should have an active team of two or more contributors

  • The group meets any policies that the UC requires all official working groups/teams to meet and will also honor future policies that are defined by the UC.

  • The WG chair (or designated member) must join the User Committee IRC meetings, at a minimum, once a month and provide an update on WG activities/progress.

In order to do an evaluation against this criteria, the UC expects the group to be set up and have some history to evaluate. This can be accomplished by the WG/Team setting up a wiki page on which lists objectives along with progress being made by the team via documentation (i.e. etherpads, Google Docs), meeting logs, links, etc; please ensure these items are openly/publicly accessible.

If a working group or team fails to maintain adherence with these requirements then a decision could be made to revoke its official WG/Team status.