[thor] Proposed Thor changes

[Carlos Pedrinaci]

On Sun, 2004-02-29 at 20:53, Jason M. Felice wrote:
> On Sun, Feb 29, 2004 at 06:29:26PM +0100, Carlos Pedrinaci wrote:
> > Given that definition of what an Objective is I think that we could
see
> > a Project (from the Plan point of view) as:
> > 
> > * Project-Plan:
> > ---------------
> > A Project-Plan is composed of (0..*) Project-Plans (of its
Sub-Projects
> > if any) and (1..*)Objectives.
> 
> Here's another possibility which might be simpler: Perhaps we just
have
> projects and sub-projects, but we have different project templates or
> types.  So we can have a "Software Change" project type which has all
of
> the appropriate fields, and we can have a "New Program" project type
> which has all the CVS repository/OS type/Language/etc. fields.  (BTW,
I
> would suggest using the Trove categories for all of this information
like
> Freshmeat does).  Then we could create new project types like "Simple
> Website," "Documentation Authoring," etc.
> 
> This would mean that when I modify Hermes, people should just choose
the
> most specific project possible to enter time on (as opposed to
separate
> code for objectives and projects).
> 
> > There may exist the typical relations between them (End-End,
Start-End,
> > etc..).
> > Every Project-Plan has a set of costs estimations and may have some
> > "known costs".
> > These are all derived from the Project-Plans and Objectives that
compose
> > the current Project-Plan.
> 
> I just had an idea of a class heirarchy where projects are really just
> containers which can contain other thor objects, and we have a generic
> thor object and derive from it like Thor_Resource::, Thor_Task::,
> Thor_Ticket::, Thor_Expense::, Thor_Milestone::.  This way a project
is
> really like a tree of objects.
> 
> I don't know if that's a useful idea, but it just occurred to me.

I like this!
I have always been thinking about Thor as a Software Projects Repository
like SourceForge, where one would also be able to set a Project Plan and
share it with a set of persons. But given that Thor will need to have
Project Planning capabilities why sticking to Software Projects??
Implementing the Container idea would allow everyone to make use of Thor
whatever the purposes are.. If we ever see the need for a new Project
Characteristic -> just create a new Object and make it available..
> > 
> > * Objective:
> > ------------
> > An Objective is composed of (0..*)Objectives and (1..*)Tasks (Nag
Tasks)
> > It has also these pieces of information:
> > >   * Description of problem
> > >   * Description of solution
> > >   * Estimated number of hours to implement.
> > >   * Test script (human-readable instructions on how to prove that
the
> > >     modification was made and works)
> > >   * Estimated number of quality assurance hours.
> > >   * Required resources (conference rooms, projectors, particular
> > >     employee (Joe Fabetes), or a class of employee (Web Designer)
etc.)
> > >   * The objective's history (using Horde_History::)
> > >   * Business case information about the objective (estimated ROI,
net
> > >     present value, how the return is generated e.g. labor savings
or
> > >     revenue increase or increased accuracy, etc.)
> > >   * The objective's state (e.g. "initial", "agreed", "completed",
> > >     "in progress", "cancelled")
> > >   * Required expenses (e.g. hardware purchases).
> > >   * Dependencies (on other objectives). 
> > 
> > See that I clearly make the difference between a Project and a
> > Project-Plan as I also want Thor to serve as a Project Repository a
la
> > SourceForge.
> 
> How about calling them "programs" and "projects" instead of "projects"
> and "project-plans"?
> 
> If we used the above model, we could have a "Thor_CVS_Resource::"
object
> that you could throw into a project-plan container.  When the project
is
> approved, all objects get notified of the state change, and the
> "Thor_CVS_Resource::" could create the CVS repository at that point.
> You could throw multiple CVS resources into a project-plan if you
wanted
> to.
Again I like the Container idea
> 
> > 
> > I'm not sure about whether the fields you want to add to the Project
> > should be part of the Project itself or part of the Project-Plan. I
tend
> > to see them more as part of the Project-Plan mainly because that
> > information strongly depends on the company. We should allow some
sort
> > of customization for that... but this doesn't seem obvious to
achieve.
> 
> If we do some sort of project-plan template thingy, then we could set
up
> custom fields per template in an admin screen (similar to whups does
per
> module).
> 
> Alternately, if we did the container/generic object model, we could
have
> a "Thor_Attribute::" object that you could throw into a container.

If we use the Container idea, everyone would be able to set the
available "Objects" for Project-Plan creation/management but also
for Project Proposals etc..
On a per-site basis System admins would define their particular policy
in terms of "Objects" available/required for Proposals, Plans etc.. so
that its use is always compliant to the company's policy/capabilities..

The container idea provides all that by itself..
> 
> -- 
>  Jason M. Felice
>  Cronosys, LLC <http://www.cronosys.com/>
>  216.221.4600 x302