> But yeah, issue tracking systems were not designed for task and project > management, but some organizations [ab]use them for that.
I probably wanted to express that having to learn a new tool requires > convincing reasons shared by the team, otherwise a tool will not be > widely accepted and effectively used in a team. Yeah it's usually better to use a tool specifically designed for that. But since nothing is being used it's better if Bugzilla is used even at least temporarily. If anyone has any other suggested systems please bring this up. Perhaps if Oliver could run a poll we could see what systems people are familiar with and choose that. On Fri, Jun 20, 2014 at 6:42 PM, Andre Klapper <[email protected]> wrote: > On Fri, 2014-06-20 at 18:05 -0400, Alex G.S. wrote: > > Except for charts (what kind? Gantt? Or some "Task 4 is 14.3% > > done" in a > > graphical way?), this sounds > > like http://bugzilla.gnome.org and not yet > > like a convincing reason for another piece of infrastructure > > software to > > maintain, > > IMHO. https://wiki.gnome.org/Bugsquad/ForMaintainers explains > > how to get a Bugzilla product and/or component, if wanted by > > the team. > > > > > > Well, after browsing, https://bugzilla.gnome.org/browse.cgi I see > > software projects, apps and code so I don't know how we could utilize > > the bugzilla for that purpose. > > You wrote about the "ability to setup a sub-project" like a product or > component in Bugzilla "and have issue tracking" like a ticket in > Bugzilla and "each article could be a feature" which might be a > component or a dependency task in Bugzilla "and people could then be > assigned" which is a ticket assignee in Bugzilla. > > Based on that I was wondering if a software project with subtasks, > target milestones and assignees for a task is very different from a > non-software project. > (But yeah, issue tracking systems were not designed for task and project > management, but some organizations [ab]use them for that.) > > > > I'm not sure though if there's really a technical issue to > > solve here > > (supporting tools) or a social 'issue' instead. > > > > > > What do you mean? > > I probably wanted to express that having to learn a new tool requires > convincing reasons shared by the team, otherwise a tool will not be > widely accepted and effectively used in a team. > > andre > > -- > Andre Klapper | [email protected] > http://blogs.gnome.org/aklapper/ > > _______________________________________________ > engagement-list mailing list > [email protected] > https://mail.gnome.org/mailman/listinfo/engagement-list >
_______________________________________________ engagement-list mailing list [email protected] https://mail.gnome.org/mailman/listinfo/engagement-list
