Re: Resource Importing

"C.J. Collier" <[email protected]> 16 May 2003 10:40:18 -0700
Newsgroups gmane.comp.gnome.apps.mr-project.user
Message-ID <[email protected]>
On Fri, 2003-05-16 at 01:29, Benjamin BAYART wrote:
> Le Thu, May 15, 2003 at 06:11:12PM +0200, Mikael Hallendal:
> > > It should be possible to import resources from your evolution address
> > > book.  Or LDAP.  Or whatever.
> > I agree that this would be a good idea. 
> 
> Not *so* good. Or not directly. An adress book in a mail agent might be
> very large, say something like hundreds (or more) adresses. Are you
> really willing to plan the work of so much people with a tool like
> MrProject?

You don't need to use every person in your address book just because you
have them at your disposal ;)

> I think a good point would be to have a *kind* of interface with
> something else, perhaps evolution or LDAP, but with a powerfull filter,
> the main interest is to have a few goodies from that:
> - not to have to re-enter all the resources for each project
> - to be able to communicate informations automaticaly to the involved
>   people

What would the filter be for?  Sounds like you're on to something, but I
don't understand...

> > > And I still think it's a good idea to link skills to resources.  In
> > > Evolution, too.  This duplication of data stuff stinks.  Perhaps
> > > Gnome-DB should be used to store contact information including all the
> > > contact stuff that Evo stores, plus skill lists, and even GnuBucks
> > > transaction information (http://www.gnubucks.com/)
> > 
> > Another solution for the skills is that we could perhaps have support
> > for a resource to be in multiple groups (which could be C-programmers,
> > Java-programmers, ... or something?)
> 
> It depends on the way you handle the groups. If you want to do "group
> leveling" (like for "resource leveling"), it doesn't sounds like a good
> idea: on the current model, the "normal" use for group with 5 resources is
> 500, on the model like the one you propose, you can have two groups with
> normal use of 1000 (you have 11 resources, in which 10 of each are
> C-programmers, and 10 are Java-programmers), in such a case you can have
> the illusion that you have a 2000 normal use for the whole staff, and
> you cannot any more use groups to compute that kind of things.

It should be easy enough to note whether a resource (or contact) is
already assigned to a project and not expect them to do two things at
once.  Say there's a C project and a Java project, if Bill is assigned
to the C project starting on Monday and ending on Thursday, and you want
to assign him to a Java project starting on tuesday and ending on
Friday, a conflict flag will be raised, prompting the project manager to
choose which is higher priority and communicating that to Bill.

> I think it's a good point to have a difference between skills and
> groups. But I don't know if assignments can be computed from skills. It
> can lead to some inextricable complexity in the schedulling process. And
> if you don'y use it for automatic assignment, what is the use of such
> information?

We shouldn't shy away from it just because it's complex.  Let's do it
right the first time, even if that first time takes a hell of a long
time.  Look at it this way:  Our work will be viewed for generations to
come.  Do we want people to see it as amazing or so-so? :)

> Regards,

> 	Benjamin.

namaste,

C.J.