Jump to: navigation, search

Difference between revisions of "ProductTeam"

(Mission)
(Mission)
Line 3: Line 3:
 
== Mission ==  
 
== Mission ==  
  
The Product working group is made of managers, people, functions, groups that own "products" based on OpenStack who aim to **improve the quality of the delivery process, the delivered product, and the product experience for operators and end users**.  
+
To listen, and aggregate, feedback on the desired capabilities for the
 
+
OpenStack platform from multiple key sources including the contributor
Members of the Product working group have a high-level view of the ecosystem and can dig into the details enough to point out where the individual components need development focus. Therefore this group has a privileged position from which it can:
+
community (PTLs), customers, and users. The group will also aim to help
 
+
PTLs and contributors resolve issues that are either of strategic
* provide prioritization of specs and blueprints based on customer demand, along with creating specs at a high level to address what the customers' biggest pain points or short horizon issues are.
+
importance or have broad implications across a multitude of services.
* provide valuable feedback during the bug triage cycle, explaining why any specific bug was more or less critical to other community members.
+
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 ==
 
== Objectives ==

Revision as of 09:15, 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

Objective of this working group is therefore to:

  • review new bugs and provide feedback in the triage phase
  • participate actively during the specs review process
  • 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

FIXME: what's the output of this?

  • get weekly reports from launchpad of 'new' bugs to be triaged?
  • Produce a list of prioritized specs to submit to PTLs?
  • Advocate material for corporations, internal training ?

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