OpenStack Terms and You

I think we need to start from the beginning to know a bit about where we really are...and to do that we need to speak the same language. This doesn't mean we must agree on the actual terms used, but that their definition and evidence of need are spelled out and can inform the following steps and discussion.

In some cases, the bikeshed will simply be in primer with placeholders until we converge an appropriate terms.

The Technical Committee Charter refers to some terms that should be clarified early in this process.

• Official Programs - The current unit of organization, called a program, logically groups people and code for purposes of achieving the OpenStack project mission. The current programs are generally teams of people woring on a common project or set of related projects. These teams elect a Program Team Lead (PTL) who has management responsibilities to the program. A proposal to change this terminology to project team is in part intended to reinforce the idea that these are groups of people first and code repositories second. The proposal is part of a series to re-structure the organization of OpenStack projects and by itself is mostly for clarity. It does not appear to be controversial based on the comments so far so I will adopt it here.

• Program Leads - We've all grown to love the term PTL and the change from program to team can be used to re-redefine PTL as project team lead as it once was back in the day.
• Oversight - The TC charter includes "[the TC] still has oversight over team decisions, especially when they affect other programs or go contrary to general OpenStack project goals". There is concern about the balance between project rights and responsibilities changing. There may also be concerns over what that balance is today.

I'm looking for the baked-in connection between governance organization and deliverables. Today we have a 1:1 between official teams (programs) and their participation in the "integrated release". Many of the proposals floating about disconnect those.

• Coordinated Release Cycle - The time period roughly starting at or just before the semi-annual Design Summit and ending approximately six months later, again just before the next Design Summit.

• Release Artifacts - The output of the process formerly known as integrated release. These are the major output of the coordinated release cycle and typically what distributions would consume in building their periodic releases.

• Project Groups - Project groups are simply groups of related projects and/or project teams that are dependent on each other and it is often useful to consider the projects together for certain matters. For example Group C includes Nova, Glance, Cinder and Neutron. Other groups might include Group I (Keystone and plugins), Group O (Swift), Group W (litterbugs), Group H (Ironic and other hypervisor drivers), Group D (Trove), Group M (Zaqar), and so on. Many groups may only have one member if there are not multiple projects with a strongly set of similar or mutual dependencies.

  One use of project groups is in simplifying the relationship diagram between projects; the diagram between projects within the group can focus on that subset and the diagram between groups can minimize the effect of the intra-group relationships. These diagrams should be useful in informing testing policy and requirements.

  These groups map into my layers description with layer one comprised of Groups I and most of C and layer 2 comprised of Groups O, H and the remainder of C (Cinder). Remaining groups of official OpenStack projects make up layer 3.

• Integrated Release - The first step is to change the term integrated release to something better defined and less overloaded. This is highly contentious as you might expect. I had intended on using nucleus to describe this chewy middle of OpenStack because it has all sorts of metaphorical nooks and crannies to be mined, but then I saw nuclear release in writing and decided to just use the rather archaic term bindle here instead, as in "the OpenStack Bindle contains the basic cloud necessities".

  The key part of the existing definition, "The OpenStack bindle is a subset of the official OpenStack projects whose member teams submit to stricter policies and oversight", divides the official OpenStack projects into at least two tiers. dhellmann describes it like this:

  size(ecosystem) > size(official-projects) > size(bindle)
  

  Inclusion in the integrated release has become the high-value attribute for many corporations judging project worthiness for contribution and/or use. Removing this attribute is one of the major driving forces for re-considering the organizational structure in general and in renaming and clearly defining the bindle.

  The makeup of the bindle defines what release artifacts are published as a result of the release process. These projects are held to a higher bar in regards to testing, documentation in involvement of team members in horizontal OpenStack activities.