On Sat, 2014-06-21 at 00:42 +0200, Andre Klapper 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. +1
-- -mvh Oliver Propst _______________________________________________ engagement-list mailing list [email protected] https://mail.gnome.org/mailman/listinfo/engagement-list
