Collecting feature requests
kevin at simguy.net
Fri Jan 2 20:36:21 EST 2009
Casey Ho wrote:
> Just a few minutes ago I created a new "brainstorm" area on the site:
> The goal of the site is to have a more open place to collect requests
> from users and figure out which ones are the most popular. The code
> running this is the same as the code for Ubuntu Brainstorm
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.
This is one of the reasons we don't have a forum and never will.
> 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.
> 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.
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 260 bytes
Desc: OpenPGP digital signature
More information about the Devel