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
