Fwd: Collecting feature requests

[Casey Ho]

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.

>> 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.

>> 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 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'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.

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.

> 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.

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.

-Casey