Open Stack

On 12/09/2014 05:49 PM, Stefano Maffulli wrote:
> Sounds better than the one we have. Do others want to chime in and
> iterate?

I iterated based on the comments received on the list and updated the
wiki page. Here is what I put in there. Feel free to edit the wiki page
directly https://wiki.openstack.org/wiki/ProductTeam


    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**.

Members or 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:

  * 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.
  * provide valuable feedback during the bug triage cycle, explaining
    why any specific bug was more or less critical to other community
    members.


    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 ?