Collecting feature requests

[John Bailey]

Kevin Stange wrote:
> Is there some way we can just make managing RFEs on trac more visible.
> This technique is going to cause mass duplication of information and
> take the focus away from the trac, which is what developers actually
> look at when dealing with Pidgin related development.  The more fancy
> widgets we have to play with, the less organized it gets and the less
> likely anyone's going to see it, and the more likely that misinformation
> appears in one or more locations.

We can create a wiki page that does a query on tickets, but that will of course
cause trac to have to run a query every time someone views the page.

>> Of course, what gets most voted on the site will be orthogonal to what
>> actually gets implemented.  That's fine, I just wanted to reduce the
>> amount of feature request juggling that needs to occur on Trac + make
>> it easy for users to "feel heard".
> 
> I'm concerned this site will be completely ignored by developers and
> thus it will be a waste of server resources and the time of users who
> are giving input.  I would rather make it easier for people to search
> for feature requests on Trac so everything is able to be monitored in
> one place.  Trac is extensible, so I'm sure an interface of some kind
> could put together a fancy page like this and not have so much overhead
> and data separation.

I agree with Kevin's assessment here, but I'd also like to point out that this
is going to cause users to think that their voting matters on what we do and
don't implement, when it will have absolutely no effect whatsoever.  I will also
note that I have no intention of sorting through yet another site with duplicate
and invalid content--it's hard enough for me to find time to deal with tickets
on trac.  I guarantee some user will decide that this site is a good place to
report bugs, even though that's not the intent.

>> Note: The new site runs Drupal, which means we can extend this in the
>> future.  On the downside, Drupal is resource intensive (Sean already
>> pointed this out).  I went with Drupal+Brainstorm because it was the
>> only available open source solution.
> 
> One of our goals has been to avoid making the web site too complicated
> so as to avoid generating extra load on our servers, which have limited
> processing power.  It's the reason I rewrote the site and killed off the
> former CMS our designer had given us.  I don't want to be using any CMS
> infrastructure if we can avoid it.

In my opinion, drupal is completely unacceptible for performance reasons alone.
 We're on two virtual machines, which I am not in ANY way happy about, and all
this does is make it even more painful to use them.  In addition, as Luke has
pointed out, this drupal installation is running on rock.pidgin.im, which was
supposed to be for just www.pidgin.im so that something beating the crap out of
a resource intensive service couldn't cripple the main website.

John

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