> As you all know, there has recently been several very active discussions > around how to improve assorted aspects of our development process. One idea > that was brought up is to come up with a list of cycle goals/project > priorities for Kilo [0]. > > To that end, I would like to propose an exercise as discussed in the TC > meeting yesterday [1]: > Have anyone interested (especially TC members) come up with a list of what > they think the project wide Kilo cycle goals should be and post them on this > thread ...
Here's my list of high-level cycle goals, for consideration ... 1. Address our usability debts With some justification, we've been saddled with the perception of not caring enough about the plight of users and operators. The frustrating thing is that much of this is very fixable, *if* we take time out from the headlong rush to add features. Achievable things like documentation completeness, API consistency, CLI intuitiveness, logging standardization, would all go a long way here. These things are of course all not beyond the wit of man, but we need to take the time out to actually do them. This may involve a milestone, or even longer, where we accept that the rate of feature addition will be deliberately slowed down. 2. Address the drags on our development velocity Despite the Trojan efforts of the QA team, the periodic brownouts in the gate are having a serious impact on our velocity. Over the past few cycles, we've seen the turnaround time for patch check/ verification spike up unacceptably long multiple times, mostly around the milestones. Whatever we can do to smoothen out these spikes, whether it be moving much of the Tempest coverage into the project trees, or switching focus onto post-merge verification as suggested by Sean on this thread, or even considering some more left-field approaches such as staggered milestones, we need to grasp this nettle as a matter of urgency. Further back in the pipeline, the effort required to actually get something shepherded through review is steadily growing. To the point that we need to consider some radical approaches that retain the best of our self-organizing model, while setting more reasonable & reliable expectations for patch authors, and making it more likely that narrow domain expertise is available to review their contributions in timely way. For the larger projects, this is likely to mean something different (along the lines of splits or sub-domains) than it does for the smaller projects. 3. Address the long-running "what's in and what's out" questions The way some of the discussions about integration and incubation played out this cycle have made me sad. Not all of these discussions have been fully supported by the facts on the ground IMO. And not all of the issues that have been held up as justifications for whatever course of exclusion or inclusion would IMO actually be solved in that way. I think we need to move the discussion around a new concept of layering, or redefining what it means to be "in the tent", to a more constructive and collaborative place than heretofore. 4. Address the fuzziness in cross-service interactions In a semi-organic way, we've gone and built ourselves a big ol' service-oriented architecture. But without necessarily always following the strong contracts, loose coupling, discoverability, and autonomy that a SOA approach implies. We need to take the time to go back and pay down some of the debt that has accreted over multiple cycles around these these cross-service interactions. The most pressing of these would include finally biting the bullet on the oft-proposed but never delivered-upon notion of stabilizing notifications behind a well-defined contract. Also, the more recently advocated notions of moving away from coarse-grained versioning of the inter-service APIs, and supporting better introspection and discovery of capabilities. > by end of day Wednesday, September 10th. Oh, yeah, and impose fewer arbitrary deadlines ;) Cheers, Eoghan > After which time we can > begin discussing the results. > The goal of this exercise is to help us see if our individual world views > align with the greater community, and to get the ball rolling on a larger > discussion of where as a project we should be focusing more time. > > > best, > Joe Gordon > > [0] > http://lists.openstack.org/pipermail/openstack-dev/2014-August/041929.html > [1] > http://eavesdrop.openstack.org/meetings/tc/2014/tc.2014-09-02-20.04.log.html > > _______________________________________________ > OpenStack-dev mailing list > OpenStack-dev@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > _______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev