Received: by 10.224.19.199 with SMTP id c7mr505812qab.22.1239282170323;
        Thu, 09 Apr 2009 06:02:50 -0700 (PDT)
Return-Path: <jham...@openplans.org>
Received: from exit.openplans.org (exit.openplans.org [64.90.184.65])
        by gmr-mx.google.com with ESMTP id 23si9922qyk.6.2009.04.09.06.02.49;
        Thu, 09 Apr 2009 06:02:49 -0700 (PDT)
Received-SPF: pass (google.com: best guess record for domain of jham...@openplans.org designates 64.90.184.65 as permitted sender) client-ip=64.90.184.65;
Authentication-Results: gmr-mx.google.com; spf=pass (google.com: best guess record for domain of jham...@openplans.org designates 64.90.184.65 as permitted sender) smtp.mail=jham...@openplans.org
Received: from openplans.org (jhammel.openplans.org [10.50.10.58])
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(No client certificate requested)
	by exit.openplans.org (Postfix) with ESMTPSA id 20FE72C9D85
	for <trac-users@googlegroups.com>; Thu,  9 Apr 2009 09:02:49 -0400 (EDT)
Date: Thu, 9 Apr 2009 09:02:47 -0400
From: Jeff Hammel <jham...@openplans.org>
To: trac-users@googlegroups.com
Subject: Re: [Trac] Re: Requirements for a new and improved Gantt plugin
Message-ID: <20090409130247.GC6588@openplans.org>
References: <C8F551D39A7C724E987CF8DD11D3178302ADD115@svr3.sixnetio.com> <rmivdpe7jku.fsf@fnord.ir.bbn.com> <C8F551D39A7C724E987CF8DD11D3178302ADD152@svr3.sixnetio.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <C8F551D39A7C724E987CF8DD11D3178302ADD152@svr3.sixnetio.com>
User-Agent: Mutt/1.5.17+20080114 (2008-01-14)

On Thu, Apr 09, 2009 at 08:27:59AM -0400, Chris Nelson wrote:
> 
> Greg Troxel wrote:
> >    2. Task A is composed of tasks B and C.  A's estimated time is the
> >    total of B's and C's.
> > 
> > This makes sense, and I think it would be good to have support for
> > this independent of a gantt plugin. 
> 
> Yes.  I agree.  It would be a nice piece of separate functionality that
> a Gantt plugin could require.  Shall we call it CompositeTicket for the
> purposes of discussion?

I've always like SubTasks, but nomenclature aside, its functionality that I've wanted for a long time (or more correctly, that other people have repeatedly asked for).  Ideally, I'd like to see this in core, but since I know that's unlikely, at least as its own plugin that other plugins could consume.
 
> > nit: Task A might have hours for A, in addition to subtasks B and C.
> > You might want to ban this by policy, but it makes sense for some
> > people. 
> 
> If A is do B and C and spend time coordinating them, I'd argue that that
> coordination is task D.  (Though I admit that time might be concurrent
> with A and B.  Maybe the solution is to pad tasks B and C for the
> management overhead in coordinating them.)  But I really wouldn't want
> to have time in a task that's decomposed into other tasks.
> 
> 
> > In the requirements, it's not clear to me if the scheduling is
> > supposed to be resource aware or not.  ...
> 
> That's a good question.  As long as it's isolated in a plugin and not
> tangling up the core, I don't know that it's a bad thing that the Gantt
> plugin is resource aware.  Or maybe there's a Resource Leveling plugin
> that requires the Gantt plugin.  (And a Project Management package that
> bundles TimingAndEstimation, MasterTicket, CompositeTicket, Gantt, and
> Resource.)
> 
> 
> >    3. Tasks A and B start at the same time
> >    4. Tasks A and B must end at the same time
> > 
> > I don't think this is realistic from the reality point of view.  
> 
> I have an associate who's a certified project planner and he couldn't
> come up with examples of those uses either, though he confirmed that
> they are considered valid to project management weenies.

Weighing in on this discussion late, I haven't used the GanttPlugin but am very interested in time-tracking via Trac.  I co-wrote the TracHours plugin in response to user-critiques of the TimingAndEstimation plugin.  Still, the latter is more mature and TracHours still lacks much functionality.  I would love to see a definitive solution to time-tracking in Trac and am willing to contribute what I can in terms of expertise (and less so in time, unless it becomes an organizational priority again) to this end.

Jeff