Doing something about signal:noise complaints

[Emmet Hikory]

Andrew Sayers wrote:
> Ubuntu developers tend to complain about the ratio of signal to noise on
> this list - that is, the percentage of posts that take up their time
> without helping them to improve Ubuntu.

    There have been a few incidents of threads-that-would-not-die,
unbounded criticism, threats to stop using Ubuntu or other such traffic
that probably cause a significant portion of this perception.  I'd say
that the majority of threads are of at least limited interest.  The
description of the list topics (1) outlines a number of things to
provide a general guideline for traffic.

    Personally, while I believe all these categories can provide signal,
they may also provide what I would consider noise, and not find useful.
 Specifically:

* Sharing of experiences with the current development branch of Ubuntu

    It's nice to hear of things that work well, or things that are
almost there, with suggestions on how they might work better.  It's less
useful to discuss specific bugs: if someone isn't following a bug in
launchpad, they aren't likely to do so more in a mailing list.  It is
interesting to discuss classes of bugs: where some set of things may be
interesting to change for a number of packages, or some means of testing
has generated a set of bugs, although in either case, it's probably
better to make sure the bugs get into LP for proper tracking (although
for a very large number, it may be useful to discuss the value of
tracking that class of bugs prior to filing).

    Note that I'm not discouraging criticism, but I do mean to
discourage complaint: it's useful when someone says "These 8 things
could be improved, in these ways" or "This change causes these
regressions, which can be tracked as these bug numbers".  It's not
useful when someone says "That sucks".

* Technical questions about new features in the development branch

    When this is about some intentional feature prepared through an
Ubuntu specification, it's very useful to discuss the implementation
under way, both for knowledge sharing, and to help ensure the
documentation for that feature is complete when the release arrives.
When it is about a feature included in some specific package or
application as a result of using a newer upstream, it may be that nobody
on the list has an answer, and a more specific list could be more
appropriate.  On the other hand, it may be that a feature provided by a
new upstream version would be a good leverage point for improving other
things, in which case it's a useful topic to raise.

*  Ideas and suggestions about future development of Ubuntu

    The more specific an idea, and the more that the presenter is
willing to be involved in the preparation of a solution, the more that
it's interesting to discuss on this list (e.g. I found an open-office
filter for the QRZX file format, and it works for me.  I understand
there is also a Koffice filter available from ${URL}.  Does anyone know
of other filters that could be used to improve QRZX file support?  I've
filed a tracking bug (URL)".  When it's something general (e.g. "Ubuntu
should enable support for the .QRZX file format, which everyone uses.
It works on my HAL and Moon systems, and Pear promised to provide it
soon"), it is much less useful.  Note that these are essentially the
same idea, but the presentation by the submitter is a bit different,
including a demonstration of some interest and effort in making it work.

* Point of contact for Ubuntu users to reach Ubuntu developers

    There are *lots* of reasons that users want to reach developers.
For many of them, there are more specific fora.  Bugs should be reported
to the bug tracker (2).  Suggestions for features that would benefit
from discussion and voting should be posted to brainstorm (3) (although
a post to this list pointing at the brainstorm entry is not entirely
bad).  Posts specific to a certain area of Ubuntu may be better
discussed on more specific mailing lists (see the list (4).  Requests
for assistance or support most specifically belong on the ubuntu-users@
list.  I'm likely missing *lots* of other specific fora, but in summary,
such a general list as ubuntu-devel-discuss@ is probably best used when
either it's not clear which  forum may be more appropriate, when it's
something that isn't specific enough to fit in another forum, or when a
specific forum for the topic in question doesn't exist.


> The current draft of the survey is at
> http://pileofstuff.org/ubuntu-survey/ and will go live this time
> tomorrow - there's still time to make changes if you have ideas.

    I took a look at the survey, and didn't think I could complete it
accurately.  Please find below my review, and suggestions for improvement:


Section 1:
    I'd suggest rephrasing the questions to be more subjective, as you
are collecting opinion data.  Perhaps:

The list has {far too few, too few, about the right number, too many,
far too many} posts overall.

The number of posts on the list that are useful to me are []
The number of posts on the list that are not useful to me are []
The number of posts that I think belong in another forum are []

Section 2:
    To save your effort, you may want to encourage the posters to go
through the list archives themselves, and post URLs to the specific
messages that fall into each category.

    Also, I'd recommend changing "would read" and "would not read" to
"would like to read" and "would not like to read", as some people would
like to read messages that get lost because they fall behind, and others
would not want to have read messages that they ended up viewing because
of their mailreader configuration.

Section 3:
   I'm curious what the first question seeks to measure.  I'm not sure
precisely what measures we have available, other than redefining the
list topics, or changing moderation, but I'm not convinced that
understanding the strength of measures to be taken, or the redirected
focus would help lead to a selection of measures to be taken.

    The reluctance section seems odd to me: I consider each of the
listed items to be significantly different, and my comfort level with
each of them has little impact on my use of this list.  While there is
perhaps some slight overlap with ubuntu-devel, that list is defined (5)
in a way that is mostly different (although I'm not sure all posters
necessarily read those guidelines).  Brainstorm is a bit more uncertain:
it really depends on the nature of the idea, and what sort of discussion
is required to move forward.  I think it is rare that a non-developer
writes a blueprint that is useful and implemented, although some of
these developers may not be Ubuntu developers.  Understanding reluctance
to post to this mailing list is perhaps more interesting.  Below this,
there is a comment box asking for an explanation of the preferences:
given that I consider each of the above described items to have a
distinct role, I'm not sure how this could be expressed as
"preferences", or what explanation would reasonably fit in the available
space.

Section 4:
    The first question may be better offering only the first four
options, each as a checkbox, to better understand the subtleties of
interaction between developer/having developer interest/non-developer
and professional/personal interest.  Firstly, many (but not all)
developers are also users, and will regularly experience areas of Ubuntu
in which they are not expert for which they have questions and concerns
no different than that of any other user.  Secondly, there is little
direct relation between one's personal or professional interest in
Ubuntu and one's status as a developer.

    The second question confuses me entirely.  I have not previously
encountered the phrase "core member of the Ubuntu project".  I presume
this is intended to represent Ubuntu Members, in which case I would
recommend using that phrase alone.  Secondly, every MOTU is an Ubuntu
Member: given that it can be determined if a given respondent is a
developer from the previous question, this could probably be reduced to
"I am an Ubuntu Member", "I am strongly involved with Ubuntu, but not a
member", "I have little or no direct involvement in Ubuntu", and "No
answer".  Note that there are also developers who don't happen to be
MOTU, but that's more an artifact of how the launchpad groups are
organised than anything else.

    Lastly, "How likely are you to unsubscribe from the list due to
noise?" is an odd question to ask current subscribers.  The plurality
are likely to be long-term subscribers, who are unlikely to now
unsubscribe (as they haven't previously), but this does not necessarily
represent a plurality of those who have been subscribed, or even of
those who have recently subscribed.

1:
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
2: https://bugs.launchpad.net/ubuntu/+bugs
3: http://brainstorm.ubuntu.com/
4: https://lists.ubuntu.com
5: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel

-- 
Emmet HIKORY