Debian teams survey results
From: | Steve McIntyre <leader-AT-debian.org> | |
To: | debian-devel-announce-AT-lists.debian.org | |
Subject: | DPL teams survey summary summary | |
Date: | Sun, 29 Jun 2008 16:20:00 +0100 | |
Message-ID: | <20080629152000.GC27034@einval.com> |
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>
Posted Jul 1, 2008 13:09 UTC (Tue)
by dulles (guest, #45450)
[Link] (5 responses)
Posted Jul 1, 2008 14:05 UTC (Tue)
by Los__D (guest, #15263)
[Link] (4 responses)
Posted Jul 1, 2008 16:22 UTC (Tue)
by nix (subscriber, #2304)
[Link]
Posted Jul 1, 2008 18:59 UTC (Tue)
by dmadsen (guest, #14859)
[Link] (2 responses)
Posted Jul 1, 2008 19:17 UTC (Tue)
by Los__D (guest, #15263)
[Link] (1 responses)
Posted Jul 2, 2008 18:01 UTC (Wed)
by dmadsen (guest, #14859)
[Link]
REAL LINUX FEEDBACK?
I'm amazed, but this Debian dude is actually seeking Linux feedback. It's not common in the
Linux world to request feedback. As we all know, it's usually "Join the mailing list" or "Stop
criticizing us". I quit reporting bugs to Linux projects (like Mozilla), because the
developers are so dumb. It's a step forward for Linux people to admit that Linux is a broken
mess, and work work towards the future. One of the basics of Software Engineering is called
"feedback".
REAL LINUX FEEDBACK?
Bla bla bla bla bla... You really don't have anything better to do than troll, eh?
REAL LINUX FEEDBACK?
His one example (Mozilla) isn't really a Linux project anyway. It's more a portable free
software project focused on Windows these days. (One sign of this is how hard the damn thing's
become to build, because virtually everyone other than core developers just uses binaries.
e.g. many extensions compiled by default in the Firefox 3 source tree simply don't. Compile,
that is. Makefile bugs, mostly...)
REAL LINUX FEEDBACK?
Let's give the original commenter some slack and assume that he's not trolling, but has had
some bad experience in the past.
In that case, your response will not be helpful.
Apparently, in the past, he's tried to report bugs. Most people don't even do that much.
Perhaps he's tried interacting with the community and has been rebuffed. It's happened to me,
certainly, and I felt the same way as he does. It does no good for a project to solicit input
and then rudely treat those who are willing to do so in good faith.
Being a developer does NOT give anyone right to look down upon anyone else. And much of the
Linux community does just that in their written communications. The implicit attitude seems
to be "if you want to play with the big boys, you gotta be special; until then go away, little
boy".
I've been a developer for MANY years, and I've learned (the hard way) that you are NEVER rude
to your end users -- the user that you discourage from submitting bugs could very well have
been the one who would have sent you the "missing link" that you're looking for to fix an
elusive bug. For me, more than once, it's been one of those "dumbest", "most exasperating"
users that have brought me the gold. It's always made me feel stoopid.
If you can't find a way to handle duplicate or spurious bug reports; handle users of opposite
temperament then yours; handle very negative feedback; deal with a zillion
postings/e-mail/phone calls about your project, well, then, you're doing something wrong.
It's not your users' fault, it's a management problem. And if you're the management, it's YOUR
problem.
If you support free software, you are an ambassador for it. Unless you're RMS, being nice
will get you heard more than if you're not. And naysayers will point to rude comments and
say, "See, they're all like that!". Contrariwise, *even if he was trolling*, a positive
response will reflect well.
Studies done in the past (late '80s, early '90s IIRC) indicate that there are lots of people
who are decent in person but easily prone to being rude in writing. If you are one of those
people, for the good of any project you are with, may I suggest you learn to control that
because your writing may be your only "face" that many people [ever] see.
REAL LINUX FEEDBACK?
You obviously haven't seen his comments on LWN...
Here's a few to check out:
http://lwn.net/Articles/278088/
http://lwn.net/Articles/241431/
http://lwn.net/Articles/278190/
He IS just a troll.
Now, let's stop feeding him. (And I apologize for starting this)
REAL LINUX FEEDBACK?
Saw the links, read the writing.
My bad. Sorry!
---dcm