On Wed, Apr 18, 2012 at 1:38 AM, Magnus Hagander <magnus@hagander.net> wrote:
>> At the same time, I think we'd likely be a lot better off squirting this
>> data into bugzilla or another standard tracker, instead of building our
>> own infrastructure.
>
> I'm somewhat doubtful.
Me, too.
It's very tempting to assume that the problem we're trying to solve
must already have been well-solved by someone else, and therefore we
ought to use their thing instead of inventing our own. But that
presumes that our problem is exactly the same as other people's
problem, which may not really be true. IME, bug trackers typically
work best when used by a tightly integrated team. For example,
EnterpriseDB uses a bug-tracker-ish system for tracking bugs and
feature requests and another one for support requests. Those systems
get the job done and, certainly, are better designed than Bugzilla (it
doesn't take much), but a lot of what they manage is workflow. Person
A assigns a ticket to person B, and person B is then responsible for
taking some action, and if they don't then someone will come along and
run a report and grouse at person B for failing to take that action.
If those reports weren't run and people didn't get groused at, the
system would degenerate into utter chaos; and of course in a community
setting it's hard to imagine that any such thing could possibly occur,
since this is an all-volunteer effort.
So I think Greg has exactly the right idea: we shouldn't try to
incorporate one of these systems that aims to manage workflow; we
should just design something really simple that tracks what happened
and lets people who wish to volunteer to do so help keep that tracking
information up to date.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
