Open Stack

Defcore Committee,

We've got a small amount of work remaining to complete the capabilities matrix - we'll need experts on object and volume to complete.   I'd like to see if we can get together early next week for a working session.

ALSO, please review the community communication doc about the Capabilities for publication next week:
https://docs.google.com/document/d/1rxDkjcgPlYKuEmcV_Nigp1bSoMRrV7iyJMQ8fzwTr9M/edit?usp=sharing   (I'm copying the text to this email too, but please direct comments to the online version)

Rob


> note: this material will be used to introduce the Capabilities Scorecard to the community for review.  We need to give enough background but make the scorecard the center of the information.



Introducing the DefCore Capabilities Scorecard & Core Identification Matrix



Insert reference to other docs here, including Mark Collier's post: https://www.openstack.org/blog/author/sparkycollier/



The OpenStack Core definition process<https://www.openstack.org/blog/author/sparkycollier/%20> (aka DefCore) is moving steadily along and we're looking for feedback from community as we move into the next phase.  Until now, we've been mostly working out principles, criteria and processes that we will use to answer "what is core" in OpenStack.  Now we are applying those processes and actually picking which tests will be used to identify Core.



TL;DR: We are now RUNNING WITH SCISSORS because we've reached the point there you can see what's going to be considered Core (and what's not).  We now have tangible draft lists for community review.



While you will want to jump directly to the results, it is important to understand how we got here because that's how DefCore will resolve the inevitable conflicts.  The very nature of defining core means that we have to say "not in" to a lot of capabilities.  Since community consensus seems to favor a "small core" in principle, that means many capabilities that people consider important are not included.



The Core Identification Matrix attempts to find the right balance between quantitative detail and too much information.  Each row represents an "OpenStack Capability" that is reflected by one or more individual tests.  We scored each capability on a 100 point scale using 13 different criteria.  These criteria were selected to respect different viewpoints and needs of the community ranging from popularity, technical longevity and quality of documentation.



While we've made the process more analytical, there's still room for judgement.  Eventually, we expect to weight some criteria more heavily than others.  We will also be adjusting the score cut-off.  Our goal is not to create a perfect evaluation tool - it should inform the board and facilitate discussion.  In practice, we've found this approach to bring needed objectivity to the selection process.



So, where does this take us?  The first matrix is, by design, old news.  We focused on getting a score for Hanava to give us a stable and known quantity; however, much of that effort will translate forward.  Using Havana as the base, we are hoping to score Ice House ninety days after the Juno summit and score Juno at K Summit in Paris.



These are ambitious goals and there are challenges ahead of us.



Specifically, we know there are gaps in OpenStack test coverage.  Important capabilities do not have tests and will not be included.  Further, starting with a small core means that OpenStack will be enforcing an interoperability target that is relatively permissive and minimal.  It's vital to remember that we are looking for evolutionary progress that accelerates our developer, user, operator and ecosystem communities.



How can you get involved?  We are looking for community feedback on this 1st pass - we do not think we have the scores 100% right.



We will eventually use RefStack to collect voting/feedback on capabilities directly from OpenStack community members.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/defcore-committee/attachments/20140407/80a4a92e/attachment.html>