Open Stack

Suggest we start higher – use cases.
Use Case is project independent.
Then based on the use case we can create blueprints for specific projects.
Then Specs.
We can track progress of the use case support based on all blueprints for it.

I would like to start with relatively small use case – DB cleanup of deleted objects.
It came multiple times in different projects I am involved.
Projects correctly decided that it does not belong in them directly.
Maybe it will land in Oslo, maybe in separate scripts in Rally or maybe separate project for operator tools.

Need to start somewhere, create use case (define format and repo for it). Then review. Decide who from outside Product WG we should ask to review it.

Pick some use case and do dry run.
Thanks,
Arkady

-----Original Message-----
From: Jean-Daniel Bonnetot [mailto:jean-daniel.bonnetot at ovh.net]
Sent: Friday, June 05, 2015 11:47 AM
To: Haselmaier, James
Cc: product-wg at lists.openstack.org
Subject: Re: [Product] How use cases works

hmm…
In a perfect world I agree with you.
In reality, it’s more complex.

Blueprint, currently, are the *What that need to be done*.
And specs are the *What* + *How*.

Here is an example
BP: https://blueprints.launchpad.net/nova/+spec/flavor-resize-restriction
Specs: https://review.openstack.org/#/c/182345/

The *use case* is really well explained in the specs (where you can find the *How* too) and the blueprint give a good idea of *What that need to be done*.
To give you a use case, I can’t say more that you can already read in the specs in the 36 first lines.

--
Jean-Daniel
@pilgrimstack




> Le 5 juin 2015 à 16:28, Haselmaier, James a écrit :
>
> I havenąt had a great amount of exposure to Blueprints, but with some
> quick scanning my take:
>
> Use Cases should focus on the łWhat˛ that needs to be done. They
> should document the desired outcome and establish clear context and
> background as to why that is needed. The Blueprint should reflect a
> specific implementation of how that łWhat˛ will be solved. The
> Blueprint documents the łHow˛ - the technical details of what will
> actually be done in the code/system in order to accomplish addressing
> the Use Case. If a Use Case is written well (IMHO) there might be a variety of ways to solve it.
> (I.e. If a łUse Case˛ is written such that it specifies how a sw eng
> is to implement it then itąs not a use case.) It becomes the project
> teamąs area of expertise to decide which implementation works the best
> - factoring in a variety of factors. There also may be situations
> where it takes multiple Blueprints to solve a single Use Case.
>
> In a perfect world the Blueprint might contain a link to the Use Case
> that is the basis of the Blueprint. Similarly the Use Case might
> contain a link to the Blueprint(s) that are being implemented to
> address the Use Case. But, frankly, for the progress we need to make
> with the Product WG at this stage, Iąd propose we put that linking
> between Use Cases and Blueprints as something we work on down the road.
>
> Jim
>
> On 6/5/15, 7:16 AM, "Jean-Daniel Bonnetot"
>
> wrote:
>
>> Hi all,
>>
>> Good to see your work. I have some questions.
>> I already summit some blueprint and spec.
>> Do I have to write a use case in addition?
>> How to be efficient and not multiplying same content?
>>
>> https://drive.google.com/folderview?id=0BxtM4AiszlEyfllFelZYR2RqNDFfW
>> VRvWW tlb09laGxwR2ljc3UxVEl5VEpfMEhicnlxUFk&usp=sharing
>>
>> --
>> Jean-Daniel Bonnetot
>> http://www.ovh.com
>> @pilgrimstack
>>
>>
>>
>> _______________________________________________
>> Product-wg mailing list
>> Product-wg at lists.openstack.org
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/product-wg
>


_______________________________________________
Product-wg mailing list
Product-wg at lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/product-wg