This week, Joshua McKenty, me and a handful of interested individuals (board member Eileen Evans included) met to start organizing the DefCore* Committee.  This standing committee was established by an OpenStack Foundation resolution just before the Hong Kong Summit.  Joshua and I were nominated as co-chairs (and about half the board volunteered to be members).    This action was an immediate result of the unanimous passage of the 10 Principles that I was driving in the DefCore “Spider” cycle.

We heard overwhelmingly at the Hong Kong summit that defining core should be a major focus for the Board.

The good news is that we’re doing exactly that in CoreDef.  Our challenge is to go quickly but not get ahead of community consensus.  So far, that means eating the proverbial elephant in small bites and intentionally deferring topics where we cannot find consensus.

This meeting was primarily about Joshua and I figuring out how to drive DefCore quickly (go fast!) without exceeding the communities ability to review and discuss (build consensus!).  While we had future-post-worthy conceptual discussions, we had a substantial agenda of get-it-done in front of us too.

Here’s a summary of key outcomes from the meeting:

1)      We’ve established a tentative schedule for our first two meetings (12/3 and 12/17).

1. We’ve started building agendas for these two meetings.
2. We’ve also established rules for governance that include members to do homework!

2)      We’ve agreed it’s important to present a bylaws change to the committee for consideration by the board.

1. This change is to address confusion around how core is defined and possibly move towards the bylaws defining a core process not a list of core projects.
2. This is on an accelerated track because we’d like to include it with the Community Board Member elections.

3)      We’ve broken DefCore into clear “cycles” so we can be clearer about concrete objectives and what items are out of scope for a cycle.  We’re using names to designate cycles for clarity.

1. The first cycle, “Spider,” was about finding the connections between core issues and defining a process to resolve the tension in those connections.
2. This cycle, “Elephant,” is about breaking the Core definition into
3. The next cycle(s) will be named when we get there.  For now, they are all “Future”
4. We agreed there is a lot of benefit from being clear to community about items that we “kick down the road” for future cycles.  And, yes, we will proactively cut off discussion of these items out of respect for time.

4)      We reviewed the timeline proposed at the end of Spider and added it to the agenda.

1. The timeline assumes a staged introduction starting with Havana and accelerating for each release.
2. We are working the timeline backwards to ensure time for Board, TC and community input.

5)      We agreed that consensus is going to be a focus for keeping things moving

1. This will likely drive to a smaller core definition
2. We will actively defer issues that cannot reach consensus in the Elephant cycle.

6)      We identified some concepts that may help guide the process in this cycle

1. We likely need to create categories beyond “core” to help bucket tests
2. Committee discussion is needed but debate will be time limited

7)      We identified the need to start on test criteria immediately

1. Board member John Zannos (in absentia) offered to help lead this effort
2. In defining test criteria, we are likely to have lively discussions about “OpenStack’s values”

8)      We identified some out of scope topics that are important but too big to solve.

1. We are calling these “elephants” (or the elephant in the room).
2. The list of elephants needs to be agreed by DefCore and clearly communicated
3. We expect that the Elephant cycle will make discussing these topics more fruitful

9)      We talked about RefStack code features

1. Allowing users to upload/post test results from their clouds to enable white box test reporting
2. Allowing users who have uploaded results to +/- vote on tests they think are important
3. We established a requirement that posting results requires an OpenStack ID
4. We established a requirement that only a single Corporate designate (provided by the Foundation) can make a result official for their company.
5. Collecting opt-in data with test results using tags for things like alternate implementations use, host operating system(s), deployment method, size of cloud, and hypervisor.
6. We discussed (but did not resolve) that it could be possible to have people run RefStack against public cloud end points and post their results
7. We agreed that RefStack needs to be able to run locally or as a hosted site.

10)   We identified a lot of missing communication channels

1. We created a DefCore wiki page to be a home for information.
2. Joshua and I (and others?) will work with the Foundation staff to create “what is core” video to help the community understand the Principles and objectives for the Elephant cycle.
3. We are in the process of setting up mail lists, IRC, blog tags, etc.

Yikes!  That’s a lot of progress priming the pump for our first DefCore meeting!