Open Stack

On Fri, Dec 19, 2014 at 1:20 PM, Haselmaier, James <James.Haselmaier at emc.com
> wrote:

> Regarding what we could be working on as the Product group:  I thought I’d
> send email and see if it sparked input rather than make Wiki changes at
> this point.
>
> I don’t think we need to be focused on the topics that are more
> “operations” focused – such as tracking quality or even prioritizing
> specific bugs.  I do think, however, there are needs for some sort of
> Product Management-type of deliverables where we could add value:
> *  User Personas.  Define the different users and their high level needs
> and areas of focus.  This would be an aggregation of actual users and
> characteristics they have.  I think it could result in Personas such as IT
> Manager, Cloud Admin, Infrastructure Admin, Application Developer, etc.
> For each there would be information about what their jobs are, what they
> need out of a cloud technology, how they prefer to interact with the
> environment, etc.
>

I think this group is uniquely suited to helping out with user personas -
the OpenStack UX folks already have a working group going around personas
that's done some work:

https://wiki.openstack.org/wiki/Personas




> *  Drive collection and consolidation of information about where OpenStack
> might need to go – on a multi-release / multi-year type of level.  This
> could result in things like Multi-Cloud Support, Significantly Easier
> Deployment, Higher Level Application Services, Billing Integration,
> Directory Integration, Security/Hardening, etc.
> *  Work with project teams during release planning on blueprint definition
> and prioritization.
> *  Provide a cross-project perspective that might not come through at the
> individual project level.  The API consistency issue is a very good example
> of this kind of issue.  The individual projects might not see this as
> having as high a priority as a user does who is consuming multiple projects
> and has to deal with it on a day-to-day basis.
>

This all sounds good - but it also sounds like a lot of continuous work and
commitment to be a part of the community in ways that haven't yet existed.
To that end, I wonder how this collaboration might happen. I know there's a
mid-cycle meetup being planned - is there anything else that might make
sense for us to do on a more regular (weekly?) basis? I have all of the
where/how questions about the above list (which is a *great* one) - and one
question that Allison,Sean and Rob posited at the Summit still sticks in my
craw: are we all willing, as a group, to share pieces of our
roadmap/customer feedback & internal prioritization at the open source
level to help out with this?

It might be a thing that has to develop organically through meetings, but I
do think developing our own upstream shared space of understanding and ways
of work will be the first step, before we can provide a unified vision to
present & help with project work happening upstream.



> IMHO all of the above should be offered in the spirit of providing input
> to the teams, NOT telling them what is to be done.  I also think once a
> release is off-and-running (from a development perspective) that this
> group’s involvement would be minimal – possibly nothing at all.  It seems
> to me the processes around actually developing what is decided to be
> developed are working pretty well.  Things seem to be getting done as
> planned.  I don’t see a need for the projects to have additional
> involvement during the development and release process.
>
>
++
I agree wholeheartedly with all of the above, *especially* with the
not-telling-project teams what to do. I do think some work could/might be
done by this group during a development cycle with an eye towards
presenting to developers or teams before the summit for the next
development cycle. I also think for folks who are on the more program
spectrum of things (as opposed to product management), meeting or gathering
mid-cycle to reaffirm resource commitments through the end of the
development cycle, or all folks gathering to help re-prioritize if projects
need it, wouldn't be awful either.



The bottom line:  I think there is an opportunity to add greater context as
> to how the software is being used, where it could/should be going, and
> working with the project teams as releases are planned to influence that
> direction.
>
> Jim
> _______________________________________________
> Product-wg mailing list
> Product-wg at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/product-wg
>


Thanks for providing the jumping off point for my questions, Jim - I'm
really looking forward to hearing everyone's thoughts on how we can become
an upstream collaboration point together to help out OpenStack.

Oh, and since I didn't do intros yet - I'm Colette, and I work at HP with
the OpenStack team there as a program manager of sorts. Hi everyone!

-colette