<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
  <head>

    <meta http-equiv="content-type" content="text/html; charset=ISO-8859-1">
  </head>
  <body bgcolor="#ffffff" text="#000000">
    <meta http-equiv="content-type" content="text/html;
      charset=ISO-8859-1">
    <div class="ace-line" id="magicdomid64"><span
        class="author-g-llo7i64ephyvgeg3">It has become very clear from
        recent discussions that how much </span><span
        class="author-g-sehws9rse8htilr5">(if at all) </span><span
        class="author-g-llo7i64ephyvgeg3">a person is bothered by the
        lack of a newsgroup presentation of Thunderbird-related
        newsgroups depends heavily on personal working style.  For many
        folks, the mailing list presentation works, if not well, at
        least Well Enough.  However, it's also clear that there are
        non-trivial usability issues in the tb-planning community with
        the current email-only presentation (mostly in Thunderbird, but
        also in a few other clients).  </span></div>
    <div class="ace-line" id="magicdomid7"><br>
    </div>
    <div class="ace-line" id="magicdomid66"><span
        class="author-g-llo7i64ephyvgeg3">Here's a short summary of the
        most important interests of multiple people in the tb-planning
        community that are not met by the current email-only
        presentation of group conversations:</span></div>
    <div class="ace-line" id="magicdomid9"><br>
    </div>
    <div class="ace-line" id="magicdomid67"><span
        class="author-g-llo7i64ephyvgeg3">* they are not automatically
        separated from the Inbox, which is experienced as clutter </span></div>
    <div class="ace-line" id="magicdomid68"><span
        class="author-g-llo7i64ephyvgeg3">* the unread count for them is
        propagated to the folder pane, dock, and biff, which feels like
        clutter and is distracting </span></div>
    <div class="ace-line" id="magicdomid12"><span
        class="author-g-llo7i64ephyvgeg3">* it's difficult to interact
        with historical or in-progress discussions </span></div>
    <div class="ace-line" id="magicdomid110"><span
        class="author-g-llo7i64ephyvgeg3">* t</span><span
        class="author-g-sehws9rse8htilr5">here is a</span><span
        class="author-g-llo7i64ephyvgeg3"> barrier to entry and exit for
        participation</span></div>
    <div class="ace-line" id="magicdomid14"><span
        class="author-g-llo7i64ephyvgeg3">* some tools for dealing with
        volume (watch, ignore, ...) are missing or inferior to that of
        newsgroups</span></div>
    <div class="ace-line" id="magicdomid15"><br>
    </div>
    <div class="ace-line" id="magicdomid111"><span
        class="author-g-llo7i64ephyvgeg3">At <</span><span
        class="author-g-llo7i64ephyvgeg3 url"><a
href="https://wiki.mozilla.org/index.php?title=User:Dmose/Tb_Product_Notes">https://wiki.mozilla.org/index.php?title=User:Dmose/Tb_Product_Notes</a></span><span
        class="author-g-llo7i64ephyvgeg3">>,  we've said that we're
        targeting individual and SOHO (Small Office / Home  Office)
        users.  We've also said that we'll be doing this by</span><span
        class="author-g-sehws9rse8htilr5"> </span><span
        class="author-g-llo7i64ephyvgeg3">"focusing on conversations
        that occur over mainstream and emerging communication channels.
        These include email, web forums, social networks, and
        microblogging services." <br>
      </span></div>
    <div class="ace-line" id="magicdomid19"><br>
    </div>
    <div class="ace-line" id="magicdomid122"><span
        class="author-g-llo7i64ephyvgeg3">All of the interests in the
        list above are not only our own interests as a development
        community, they are also shared by our users when they're having
        conversations over email.  And those rough edges of handling
        conversations over email are part of our mainstream users'
        day-to-day experience of our product. </span></div>
    <div class="ace-line" id="magicdomid21"><br>
    </div>
    <div class="ace-line" id="magicdomid189"><span
        class="author-g-llo7i64ephyvgeg3">While it makes a </span><span
        class="author-g-sehws9rse8htilr5">lot</span><span
        class="author-g-llo7i64ephyvgeg3"> of sense for us as </span><span
        class="author-g-sehws9rse8htilr5">the </span><span
        class="author-g-llo7i64ephyvgeg3">development community to enjoy
        the benefits of the NNTP experience today, it is also acting as
        a crutch: because we're not eating our own dogfood, it's
        preventing us from having a deeper understanding of how those
        problems feel to our users.</span></div>
    <div class="ace-line" id="magicdomid23"><br>
    </div>
    <div class="ace-line" id="magicdomid227"><span
        class="author-g-llo7i64ephyvgeg3">This in turn makes it much
        harder for us to make the gut prioritization choices for
        solutions to these issues both individually and as a group. And
        when I say individually, what I'm trying to communicate is that
        while some amount of feature work and fixes happens as a result
        of driver-led prioritization, lots also depends on decisions
        made by individual community members.  In particular, it depends
        on the decisions of individual developers, triagers, </span><span
        class="author-g-sehws9rse8htilr5">bug filers, and </span><span
        class="author-g-llo7i64ephyvgeg3">designers about "what feels
        like the next most important thing for me to spend my own time
        on?". </span></div>
    <div class="ace-line" id="magicdomid25"><br>
    </div>
    <div class="ace-line" id="magicdomid278"><span
        class="author-g-llo7i64ephyvgeg3">So I'd like to be clear that
        at this point I still feel that the decision to leave the NNTP
        gateways off is the right one, though not an easy one.  I
        understand that this requires some work flow changes and, even
        with those, it won't be entirely comfortable, and I'm
        sympathetic to that.  But it has the advantage of serving the
        interests of _both_ us in the development community _and_ the
        interests of our users, rather than serving the interests of the
        development community while working against the interests of our
        users. </span></div>
    <div class="ace-line" id="magicdomid27"><br>
    </div>
    <div class="ace-line" id="magicdomid330"><span
        class="author-g-llo7i64ephyvgeg3">It's not impossible that I c</span><span
        class="author-g-sehws9rse8htilr5">ould</span><span
        class="author-g-llo7i64ephyvgeg3"> be convinced to change my
        mind, but at this point, I feel like the bar is pretty high. I
        have a decent understanding of the pain points, and for me to
        change my mind, I'd have to get new information that made me
        believe that creating those gateways really would serve the
        overall goals of Thunderbird better. </span></div>
    <div class="ace-line" id="magicdomid29"><br>
    </div>
    <div class="ace-line" id="magicdomid285"><span
        class="author-g-llo7i64ephyvgeg3">Dan</span></div>
    <div class="ace-line" id="magicdomid32"><br>
    </div>
  </body>
</html>