[openstack-dev] Havana roadmap?

Joshua Harlow harlowja at yahoo-inc.com
Fri Apr 12 16:17:44 UTC 2013

Starting to see the light. (I think)

I agree with u robert after further thinking about this. I guess there is a mix of directing and facilitating and leading that is likely the best ptl and finding that mix isn't easy. Especially in open source projects with various "forces" tugging it in different directions. I guess it's somewhat like rodeo bull riding, haha.

Sent from my really tiny device...

On Apr 12, 2013, at 1:00 AM, "Robert Collins" <robertc at robertcollins.net> wrote:

> On 12 April 2013 19:11, Joshua Harlow <harlowja at yahoo-inc.com> wrote:
>> Interesting view,
>> I was thinking that most companies and groups of people, even in open source like to have leadership which clearly knows where they want to "sail the ship" for the next six+ months. And said direction should be something concrete and simple (aka fits in one or 2 sentences). Doesn't that seem like a good thing to have?
> I think that confuses a tool for the actual leadership. Just about
> everyone has strong ideas about what they want to see happen. The job
> of a [technical] leader is to help the project make the most out of
> all the energy folk are offering the project. For instance, help
> everyone that is driving in their own particular direction do so
> harmoniously, or identify and remove roadbloacks. For instance, one
> group of folk might want to see much better nova DB queries, another
> might want to see nova become more maintainable, and a third may be
> hell-bent on new features. It's the leaders job to help them all fit
> together even when the directions they are pulling in are somewhat (or
> even very) incompatible.
> One technique that can be used to do that is to have a clear vision -
> which might be years long - and help folk map their personal desires
> into the framework of that vision.
> Another technique is to identify practices and processes which are
> holding the project back and get discussion going on them.
>> Like for example.
>> "During my term I will try to make nova more stable and reliable."
>> Now that goal is at a high enough level that it can be tolerant to developers failing to actually submit any work (to some level) but it is also somewhat measurable so that after 6 months is up people can ask themselves if nova is really anymore stable and if not then maybe said person is not a good project leader. It always acts as a steering force for which types of blueprints people will submit and so on...
>> How else do people measure whether a  project leader is doing good or bad without this kind of initial goal and evaluation?
> You measure the project as a whole against the values you want it to
> live up to. For instance, stability and reliability, performance,
> changes in contributor numbers, quality, user perception.
> When I was technical architect for Launchpad, I write a bunch of code
> - cool. But I had more impact from various quite small things I
> organised - one was to start systematically reducing the timeout
> permitted on slow code, forming a ratchet to prevent backsliding of
> pages which had had their performance fixed. Another I sponsored a
> project to do parallel testing which took a 6 hour landing time down
> to ~45 minutes. A third thing was to change from monthly deploys to
> daily (which got the project on the path to continuous deployment -
> and they can now deploy multiple times a day). The point of relating
> these things isn't to blow my own horn - it is that *all* of these
> things had broad support from the project members, even though what
> they personally were working on was often tangential, or even in
> tension with it.
> Trying to get hundreds of developers working on the same thing will
> just lead to lots of conflicts in patches, and is a poor way to
> capture the energy of all the folk who come to the project with their
> own agenda.
> There is no harm in saying 'I think X is very important and I will
> happily coordinate work on making it better', but you need to
> recognise that a leader is a facilitator not a director.
> -Rob
> -- 
> Robert Collins <rbtcollins at hp.com>
> Distinguished Technologist
> HP Cloud Services
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

More information about the OpenStack-dev mailing list