I've seen the current incarnation of Bugzilla used as a task manager a couple of times already: "bugs" become "tasks"; "people" become "programs"; and "components" become "projects" that people are working on. This works really well because a lot of the logic of a "bug" applies to tasks in a business as well (for instance, at a consulting firm I work at, where we're looking at using bugzilla for this); some tasks rely on other tasks. Some people work cooperatively on tasks (cc); managers might QA the task to make sure it's done to their specifications; a task has an "owner" that is responsible for making sure it gets done correctly... the correlations can go on and on. The great thing about bugzilla as it is now is that it handles most of the dirty work for a "task" system right now: it does "task" dependencies, attachments, keeps a log of what was discussed between those working on the tasks during its completion, has all the logic for sorting/querying "tasks", etc.; in other words, bugzilla has a huge amount of wonderful functionality for the management of tasks as well as bugs. A couple of things it does lack: time tracking/billing management, and some other business requirements of a small business task manager (which I'm currently starting to gather based upon what the company I work for uses it for). It would be cool if bz3 could use some sort of "plugin"-type design for description fields in a "bug"/"task" so that the current bugzilla engine could be extended for not only bugs, but tasks, and anything else that lends itself to this type of collaborative effort. Thus, it would be nice if bz
Reassigning bug to myself for now... Hixie doesn't need more work right now. :-)
The Bugzilla 3 component is going away. We're going to depend on the Milestones for this. At the time this component was created, we didn't have milestones for Bugzilla.
Suggestion: For customizing bugzilla into a task-management utility, can this be done such that a handful of configuration files can be tweaked? My company wants me to customize a new bugzilla instance for purposes of doing Taskzilla-type things. In the interim, while I do this, I want some kind of path to retain the existing data that will be produced from this instance. I will need to migrate this to the proposed Taskzilla when you guys release it. Taskzilla has been targetted as Bugzilla 3.0-based, and I read that 3.0 is a new re-write? What does this mean for anyone who's 2.1X(.Y)-based? We will also need a migration path to retain any previous customizations we might have made. I'm not a believer in re-inventing the wheel, hence my comments. I want to make use of whatever you guys come up with, but would prefer to have the simplest way for doing what my company needs. And I don't want to pre-empt future Taskzilla usage by starting on a customizations rampage with an existing bugzilla instance.
There will most certainly be an upgrade path for standardized 2.x Bugzilla fields whenever 3.0 hits the scene; if you customize a lot of fields to tack on "Taskzilla"-like features to BZ, these probably won't be supported by our official upgrade process, so you'll have to hack something together yourself (possible) or hope that we add enough features to fulfill you needs in 2.x. Having said that, Bugzilla is working pretty well as a task tracker already; bug 24789 will increase its usefulness in that space. If there are other features you want, I would recommend filing them as RFEs and Ccing firstname.lastname@example.org; he focuses on a lot of enterprise features, of which increasing Bugzilla's usefulness as a task tracker is one of those goals. I'm actually thinking about resolving this bug as a duplicate of bug 13540.
In modern times, all of the things in the original comment are pretty much possible. It's very easy to change the name of Bugzilla and the word "bug." Also, we have time-tracking now.