My thoughts on bzr sub-teams

[Martin Pool]

2009/11/26 Ian Clatworthy <ian.clatworthy at canonical.com>:
> 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.

It's been clear recently that subteams can be a really powerful tool
to give people a easier way to do what they want to do.  (I was going
to say "to contribute", but that's almost a selfish way to look at it
- the point is that they already want to have things happen, but some
things make it more welcoming than others.)

In particular if someone wants to say improve the documentation or
build packages or improve the help text there should be as few
barriers as possible in the way to that, recognizing both technical
and social things, and that a full-on developer mailing list may seem
like a social barrier in itself.

Launchpad Translations developers say their goal is: the only
precondition to do translations is to know English and one other
language.  It's a nice way to put it and we should aim for something
similar.

> 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!

It's interesting you use the example of bug triage because in some
recent conversations it there seems to be a consensus that though it
would be nice to make sure all bugs get a severity and either
confirmed or rejected, it's not actually a good use of core developer
time to prioritize them.  However, this is something that many other
people could do, if they wanted to, if they got some experience and
knowledge about it, and most importantly if they felt they really had
permission to do it and permission to make mistakes.  I suspect the
last factor is the biggest, and understandably - I would hesitate to
jump into Ubuntu's bug database and start triaging them.  But I would
certainly trust over a dozen people here to triage our bugs - after
all, it's easy to change them if one disagrees.

I don't know if creating a bzr-qa team directly addresses that - I
think there is a real risk of fragmentation, that leadership will be
spread thin, or that the teams will just fail to thrive.  But perhaps
creating a team is a really good way to signal that people in it have
permission/encouragement/responsibility to do these things, and that
it's easy to get there.

-- 
Martin <http://launchpad.net/~mbp/>