Open Stack

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