Open Stack

Hi Sean,

I apologize for the late review...

Can you please elaborate on the "DefCore spot check" in the process
workflow?  Generally we will probably have capabilities (API introduction)
and non-capabilities (e.g. fixes, enhancements, etc.) and, therefore, not
all roadmap items may even qualify to be a capability in DefCore.
Furthermore, DefCore will only account for API sets with broad adoption and
new requirements from our output will probably not hit the required
threshold for DefCore consideration until at least N+1 release cycle (at a
minimum).

I agree that we do need alignment with DefCore but my suggestion would be
to make it a consumer of the output and an advisor to the input as opposed
to being in the roadmap process itself.  At the conclusion of each release
cycle, and prior to starting the next iteration of the roadmap process, we
should determine if any of our prior roadmap items have reached the "broad
adoption" threshold (by reviewing collected data from RefStack) and, in
that case, we should propose for them to be included as DefCore
capabilities.  Likewise, if we find that certain capabilities are failing
in a high percentage of deployments then we should be able to get that as
input into the roadmap (e.g. fix a capability that is already deemed a part
of the OpenStack brand).

Should requirements identified by other teams such as WTE or the API WG be
called out as a specific item in the workflow so that we can establish what
the interlock process would look like for this task?  I think item 1a
currently covers the act of gathering requirements but does it make sense
to break out requirements collected from users, projects teams, and other
working groups independently in the process?

-- 
Thanks,
Shamail Tahir
Cloud Architect, EMC
t: @ShamailXD
tz: Eastern Time

On Tue, Feb 24, 2015 at 9:42 PM, sean roberts <seanroberts66 at gmail.com>
wrote:

> Now that DefCore is somewhat finished for the next board meeting, I have
> cycles to focus on the product team.
>
> I have to point out that the more I discuss the product team with people
> both within and without OpenStack, I get more interested in what we can
> accomplish with this work. Getting down off my soapbox. I share the product
> team release process that was started at the last face to face meeting.
>
> https://docs.google.com/document/d/13JPDDiBGGXf5dtP0u8C-1So2Mjb3yEmGhv_ijVqyEf0/edit?usp=sharing
> .
> I have fleshed out some basics with a timeline and responsibilities. I am
> creating the flowchart as I send this email.
>
> Win-the-enterprise, project tagging, incubation-lite, and DefCore will
> overlap with what we are working on here. I will keep updating this ML as I
> figure out new information. Do the same as you hear new issues and
> discussions that can effect our work.
>
>