Collecting feature requests

[Marc Seiler]

Well if I may add to that being a web developer drupal is a very bad idea
for a site with high activity and even worse for one being ran on a virtual
server. I know that it is becoming very redundant in what you all are saying
and having multiple places for people to submit features or in some cases
bugs (because people will) for a developer to monitor is a bit much even for
a paid developer specially when like Luke said trac seems to have most of
the same features and it would centrelize all the data. Just my 2 cents.
Sorry if my mailin list etiquette is a bit off I've never really used one
before so if top posting is bad I'm sorry let me know and if I snipped to
much also let me know

Thank you,
Marc Seiler


On Sat, Jan 3, 2009 at 2:02 PM, Luke Schierer <lschiere at pidgin.im> wrote:

> On Sat, Jan 03, 2009 at 01:47:26PM -0500, Marc Seiler wrote:
> > Hello guys I have never posted on here but I've been watching for a long
> > time and was wondering where is "trac"? I don't think it's labeled trac
> on
> > the website because I can't find it.
> >
> > Thank you,
> > Marc Seiler
>
> The "development" button on the website is the primary way to reach it,
> but you could also find yourself there having followed the "User Guide"
> or "FAQ" links under the "Help" section.  There are also a couple other
> links on the website that would bring you to our Trac install.
>
> Basically trac is an integrated wiki and ticketing system that we use
> both for content that users should be able to contribute to (like the
> FAQ), and for handling bug reports, feature requests, and so on.
>
> That's part of why Kevin, John and I have objected to the brainstorm
> install: it is another, very separate place, for feedback, guaranteeing
> duplication of information.
>
> Back when we were entirely hosted on SourceForge, we had both the SF
> trackers enabled, and the SF forums.  Users regularly found one or the
> other, but rarely both.  Beyond that though, it is MUCH harder on the
> developers to try to keep up with, and respond to, a multiplicity of
> feedback venues and still find time to actually … develop.  Which is
> what, at the end of the day, all of us want developers to be doing more
> of ;-).
>
> Right now we have this and other mailing lists, and Trac for more
> perment things (such as feature requests or bug reports).  I think
> expecting developers to monitor another system is too much, ESPECIALLY
> when we can get most of the functionality in the existing system.
>
> Beyond that though, as I have said in other emails, I have a
> *particular* dislike of drupal based systems, having seen them crash and
> burn rapidly and messily when load gets high.  One thing my time on this
> project has taught me is that we *must* plan for that eventuality.  No
> matter how slow things might seem at any given point, this project will
> become busy again, and will eventually get /.ed again.
>
> Luke
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://pidgin.im/pipermail/devel/attachments/20090103/d624320b/attachment.html>