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.