Open Stack

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

> 
> 
> -----Original Message-----
> From: Doug Hellmann [mailto:doug at doughellmann.com] 
> Sent: Wednesday, December 10, 2014 2:57 PM
> To: product-wg at lists.openstack.org
> Subject: Re: [Product] An "Operations Project" and the questions it raises.
> 
> 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:
> 
> [Rockyg]  One area pro[d|j]ect managers provide value is during the bug triage cycle.  If there were a time for discussion (weekly meeting agenda item?), an interested party could provide their input as to why any specific bug was more or less critical to other community members.  They also might be able to tie it to issues in other projects.  Also could be useful on importance of back porting.

It would be great to have that sort of input through comments left directly on the bugs so there is a record of the information.

> 
> * 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.*
> 
> [Rockyg]  I Understand lack of resources, but having others provide prioritization might highlight how important or timely a feature is, and also highlight that there are no resources on an important feature, which might get these people focusing on adding resources. It is also possible that if someone considered an unstaffed or lightly staffed feature to be of high importance, enough resources could be put against that to free others to work on features they felt matched their talents better.  Also, perhaps this is a perfect place where adding senior developers as reviewers of specs and/or code, even if they can't spare developers might be an added incentive for a developer to take on the task.

At least in Oslo we tend not to have feature definitions without developers. We assume that if you’re writing the spec, you’re signing up for the implementation work, too. In fact, part of the spec is the list of people who are committing to doing the work so we know who to talk to about it. So having some input about desirable features is good, but I don’t know the best way to communicate that. Maybe we should use blueprints, since a blueprint is much simpler to create.

> 
> 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.
> 
> [Rockyg] Agreed.  But, I think that we also need to ensure the proper tests are part of the contribution and other contributions that interface with it so that issues are found before merge or shortly thereafter.

Yes, that’s largely up to the review team to enforce. The cases I’m thinking of in the past had to do with features that couldn’t be tested in the gate because they needed services not available there (like ceph or some other external system). Obviously the level we can test a feature varies based on what the feature is, but it’s definitely something we try to include in reviews.

> 
> 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.
> 
> [Rockyg] Agreed. We have to make sure the resources are up to speed if we commit them to a development 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.
> 
> [Rockyg] Also agreed.  With a team I mentored, the team was instructed to start contributing by writing tests (API to learn the flow and interfaces), performing reviews (at least one a day), and fixing and/or finding bugs. I tried to encourage the developers to provide 5 reviews for every gerrit submit/amend they did. But, that's my team and info gleaned from the mailing lists to come up with the suggested levels. We as "managers" of whatever sort should be able to better socialize what corporate participate should be and might actually have a better chance of getting the proper commitments when the managers' group is doing the shaming/praising.  It's really hard for a developer to get a busy manager to hear him when he says he can't get reviews because he isn't allotted time in his schedule to do them for others' code. 

Yep, good point.

> 
> All of the above allow for more meaningful contribution from resources committed to making OpenStack better.
> 
> [Rockyg] These are all important aspects and issues the pm group needs to consider and come up with ways to address these issues to better deliver what our customers need.
> 
> --Rocky 
> 
> 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
> 
> 
> _______________________________________________
> Product-wg mailing list
> Product-wg at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/product-wg