Open Stack

As a PTL, I can offer some insight into how my team and I set priorities for Oslo (I can't really speak for the other projects).

Bugs are prioritized according to some general heuristics:

 * Bug reports submitted by users in production systems are prioritzed over bugs just reported in our CI system.
 * If a user-reported bug is seen on an release more than 1 cycle old, it likely will not be prioritized unless it is repeatable or also reported on a newer release.
 * Bugs that are triggered frequently in the CI system are also given high priority, since they have a direct impact on all of the other contributors.
 
Feature requests are treated a little differently. 

Feature requests, as they relate to specs, are prioritized based on:

 * alignment of the spec with basic architectural and technical underpinnings of the project
 * how widely useful and applicable the feature is, as presented by the spec author
 * having resources available and willing to execute on the spec
 * consistent availability of resources to continue to implement the spec
 * consistent and continuous consensus on implementation plan for the spec among core project members

*Having a list of prioritized features, but no resources contributing meaningfully to implement them, isn't helpful.*

There are a few things I, as a PTL and TC member, would love to see from this group:

1) Alignment of contributor working cadences with OpenStack release cadences. Having them 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.

2) An allowance of time for each OpenStack contributor committed to a project to learn (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.

3) The 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.
    
All of the above allow for more meaningful contribution from resources committed to making OpenStack better.

Doug

On Dec 10, 2014, at 2:57 PM, Rochelle Grober <rochelle.grober at huawei.com> wrote:

> I think one of the most important things we bring to the table is the melding of the technologies and the needs of the customers.  Developers have all sorts of great ideas for adding features and improving the existing ones, but they don't know how many customers need or want that particular feature or improvement.  We 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.
> 
> We can also look at the velocity of development and project possible roadmaps for getting features and improvements in, beyond the single cycle, or single cycle plus fudge.
> 
> We can also 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 even better, highlight cross project dependencies that can be tracked to raise flags when one of the critical path items gets bogged down.
> 
> I think our greatest strength is being able to view the ecosystem from a high level and dig into the details enough to point out where the individual components need development focus.
> 
> --Rocky
> 
> -----Original Message-----
> From: Roland Chan [mailto:roland at aptira.com] 
> Sent: Wednesday, December 10, 2014 3:29 AM
> To: product-wg at lists.openstack.org
> Subject: Re: [Product] An "Operations Project" and the questions it raises.
> 
> I think we produce guidance on how to make stuff better or influence how
> stuff is improved.
> 
> Ultimately what matters most is customer satisfaction. We can't frame that
> purely in terms of feature delivery rates although getting the right
> features to the customer is very important. Features have to be delivered
> to a prioritised schedule, but also they have to work as advertised, they
> can't break other stuff and they have to be deployable.
> 
> Probably more stuff too, so feel free to add to the list, but try to remain
> at a high level otherwise we'll get lost in the solution before we've
> finished requirements.
> 
> Roland
> On 10 Dec 2014 12:50, "Stefano Maffulli" <stefano at openstack.org> wrote:
> 
>> On 12/07/2014 11:38 PM, Roland Chan wrote:
>>> Stefano's points on coordination and prioritisation are the tactical part
>>> of product management. It's the strategic part that concerns me: what are
>>> we going to do to improve OpenStack as a product (which is a lot more
>> than
>>> shipping the latest release) in a changing environment?
>> 
>> I always thought of this group as a tactics-focused one since the
>> strategy for OpenStack is done at TC and Board level but re-reading your
>> message though I think I can be convinced of the contrary: what do other
>> people think?
>> 
>>> I would go with something like:
>>> 
>>> 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. We do this by coordinating our actions,
>> advocating
>>> on behalf of our customers for improvements in all areas of the OpenStack
>>> community's activity and continuously measuring our progress.
>> 
>> Sounds better than the one we have. Do others want to chime in and iterate?
>> 
>>> What we measure is an interesting question.
>> 
>> How about we start talking about what we produce and go from there? Are
>> we going to produce something like a list of what this groups considers
>> top priority blueprints/specs? Something else?
>> 
>> /stef
>> 
>> _______________________________________________
>> Product-wg mailing list
>> 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
> http://lists.openstack.org/cgi-bin/mailman/listinfo/product-wg
> 
> _______________________________________________
> Product-wg mailing list
> Product-wg at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/product-wg