Jump to: navigation, search

Difference between revisions of "ProductTeam"

(Mission)
(Objectives)
Line 14: Line 14:
 
== Objectives ==
 
== Objectives ==
  
Objective of this working group is therefore to:
+
The objectives of this working group, based on the mission, are therefore to:
  
* '''review new bugs and provide feedback in the triage phase'''
+
*'''Collect Feedback'''
* '''participate actively during the specs review process'''
+
: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.
* '''provide an ecosystem view of the the current release and maybe even roadmaps''', so everyone knows what is planned to be delivered by the OpenStack organization in the next release, and highlight cross project dependencies that can be tracked to raise flags when one of the critical path items gets bogged down.
 
* '''align contributor working cadences with OpenStack release cadences''': having contributors available to work whole cycles, instead of contributing code and leaving before RC is complete will increase the chances that a contribution made early in a cycle won't be pulled if critical issues are found late in the cycle.
 
* '''advocate at their corporate level an allowance of time for each OpenStack contributor committed to a project to learn OpenStack''' deeply, through code reviews, and across projects, through exploration. Having a better understanding of OpenStack will allow them to write higher quality, more sustainable code for you and the project. Also, advocate dedication of more reviewing resources. OpenStack projects are review-driven. Every contribution must be reviewed, several times, before it is accepted. The small groups of core reviewers are operating above a sustainable capacity already, and want to train new members up to core level. We need skilled developers to be given time to gain the trust of the core teams by performing reviews on existing projects.  Contributing code should be an equal, or even secondary, priority to reviewing for anyone who needs to get anything done at all.
 
  
=== Output of this group ===
+
*'''Categorize and Increase Contextual Awareness'''
 +
: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.
  
FIXME: what's the output of this?
+
*'''Prioritization Planning'''
 +
: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.
  
* get weekly reports from launchpad of 'new' bugs to be triaged?
+
*'''Transparent Reporting'''
* Produce a list of prioritized specs to submit to PTLs?
+
:Increase transparency for the prioritization of consolidated feedback from customers (developers, end users, and vendors) along with the resulting plan of intent.
* Advocate material for corporations, internal training ?
+
 
 +
*'''Increase Uniformity of Epics and User Stories'''
 +
: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'''
 +
: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'''
 +
: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'''
 +
: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.
 +
 
 +
=== Outputs of this group ===
 +
 
 +
The initial outputs of the team are to define various processes and, most importantly, to listen to the PTLs and document their current roadmaps and thoughts.
 +
 
 +
The team is currently focused on three outputs:<br>
 +
1) '''Socialization''':  Gathering feedback from PTLs and documenting the results<br>
 +
2) '''Roadmap Definition''': Creating the process that can be used to eventually define the roadmap<br>
 +
3) '''Roadmap Communication''':  Creating the process for cross-project communication of the roadmap and making it transparent
  
 
== Mailing list ==
 
== Mailing list ==

Revision as of 09:35, 10 February 2015

OpenStack Product Working Group

Mission

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.

Objectives

The objectives of this working group, based on the mission, are therefore to:

  • Collect Feedback
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
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
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
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
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
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
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
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.

Outputs of this group

The initial outputs of the team are to define various processes and, most importantly, to listen to the PTLs and document their current roadmaps and thoughts.

The team is currently focused on three outputs:
1) Socialization: Gathering feedback from PTLs and documenting the results
2) Roadmap Definition: Creating the process that can be used to eventually define the roadmap
3) Roadmap Communication: Creating the process for cross-project communication of the roadmap and making it transparent

Mailing list

It's good practice to send a brief personal introduction when signing up.

Meeting notes

2014-09- https://etherpad.openstack.org/p/paris-product-meeting