[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

DPL teams survey summary summary



Hey folks,

As you may remember, back before I started the DPL job I promised to
run a survey. Then I pestered a huge number of people to answer a set
of questions and get back to me. I've taken longer than I hoped to
read through all those responses and summarise them, but finally I'm
done. As I said at the time, I'm *not* going to go into great gory
detail about individuals or specific teams here and now. Many of the
surveys include personal information and I promised to protect
that. Instead, this is just a summary of the results. I'll be
following up in more detail with various of the teams in the coming
weeks. If you have any questions in the meantime, please feel free to
contact me.

So, enough of the disclaimers... :-)

The raw numbers
===============

I sent out 75 mails containing survey questions[1] at the end of
April. The initial (announced) deadline was the 25th of May, but I
always planned to accept late submissions (within reason). When I sent
out an update [2] earlier this month, predictably that prompted more
answers. The latest response landed in my inbox on the 20th of
June. In total, 116 people got back to me with information and all of
those (modulo a couple of bounces) should by now have received
individual thank you messages from me. I'll echo that again here anyway
- thanks very much to the people who spent their valuable time giving
me the data I asked for.

It's common for people to be in multiple teams; 15 people identified
themselves as belonging to 4 or more teams, and a couple said they
were in 10 or more teams. But still the majority of people responding
listed one team only.

In all from the responses, 77 teams were listed.

Highlights
==========

As I hoped to find, the vast majority of the respondents said they
were having fun working on Debian. That's not unexpected, but it's
nice to confirm this. A few people responded to say "I have fun doing
Debian work, but would have even more fun doing it if I had more
time." Quite a number said they're enjoying working with friends,
doing cool technical stuff but are less happy about our mailing lists
and IRC channels when they devolve into flamewars.

Most respondents believe that their teams are working
well. Apparently, just about *every* team could do with more people to
help with their tasks, but again that's not a great surprise. :-)

Some teams are working very well, by all accounts. As an example: I
received a huge number of responses from the Perl team, all of them
very positive. The group seem to be getting on astoundingly well,
supporting hundreds of packages between them. Communications are good,
and there are enough people to cover bug reports and new package
versions. Woo!

The i18n and l10n groups tend to be quite informally organised, but
(with a small number of exceptions) are mostly working well. There's a
small (and funny) contradiction in the responses here: Christian
Perrier told me that the team needs some stronger leadership and he
doesn't think he's good at organising things. Most of the other people
in this area said that they loved Christian and his efforts in
organisation. *grin*

More and more teams are springing up spontaneously over time, mainly
covering groups of packages. This is aiding developers to work
together on related work, plus it's a great way for new developers to
join in and learn more about Debian.

Lowlights
=========

I received no responses at all from a small number of the teams. These
include a couple of the role addresses listed on our organisation page
[3]. I'm going to try and fix those quickly, and I'll be checking up
on the rest of these teams ASAP.

Many of our longest-standing developers are overworked. Most of them
are still having fun, but not all. Almost all of them are struggling
to find the time to do the jobs they want to do, and it's clear that
in some cases they feel guilty because of this.

It won't come as a big surprise that the porter teams working on
several of our architectures are short of manpower. Some are thriving
and working well, but it seems that we have a real problem finding
skilled people with enthusiasm to work on some of the more exotic
types of machine. In stark contrast to that, I received a large number
of reports from the m68k porters; they may be working on old, slow
hardware but they're still passionate about making it work.

Communication between some of our teams is less than ideal, ranging
from bad to non-existent. There are many reasons for this: personality
conflicts, lack of time, conflicting goals and ideas and
more. Communications inside some of the teams can be just as bad -
I've heard of places where the only communications between team
members come via comments in VCS reverts.

Some of our teams struggle for leadership. It can be all too easy for
people to leave tasks for "somebody else" to do, but "somebody else"
never picks them up. Some teams may be working just fine on the
day-to-day tasks that come up, but either never consider the bigger
issues or get too bogged down in discussions and disagreements about
how to solve those issues such that they never get started.

Expected results
================

Almost all the respondents said that their teams could use more
people. Not a shock... :-) Some teams are *really* short of people for
important core jobs and could do with help to find more.

Several core teams have had problems with communications. That was
already expected up-front, and was one of the reasons why I initiated
this review. Personnel changes have happened in various of those teams
already, and it seems that they have made quite a difference in a
short time. More work is still needed here yet, as more teams are
still having problems.

Quite clearly, many of our developers are over-committed. That's not
uncommon at all in a volunteer project - it goes with the
territory. It's also clear that quite a few people have not (until
now) actually taken stock of all the jobs they have promised to
do. Maybe I've just caused some of them to be scared now. :-)

I now have a much more complete picture of how our teams are
working. I had my own ideas beforehand, but in a lot of cases all I
had to go on was second-hand stories and rumours. There's now a lot
more information for me to use when talking to some of the teams in
the upcoming weeks, and that will be very helpful.

In return for the promise of privacy / anonymity in the surveys, I
have had some refreshingly honest answers from many people. This does,
unfortunately, mean that I can't really publish much of the data I've
gained, but that's a price worth paying. By explicitly asking for
responses to be sent to leader@ rather than to me directly, at least
most of the data will be archived for future DPLs to see. If that's
not something you expected for your survey response and you'd like it
to be un-archived, please contact me privately.

Unexpected news
===============

I wasn't aware of just how badly some of our teams were
performing. Quite a few are barely functional at all. In more than one
case, I had responses like "team? what team?". Several are technically
made up of a group of people, but only one person is doing all the
work. Other teams are in worse positions of stagnation or even
out-and-out conflict. There are not many teams in these states, but
having any at all is bad.

Many of our developers are used to strong discussions and technical
arguments in the course of Debian and Free Software development, but I
was *shocked* to hear that one of our community has been the target of
death threats as a thank you for her work. I'm horrified to hear about
such a nasty thing happening; please let me know ASAP if any such
thing happens again in the future and I'll do my level best to help
track down and deal with the perpetrators.

Where to go from here
=====================

There are a few things I can do here, and a lot more that I'd like to
encourage others to do or to help with.

1. As I've mentioned above, there are several places where urgent work
   is needed to try and rescue teams/tasks that are failing. I'll be
   talking to those folks as soon as possible. I'm not naming names
   here just yet, as I don't want to just add even more pressure to
   already-stressful situations.

2. On the flip side of that, I'd also like to ask the members of the
   teams that are acknowledged to perform well to help us with ideas
   for good practices to follow. Obviously, some working methods may
   not transfer well from team to team as they face different
   problems. But it's also clear that some methods *will* work well in
   a wider context, and it would be nice to see them tried.

3. Being busy is not itself a problem, but being *too* busy (such that
   tasks are left undone and other people are blocked) does cause
   trouble. To fix it, we need to spread the load and re-prioritise
   work, admitting that we need help on some of our tasks. We all need
   to look at our own work and time commitments and honestly evaluate
   whether or not we can do all that we've promised. Over-work doesn't
   work in the long run.

4. Several teams desperately need more help. Firstly I'd suggest that
   they should try to find more help themselves. Blog posts on Planet,
   or mails to debian-devel, or "bits from" mails to d-d-a are a good
   way to pick up more interested people. If those really don't help,
   then we can maybe find more ways.

5. Face-to-face meetings have been a great help for various teams over
   the last few years, at FOSDEM, Debconf, Extremadura and
   elsewhere. If you think that your team(s) would benefit from
   getting together like this, then get organising!

6. I found that people from quite a number of teams responded to the
   survey, despite not being on my initial target list. That's not a
   surprise! However, a more comprehensive, canonical single list of
   teams would be very nice to have. Currently there are multiple
   incomplete team lists scattered all over the place; that's not very
   useful.

7. Be more verbose about what we're doing. The more that people talk
   about the good work that's going on all over the project, the more
   we'll encourage existing and new developers to join in and help
   us. Equally, if there's something particularly problematic that
   you've found is blocking you, tell the rest of us about it.

8. Publicise more clearly the places where new people could help
   out. I'm commonly asked by people how they could get involved in
   Debian, or what tasks most urgently need help, and those are quite
   difficult things to answer. A more focussed set of web pages and/or
   wiki pages targeting these questions would be a great thing to
   have.

There's a whole load more ideas people have suggested to me beyond
these, some quite obvious and easy to implement and some much less
so. I've also got quite a few people to come back to and talk to some
more about various other topics they raised in their survey
responses. It's been a busy few weeks, and there's no sign of that
changing much soon... *grin*

Thanks for bearing with me so far.

[1] http://people.debian.org/~93sam/teams_review.txt
[2] http://lists.debian.org/debian-project/2008/06/msg00045.html
[3] http://www.debian.org/intro/organization

-- 
Steve McIntyre, Debian Project Leader <leader@debian.org>

Attachment: signature.asc
Description: Digital signature


Reply to: