Next steps for ‘Hidden Influencers’

With Paris only weeks away it’s time to announce that we have a time and place to meet people whose job is to decide what OpenStack means for their company. The OpenStack Foundation has offered a room to meet in Paris on Monday, November 3rd, in the afternoon: please add the meeting to your schedule.

There have been discussions in the past weeks about the hidden influencers, there was a recent call by Randy Bias to identify people, functions, groups, anything who can own the product OpenStack. The time is ripe to get to know who directly control the engineers’ priorities and complete the circle of end users, operators, product owners, developers.

Rob, Sean, Allison and I have the idea of creating a working group modelled after the Operators group: get people in the same room, some time mid-cycle and sync up on the development effort. It’s just an idea, mid-cycle is when the development roadmap gets more realistic, it’s more clear which blueprints are in good shape and which are less likely to make it into the release. We believe it would be valuable to have a moment when product decision makers can coordinate and get a chance to share their priorities.

The room is available for 4 hours, but of course we can use for less time if needed. It makes sense to start hacking some of the topics in the next weeks, before Paris. Please join the mailing list and introduce yourself while the agenda will be drafted on the etherpad. For naming the group you can join the async brainstorming session (drop names at random and don’t judge yourself nor others: everything is fair game).


Improving the content of OpenStack wiki

The pages on have been growing at a fast pace and it’s  time to give the wiki more shape: new contributors, end users and operators are having a hard time finding documentation since over time it spreads across many places. The wiki can have a role at directing readers where most appropriate. Luckily we have a team ready to help give the ~350 pages a more solid navigation and fixing content while at it:

  • Katherine Cranford (a trained taxonomist) volunteered to get through the wiki pages and propose a taxonomy for the wiki.
  • Shari Mahrdt, a recent hire by the Foundation, has volunteered a few hours per week to implement the taxonomy in the wiki pages, setup templates and write documentation to maintain the wiki.
  • I am overseeing the implementation and looking more carefully at content for contributors.

We are keeping track of things to do on the etherpad: Action_Items_OpenStack_Wiki. Shari and I started implementing Katherine’s proposed taxonomy: it’s visible as a navigable tree on

As an example of how the taxonomy works, let’s look at the tree of OpenStack Programs. One can think of Programs as teams of people using tools (code repository, bug tracker, etc) and coordinated processes to deliver one or more project to achieve a clearly stated objective. For  example, the Telemetry Program has a team of core reviewers responsible to drive development in code repositories for the Ceilometer project and the Ceilometer client, and each has pages for blueprints and specs, meeting notes and more. Programs contain projects, so the tree of categories under Programs will look like:
  • Programs
    • Telemetry
      • Ceilometer
        • Client
        • Blueprint
    • Block Storage
      • Cinder
        • Client
        • Blueprints
    • Compute
      • Nova
        • Client
        • Blueprints

You can see this live on the wiki on Fairly straightforward except that over the years some of the pages have started with describing a project and have now been repurposed to illustrate a Program. Look at Nova page for example: the name of the page is “Nova” but the title is OpenStack Compute. We’ll definitely have to shuffle content around.  For example, the Category:Programs page can be considered a duplicate of the wiki page: since everything on mediawiki is a page, the Category pages can be edited and can be redirected to/from like all other pages. In this case, it would make sense to make high level content like Programs more of a dynamic page, like Category:Programs. The cool thing of this approach is that we can probably create new category page for new programs automatically when modifications to the programs.yaml are approved via jenkins.

Adding a taxonomy and templates (more on this later) will help newcomers discover relevant content and find information more easily. While we implement the changes to the wiki we’ll also be reviewing the content on the pages, delete or mark as obsolete the old stuff and make things more readable for all. You can keep up with the progress by looking at RecentChanges.

If you’d like to help us out or find out more please feel free to contact and