My thoughts on bzr sub-teams
ian.clatworthy at canonical.com
Thu Nov 26 07:25:04 GMT 2009
I recently raised the idea of creating a bzr-l10n team. Here's my bigger
picture view on why I'm keen on sub-teams.
Having spent over a decade as a technical manager before I saw the light
and went back to hacking 3 years ago, I can genuinely say that ...
"Great leaders make room for others to succeed."
It sounds terribly corny but it's true. You'll never climb up the
management chain or move onto more interesting projects if you make
yourself indispensable in your current role. :-) It takes longer but
mentoring others rather than doing everything yourself ends up being a
big win for all involved. Before 2.0 was released, the core *had* to
focus on the deep engineering changes we were doing. I think the time
has now arrived for the core to put a higher emphasis on enabling others
to contribute rather than trying to cover as many bases as we do. We've
made great strides along that road already in recent weeks. Sub-teams is
another step along that path IMO.
We have an immense amount of talent in the Bazaar community and in our
potential community. We need to ask ourselves how we best make space for
that talent to shine. Speaking personally, I don't believe "one large
team" is the best way to scale. It's too easy for the core people in
that team to become a bottleneck and for others to leave most things for
them to solve. It's also harder for non-fulltime contributors to keep up
with every discussion or to feel closely connected with like-minded peers.
In coming months, I'd like to see us grow several sub-teams. There are
pitfalls undoubtedly. In particular, we don't want to partition along
the wrong boundaries or over-partition. We'll need some guidelines about
communication too. I think we're clever enough to address those issues.
The really important thing IMO is that these are *teams*, not just
discussion forums, i.e. they have responsibility for something concrete
and work together to improve it. At a given point in time, each team
should have a "leader" who ensures releases get made when they need to.
In fact, I think a leadership pair works best so one person can drive
things forward when the other person is away or snowed under with other
commitments. QBzr is a shining example of a *great* team. Alexander and
Gary help each other keep the ball rolling and getting releases out in
time. Lukas (the original developer IIUIC) provides wisdom and helps
when he can. Several others pitch in here and there. It's not large in
size but QBzr makes great progress month after month.
Here are my suggested bzr sub-teams:
* bzr - responsible for core bzr and overall coordination
* bzr-windows - responsible for the Windows installer
* bzr-mac - responsible for the OS X bundles
* udd - responsibility for Ubuntu Distributed Development
(includes imports, deb packaging, meta-projects, patch mgmt, etc.)
* bzr-doc - responsible for our documentation
* bzr-l10n - responsible for translations, both GUIs and doc
* bzr-qa - responsible for confirming and prioritising bugs and
testing (including writing tests for bugs, benchmarking, etc.)
* bzr-integration - responsible for bzr integrations as a whole, i.e.
client-side (file managers, editors, IDEs) and server-side (bug
trackers, CI tools, web servers, etc.)
We're part of the way there already. Here are the some things we could
* A leader or two for the bzr-windows team. This team should take
ownership of the Windows installer so John doesn't need to do it.
* A leader or two for the bzr-mac team so bundles get made for each
OS X platform each release. Individuals there are doing great work
but someone needs to "own" consistent releases and a roadmap for
evolving the bundles further.
* Ditch the old IDE-integration team (which went no-where) in favour of
a more broadly scoped one. (I can imagine plenty of developers in
*other* communities who would never join our main list but who would
benefit from being connected with other developers who also own
* We could subscribe the bzr-core team to each sub-team as it was
created so members of core would remain across most conversations.
Does this sound like a sound strategy? In particular, I'd like to know
if there are non-core people out there who would be interested in taking
on the leadership positions I described either in existing teams or
suggested teams, assuming we agreed to form them.
Maybe I'd dreaming but I see plenty of amazing people out there who have
the ability to accelerate Bazaar. Could you contribute more if we gave
your more structure as outlined above? Just think of all those speed
improvements John could make if he wasn't building Windows installers,
code improvements Martin could make if he wasn't triaging bugs, etc!
More information about the bazaar