Standing in the street trying to hear yourself think

Andrew Sayers andrew-ubuntu-devel at
Fri Jul 3 03:44:34 UTC 2009

The Ubuntu community is growing, and as Evan mentioned, our current 
channels of communication can only support a finite rate of messages. 
So there are only two possible solutions: increase the supply of 
meat-bandwidth, or decrease the demand.  Other posts have interesting 
ideas about increasing supply, so I'd like to suggest a way of 
decreasing the demand.  This would involve trying to find "higher-order 
issues" when someone asks a question - the trail of logic that lead them 
(and therefore others) to demand bandwidth in the first place.

As some people might remember, I wrote a survey about noise on the list 
a few months ago.  The response was fairly clear, but didn't demonstrate 
any overwhelming pressure, and my impression was that the list 
coincidentally became less noisy at about the same time.  So I did 
something I rarely do - wrote up my conclusions and shelved them for 
later reference[1].  Those conclusions might be interesting in this 
debate, although they're fairly specific to this list.

Thinking back on the survey, one of the "meta" learning points is that 
most Ubuntu people get far more exercised by specific cases than by 
statistics.  Another example is the way there's always a clamour to 
improve apport, but popcon's significant opportunities seem to be 
provoke a more relaxed attitude amongst would-be beneficiaries.  Though 
we few evidence-zealots keep chipping away, the fact is that getting the 
majority of Ubuntu folk interested in a problem means presenting them 
with an individual they can help.

This suggests a solution I've pulled together from a couple of Joel on 
Software articles[2][3]: when someone comes to you with a problem, first 
fix the presenting problem, then fix the second-order problem that 
caused it, then the third-order problem, and so on back to the original 
source.  Although this significantly increases the amount of work per 
issue, it's more than offset by the reduction in the number of issues.

Here's an example:

An e-mail recently came to the list[4] asking about adding a feature to 
the panel.  This seems to me like an upstream issue, not something for 
the list.

I e-mailed the author suggesting he take the issue up upstream (fixing 
the first-order bug), and politely inquired what lead him here.  He said 
that he'd read the text at [5], which suggested feature requests go to 
ubuntu-devel.  Realising that a non-developer probably shouldn't be 
posting to -devel, he decided to post here.  This suggests two 
second-order bug fixes to me:

* The page at [5] should suggest -devel-discuss rather than -devel
* The page at [5] should talk about filing feature requests upstream

Fixing these second-order issues would shut down a whole category of 
misdirected posts, but we can still look at a third-order bug: people 
don't know where to post messages.  A possible fix would be:

* Create #ubuntu-signpost, a place for people to be pointed in the right 

That would be a fairly easy channel to support, and would reduce the 
amount of noise created by a much wider category of issues.

Fixing the first-, second- and third-order bugs would probably reduce 
traffic to the list by about one post every few months, so I would 
expect it to "pay for itself" in time spent within a year or so.  That's 
not much on its own, but a community-wide effort would soon add up.

So to conclude, my suggestion is that we politely ask people about the 
higher-order issues that lead them to send messages.  These might be bad 
documentation, not enough search, actual program bugs, or any number of 
other things.  Taking extra time to address higher-order issues will 
stop similar issues from occurring again in future, significantly 
reducing demand for bandwidth in the long-run.

Also, I'll be on #ubuntu-signpost later if anyone wants to join me, but 
right now it's way past my bedtime :)

	- Andrew


    (section 1, "fix everything two ways")




More information about the Ubuntu-devel-discuss mailing list