Open Stack

In the opening statement I’d like to use the terms that came out of the taxonomy effort during last week’s Product meet-up.  I think consistency in the terms we use for different groups.  It makes subsequent communications much easier.  The taxonomy sub-group created a graphic which can be found at the URL below.  I also included a slide with term definitions.

https://docs.google.com/presentation/d/1uBH6NhWPPpzhbLQ9BZn2PMx8H0VgyXPTTCkxwuSQcNQ/edit#slide=id.gf7b25a4ed4277290

So - the opening sentence could look like this:
To listen, and aggregate, feedback on the desired capabilities for the OpenStack platform from multiple key sources including the contributor community (PTLs & contributors), Operators, App Developers, OpenStack vendors, and Services Providers.

The last sentence could be:
Finally, we will also help users and vendors be successful with adoption of the platform by leveraging additional development resources on areas that are identified as high impact by removing barriers to adoption/operation.

Jim



On 1/31/15, 12:13 PM, "AJ Park" <aj.park at icloud.com<mailto:aj.park at icloud.com>> wrote:

Thanks Stefano and Shamail for putting this together. The list looks
good. One comment:

Can we add something to the list that speaks to our team trying to ensure
the high priority items in the roadmap actually get worked on? This could
include evangelizing the roadmap whenever we get a chance, or try and
influence/commit developers to work on the high priority items.

I am suggesting adding something like:

*Help Drive Adoption of the Roadmap"

Try to ensure high priority items in the roadmap get the necessary
developer attention by socializing the roadmap in the community and
attempting to influence and commit developers to high priority items that
need attention.

Best,
AJ

On Jan 28, 2015, at 01:44 AM, Shamail Tahir <itzshamail at gmail.com<mailto:itzshamail at gmail.com>> wrote:

Hi Stefano,

Thanks for sending this out and for volunteering to update the wiki. I
have used the base items mentioned in the ether-pad summary to create a
new
version of the mission and details on planned activities. I look forward
to the team's feedback and potential edits.

*Mission of the Product Working Group:*

To listen, and aggregate, feedback on the desired capabilities for the
OpenStack platform from multiple key sources including the contributor
community (PTLs), customers, and users. The group will also aim to help
PTLs and contributors resolve issues that are either of strategic
importance or have broad implications across a multitude of services.
Finally, we will also help customers/users be successful with adoption of
the platform by leveraging additional development resources on areas that
are identified as high impact by removing barriers to adoption/operation.



*Details on Planned Activities:*

*· Collect Feedback*

o Gather, and report, feedback in a transparent manner from customers
(developers, end users, and vendors) on OpenStack with regards to the
state, capabilities, and user experience of the platform.

*· Categorize and Increase Contextual Awareness*

o Provide the data and associated context on themes (and associated use
cases, problem statements) to all stakeholders to ensure focus areas can
be
clearly defined for each release cycle.

*· Prioritization Planning*

o Develop a repeatable, transparent, process for prioritization of
requirements for each release. The criteria for the process along with the
results should be clearly communicated with the community and our
end-customers.

*· Transparent Reporting*

o Increase transparency for the prioritization of consolidated feedback
from customers (developers, end users, and vendors) along with the
resulting plan of intent.

*· Increase Uniformity of Epics and User Stories*

o The team should leverage epics to capture larger stories/requirements
and then convert to (two or more) user stories to break them into
actionable granularity.

*· Aggregation of Requirements*

o This group will collect (and aggregate) user, admin, customer, and
operator requirements. The group should also interface with, and gather
data from, the other existing groups collecting requirements for specific
verticals, markets, or user segments (e.g. Operators, Win The Enterprise,
Personas, NFV/Telco, End Users/App Developers, etc.)

*· Grouping Requirements and Cross Project Communication of
Requirements*

o This group will be analyzing data/requirements received from all of the
sources (developers, end users, operators, and vendors) and establish
grouping of similar requirements into themes. The themes will also have a
recommended break-down of manageable engineering tasks necessary for
meeting the theme criteria which will be communicated across all projects.

*· Multi-release Roadmap*

o Generate multi-release roadmap based on the aggregated data and
resulting themes/requirements. The roadmap will be socialized,
transparently, to community stakeholders for agreement and approval. After
a roadmap has been established/approved, the OpenStack community will be
notified of the results, the drivers for the decision, and its impact over
multiple releases to consumers (and developers) of the platform.
--
Thanks,
Shamail Tahir
Cloud Architect, EMC
t: @ShamailXD
tz: Eastern Time

On Tue, Jan 27, 2015 at 7:58 PM, Stefano Maffulli <stefano at openstack.org<mailto:stefano at openstack.org>>
wrote:

To finalize the conversation we had this morning, we should make an
effort to take the notes from etherpad and consolidate them in the wiki
page. Below is what's in the etherpad, sort of cleaned up:
Mission of this group is to listen and provide help: listen to
contributor's community (PTLs) and listen to customers and
users; help PTLs and contributors resolve issues, help
customers/users be successful by mobilizing underutilized
developer resources.
In details this group:
* [Collect Feedback] Gather, increase detail and context,
prioritize and transparently report customer (developer, end
user, and vendor) feedback about the current
state/capabilities/and use experiences of OpenStack
* [Categorize and increase context] Provide the data and
context so that focus can be better defined for each release of
OpenStack
* [Transparently report] Increase transparency for
prioritization/resolution of consolidated feedback from
stakeholders
* [Transparently and consistently prioritize] Development of
clear and transparently communicated criteria/process for what
gets into what release.
* [Increased uniformity of Epics Use Cases]
* [Providing dual roles: a place that collects all
user/admin/Customer/operator requirements. Breaking it down into
theme and manageable engineering tasks. Generating roadmaps,
theme and getting buy in. And then generating OpenStack
community message to user/admin/Customer/operator/all what
OpenStack is driving over multiple releases over all projects.]
This group should also be responsible for gathering "operator"
requirements along with other types of requirements. We should
understand how to leverage/involved in other existing working
groups, like Operators, WinTheEnterprise, Personas, NFV/Telco,
End Users/App Developers, etc.
I think it's still a bit convoluted and can be refined further before it
goes on the wiki. If you have spare brain cycle left, please share your
thoughts on the list and I'll try to consolidate them in the wiki.
Cheers,
stef
_______________________________________________
Product-wg mailing list
Product-wg at lists.openstack.org<mailto: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<mailto: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<mailto:Product-wg at lists.openstack.org>
http://lists.openstack.org/cgi-bin/mailman/listinfo/product-wg