Fwd: Collecting feature requests

[Kevin Stange]

Casey Ho wrote:
> On Sat, Jan 3, 2009 at 3:31 PM, Kevin Stange <kstange at pidgin.im> wrote:
>> Casey Ho wrote:
>>  > You seem to have missed the point of Brainstorm.
>>> The point was _NOT_ to improve our development tools.
>>>
>>> The point was to improve our user relations.
>> I think I speak for nearly all of the development team when I say that
>> we do not feel it improves user relations to give people an extra place
>> where we will blatantly declare we intend to disregard all of their
>> feedback.
> 
> If you phrase it that way, sure.
> 
> What I mean is we can disregard the feedback on a day to day basis.
> It's still important for one of the developers to check every couple
> of months and report back.  That's not asking much.

It's asking a lot more than you think because for it to be effective,
everyone has to play.  I'll explain further down.

> 
>>> There was no intent that developers would ever need to even look at
>>> such a site.  By corollary, I never expected it to be a huge driver of
>>> development either- mainly because some of the ideas are already being
>>> worked on (good!).
>> So in other words, your goal was to create a black hole in which lots of
>> information goes in and almost always disappears forever.
> 
> No the point is that the information is available to the public, even
> if the developers aren't doing anything about it.

I think you have a misunderstanding of our feelings about leaving users
to their own devices without an active developer presence filtering and
responding to feedback.  It results in speculation, dissemination of
incorrect information, and unrealistic expectations.  It tends to result
in things like inaccurate slashdot and wikipedia articles and blog posts
asserting things that are untrue.  I don't feel we need to make more
room for such things.

We put a lot of effort into attending to all feedback so we know what
information is being put out there and can direct it into helpful forms.

>>> Yes things will be redundant.  But it's a place for users to vent, for
>>> users to find out that other users care too and for an idea to be
>>> picked up by a new patch writer or plugin developer.  The latter point
>>> is the most important, because right now everything that happens in
>>> Pidgin needs to be filtered by the developers first- ala the
>>> Cathedral.
>> Everything that happens in Pidgin will always need to be filtered
>> through the developers first before anything changes.  We are in charge
>> of the project.  This just misleads users as to what level of impact
>> they have on things.
> 
> Absolutely, and this should remain true.  However, the developers
> should act as the final judges, not the first level of filtering.
> 
> That also doesn't address plugin developers, who benefit from this
> knowledge.  For Wordpress, whenever someone has a plugin idea, people
> say "hey, send it to the ideas board first".

We want plugin developers to check our Trac for feature suggestions we
think don't belong in Pidgin.  It's counter productive if we have a
patch writer or developer implementing something within Pidgin based on
a ticket in trac while plugin authors are off on another part of the
site taking the same ideas and making duplicate effort.

Then, we simultaneously lose track of valuable user feedback as to how
the implementation might be better tuned for alternate use cases while
the plugin author is collecting them.  Then we have two conflicting,
divergent implementations of the same thing.

Divergent, duplicate work is something we want to avoid and duplicating
information across a lot of different media is something I see as very
bad because it's so much harder then to ensure people are consistently
informed.

It's one of the major complaints we've had with Ubuntu's launchpad.
People posting issues there go there rather than to our primary support
resources and then end up getting delayed or inaccurate information from
other users because Pidgin developers don't want to spend the time
checking yet another support resource.

>> We already categorize tickets on our ticket system to separate feature
>> requests for which we want third party contributions or plugin authors
>> to step up, and you can drop a single search query into the ticket
>> system to find them.  If we want to pre-fabricate a page that shows
>> those tickets, that's pretty easy, but segregating our users into a
>> separate-and-not-even-supposedly-equal "feedback" mechanism is just
>> going to result in worse user to developer communication.
> 
> The best way of doing feedback is to have multiple places to do it-
> surveys, Trac, mailing lists, forums.  Each user has their own
> favorite way of submitting feedback, and that's just the way life is.

I disagree.  The best way to handle feedback effectively is to have it
all come into the same place so it can be uniformly reviewed and sorted.
 The more avenues of information to process, the more likely that one
will be neglected and users will feel they are being ignored.
Additionally, if various areas are receiving different levels of
attention, we lose a percentage of simultaneous feedback that might have
been useful at a specific time while developers were conducting a
discussion on how to undertake a particular task.

I work in customer support.  Just because a user prefers to submit
technical questions to me via IM doesn't mean I'm going to let him.  He
has two choices: ticket or phone call. If he calls and his issue is
complicated, I'm going to insist he use a ticket so that we can actually
keep track of what's going on in a coherent and uniform way.

If we want to serve our users, I would agree that we have a
responsibility to provide a clear way to submit feedback, but we don't
have a responsibility to provide everyone with their favorite feedback
mechanism.  I am not going to sit in an official Pidgin Yahoo! chat room
or start accepting feedback for Pidgin over the phone, so that those
subsets of users that prefer them will have their favorite medium available.

> I'm not asking every developer to check every new feedback venue.  If
> you don't like Brainstorm, don't visit it.  Let me or someone else do
> it.

No offense, but I wouldn't be comfortable with a non-developer taking an
"administrative" role in an "official" feedback mechanism.  The
development team is aware of what is going on in their parts of Pidgin
and the feedback is most meaningful to people with a detailed
understanding of those components, which is why having the tickets
assigned to them in Trac makes the most sense.  If you are taking
feedback regarding components you're not maintaining, how do you know
whether what's being said isn't already part of a larger plan, or
whether it would be easily welcomed in patch or plugin form?

It's one of the reasons I'm really frustrated right now.  You're making
changes to Pidgin's web site, which is presently my responsibility,
without ever clearing anything with me.  I don't even make changes to
the web site without getting a fair amount of consensus from our
development team.  I am doing my best to run QA on your changes after
the fact and hope our users aren't getting too much confusion in the
process.

We don't let patch writers commit their patches to our source code to
our monotone server without discussion and review.  Again, most of our
developers don't even undertake major changes without running it by as
many people as possible for consensus.  I would really appreciate
discussing things like this BEFORE implementation so we can have these
discussions amongst both users and developers like we're doing now after
the fact.

> Keep in mind Brainstorm is not meant for troubleshooting (unlike the
> SF forum and the mailing list), hence it shouldn't require daily and
> immediate developer feedback.

For the record, the SF forum is almost entirely ignored.  From my review
of recent posts there, there is a lot of unneeded confusion until a
developer wanders in.  I would personally prefer we discontinue the SF
trackers and forums.

>> This entire plan seems to be structured around the idea we do not want
>> or care to hear from users, which is untrue and helps feed a lot of
>> misconceptions about our project.
> 
> No, the plan is structured around the misconceptions, which have a lot
> of validity, like it or not.
> 
> The plan assumes that ratio of developers to users is so high that
> there's no possible way for developers to enjoy listening to them one
> by one.  I don't.

They have no validity as conceptions, only as misconceptions.  We do
consider user feedback and try to redirect it to channels that are most
appropriate based on our own determinations.  Luke and John in
particular have expressed interest in bearing some of the responsibility
of doing the high level filtering of all feedback.  I know they don't
need any more places to pay attention to while they are filtering
information.

The misconceptions come from the idea that feedback is equivalent to a
guaranteed change.  Our debates with users about their ideas help us,
and we hope to show users why some feedback does not turn into
guaranteed change in the process.  Separating feedback in this way has
not the slightest hope of correcting those misconceptions.

If the misconception is "Pidgin doesn't care about user feedback" which
seems to be the number 1 misconception about Pidgin, adding a section
where Pidgin largely ignores user feedback may stop people from hearing
things from us that they can interpret as "Pidgin doesn't care about
user feedback" but they'll instead *see* that "Pidgin doesn't care about
what I say here" and we have a new misconception.

> The plan assumes it's a good idea to separate feedback from
> development, so developers can cherry pick the feedback but also tune
> it out easily.

I think feedback and development must be tightly associated if we are to
identify issues with design changes and new features promptly, and I
think we should focus on having feedback in fewer places to avoid people
going unheard.

Kevin

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 260 bytes
Desc: OpenPGP digital signature
URL: <http://pidgin.im/pipermail/devel/attachments/20090103/efefa5cf/attachment.sig>