Forum OpenACS Development: dotWRK: Project Manager

Here is some preliminary thinking about it: https://openacs.org/forums/message-view?message_id=90508 (and the whole thread: https://openacs.org/forums/message-view?message_id=86810)

My workplace is clamoring for a project management solution. Unfortunately, that means they want it right now, and I'm still on ACS 3.4, gradually porting everything to OpenACS.

So I can write it on ACS 3.4, and port it to OpenACS. However, then I'm out of step with the efforts going on with OpenACS. Perhaps I can write this as a "rough draft" of the project management package for OpenACS?

Anyway, back to the point.

1) I've looked at all the resources people have suggested for project management so far (the data model for MS Project was very interesting). Are there any other things I should be looking at?

I went to http://www.microsoft.com/office/project and ordered an evaluation copy of MS Project for $8. Anything else we should be evaluating?

2) Do we have a clear roadmap for dotWRK? We have the people who are on-board, we have a list of things we'd like to do, and what we're interested in working on. What happens next?

3) Here is a very very (very!) primitive prototype of some ideas I've been kicking around for the project management piece:

http://www.dgp.utoronto.ca/~jade/projectmanagement/

I'll be working on this some more, and posting updates. I'd appreciate feedback on it.

Bear in mind that this is not even a partially complete interface. I'm playing around with what is necessary to make a simple but expandable project management system.

Anyway, I'd welcome your feedback.

Caroline, is there any way I could get a copy of the project management software Aristoi wrote? Could that be the foundation of the new dotWRK project management software?

Even if the code isn't up to your standards, it can be helpful as a starting point.

<blockquote> are we trying to create a product that competes head to head with
existing solutions or one that can be easily customized to meet non-
standard requirements.  Or probably a better way to look at it is where
on the spectrum between those two are we aiming for? 
</blockquote>

I propose this as a goal: dotWRK Project Management should initially provide a simple product that can be easily customized and extended by individual companies in a way that won't conflict with future upgrades. However, it should work for simple cases without any customization.

Our use case:

Actors:

Employees (Sales, R&D, Graphics, etc)

Projects:

Rolling out products for various customers
Typical project cycle is fairly complicated, but involves things like making the sale, then a huge mess of operations involved in getting the product to market for them. Each project involves up to 10-15 people in some way, sometimes more.
We keep track of information like which region this project is in, who is responsible for it, what products are involved, who in each department is involved, product numbers, etc... etc..

We have hundreds of projects, and are planning them throughout the year.

Scheduling of resources is a very large issue.

We don't have any particular need at the time to allow an extranet, although we have talked about it, and it is probably something we'll do at some point in the future.

We do have people in disparate locations.

We have frequent schedule changes. Entire projects can be rescheduled by months or weeks, cancelled, and brought back.

We are using the 3.4 Intranet right now, and I modified it to support our own company. A lot of it isn't being used at all. Mostly we're just using tickets, the calendar (with tickets hacked into them), time logging, and a bunch of proprietary stuff.

I've done a lot of reading these last couple of days about project management. Here are some links I found particularly interesting:

Edwart Tufte's discussion thread on project management software, gantt charts, and the issues involved in input and output. See especially the part at the end about the web-based design by Frog Design. I'd love to see that software.
http://www.edwardtufte.com/744545307/bboard/q-and-a-fetch-msg?msg_id=000076&topic_id=1&topic=Ask%20E%2eT%2e

Columbia's course on Project Management page. This has a great list of links for PM topics. Some of those links are really worth looking at.
http://www.columbia.edu/~jm2217/

For those just getting up to speed on PERT, activity networks, and critical paths:
The charts aren't great, but it does cover the territory:
http://www.doc.mmu.ac.uk/online/SAD/T04/projman.htm

One of our needs is to be able to associate arbitrary information with different project types.

For example, if we tag a project as a Graphics project, then we'd like to associate certain tables in the database with that project, and have the project page show information from those tables.

If we tag a project a Product project, then we can show information about the products.

Or something like that. I'm not sure of how to do this yet, but I think if we do something like this, we can avoid some of the problems I've seen with other PM software. It seems like because companies have such widely varying needs, something like this might be necessary in order to fulfill all of our needs.

A software company might be interested in linking in a completely different set of information for a project than a manufacturing company.

The way I see it right now there are:

Projects (and subprojects)

  Tasks (and possibly subtasks)

    Dependencies (a task is dependent on another task being completed)

  Project are broken down into Categories (may belong to more than one)

Users

  Roles (a user can have several different roles)

There are also several views:

Task View (for each user)
Project View (for each user)
Gantt or improved-Gantt chart for a Project
PERT-like view for each project

Requirements:

- When a user looks at a task, I think they should be able to see what depends on it being done, and how much slack time they have to complete it.
- When planning out a new project, it should be easy for a manager/PM to move project deadlines around, add in new tasks, make tasks dependent on other tasks, and reschedule tasks.
- Users should also be able to reschedule their own tasks (sending out alerts).
- It should be easy to see the critical path in a project.

I'm just blabbering a bit about what I've been thinking of. Any thoughts?

Also, copy project frameworks to new instances for generating initial new projects  (templating projects)

I think  it's  important to note that subprojects/phases might overlap temporally, also (phase-in, phase-out). Something to remember when defining constaints in the data model.

ps. Everything above I've read seems fine.

I am planning to use the categories package for the Time Logger application as well. I'm hoping the categories package will finally serve our need for a site-wide-category service in OpenACS.

I think adding some of these capabilities to the PERT/CPM functions could be useful for dynamic projects where multiple outcomes or operating conditions need to be considered/managed.

Let me know if this doesn't clarify things. I'm coming from a fairly abstract perspective, so I might have to write a few iterations to express myself clearly. =)

Gert is an less restrictive network diagram (PERT/CPM). From what I've read so far, Q-GERT seems to be the most popularly accepted revision, and is available as software called the same (I'm still looking into this).  I haven't found any really useful web references, though I'll be looking into some books in the next few weeks.

With Gert, some looping (repetition) of tasks is acceptable  Branching of network at sub-nodes is permitted, also. One might branch at a node, depending for example, on environmental circumstances not within control of the project: path A might be chosen over path B because C indicates A will not work (where the decision could not be previously determined). Each branch is given an estimate of likelihood for occurring (statistics based on history will improve accuracy of course).

WBS = Work Breakdown Structure.  WBS is the categorization/subcategorization of the project to tasks, before attaching scheduling and dependencies (order of implementation). Basically, the WBS answers the questions: What needs to be done to complete the project? Who will do each task?  How long is  each task (time)? What resources are required (costs, materials etc.)?

"Ongoing projects" might be better referred to as Operations Management. Based on the morphology of systems engineering I've read from Arthur D. Hall, III, senior member, IEEE ("Three-Dimensional Morphology of Systems Engineering" April 1969), Operations Management is a subset of Systems Engineering, which I believe resembles Program Management. Program here, refers to very large projects. I think dotProject should be able to apply to most any phase, whatever its called. So, for purposes of dotProject, I'd like to see "ongoing projects" or "Operations Management" applications also addressed. However, I don't think that dotProject should adopt any specific phase structure or categorization labels (though adoption of some consistent terminology will be needed).

With Operations Management, one can see how tactical decisions affecting daily operations can be expressed according to planned node branches discussed with GERT above.

Operations Management might include running a website (after it has been developed), or producing Woodstock 2003, or distributing humanitarian aid, where there's a phase-in, repetitive (perhaps daily) operation that lasts an extended period of time (arbitrary for purposes of dotProject), then perhaps a phase-out.

I imagine dotProject will have its own Calendar expressed, with connects to the WBS, with GANTT chart and network diagrams etc. And that the various players who perform tasks and manage resources will have their own calendars (that may share with other projects or their own external schedule entries). Scheduling-flow will have to be created so that the individual views affect the overall calendar, and changes to the overall calendar institute changes to the individual calendars.

http://www.dgp.utoronto.ca/~jade/projectmanagement/dotProject_mockup.gif

It shows one idea for an initial page.

People who only wanted to look at tasks could close the project window, and vice versa.

Processes are a set of tickets, kind of like a set of ticket templates, that have dependencies on each other.

Users can easily reschedule multiple projects and tickets, and see charts and so on even between projects.

It's rough, but it's a start. I'd love some feedback on it.

Oh, and as far as a general roadmap:

- should we work out the basic interface first
- then data model
- then do it?

That's generally how I go about it, although I am doing a lot of thinking about the data model right now too, I guess.

If I get it right he basically suggests to strongly separate the things (tasks, fases, documents, resources) from the processes or process-look-a-likes (scheduling, reporting).

As for starting with the ui and then doing the datamodel; I'm not really in favor of that.

UI mock-ups are great, to visualize what you mean. But at some point I think those need to be abstracted and turned into a datamodel before we do any real ui work.

When there is a solid datamodel in place, creating a ui on top of it is fairly straight forward. This, in combination with Rogers line of thinking, also partly solves Carolines "problem" I guess:

"""An interesting philosophical question for dotWRK is are we trying to create a product that competes head to head with existing solutions or one that can be easily customized to meet non-standard requirements.  Or probably a better way to look at it is where on the spectrum between those two are we aiming for?"""

From my point of view, 'non-standard requirements' are often in the way things are presented - to bring it closer to the window of reference of that particular usergroup. On a more abstract level, e.g. the datamodel, it's mostly the same - give or take a few extensions. Am I wrong on this one?

As to competing 'head-to-head' with existing products - don't know - if this beast does what we (or our customers) want it to do then who gives a damn about the other products? If we're desperately try to mimic e.g. MS Project Server as closely as possible, one might as well just shell out the buck to buy the 'real thing'.

On another note, I really like Jades idea of categorizing tasks in order to get statistical info that can be used for forecasting. This aspect is really usefull if you're in the business of doing a lot of similar projects. At least, as long as your not _forced_ to put each and every task in a category (like in achievo, www.achievo.org).

As for dependencies, I've never found any real good use for the "can start after other tasks starts" type. There're a number of other dependency types (see e.g. MS Project) but I'd say that the other two Jade mentioned are the most used ones.

As for seeing an operational situation as an on-going project, well, strictly by definition this is indeed a no-no, though from a practical point of view I'm very much in favor of viewing an operational situation as an 'on-going project'. Especially in modern-day IT operations, with SLA's etc. One has for a particular period, a defined deliverable. It's like running a project each month, that looks very similar to the project you ran last month.

I think Torben indeed has a good point with the 'end-user autonomy'. A thing Torben touches, and is often overlooked imo, is client-participation. E.g. I've some projects that run mostly within the clients organisation (i.e. we offer expert advice and pm-guidance, most 'real' work is done by the client). Those projects are quite small, but 'feel' very large because of the organisational distance between you and the participants (most of whom you can only address through 'middleman'), and the fact that you often work 'cross-country in an island-culture' (if that makes sense to anyone?). In those cases it would be really valuable if all participants could access and manipulate e.g. the wbs and work fairly autonomous, while allowing overall oversight at the same time.

Then on the todo list/roadmap I'd see things like:
- compile a list of functionality we need and document
  a general idea of the architecture we're looking at
  (using an imaginary company, ui-mockups etc.)
- design and implement a datamodel that supports the above
- design and implement an api to use the datamodel
- create a number of applications for the
  end-user to work with the datamodel

My 2c so far, halfway the coming week things will calm down at work and I'll have time again available for dotwrk.

http://www.stevemcconnell.com/ieeesoftware/bp11.htm

After reading this, does it seem like a good option to include risks in the projects? This could be optional, and I'm not sure if this is a good idea or not.

Jade, in short, you answer your own question. Your "idea of categorizing tasks in order to get statistical info that can be used for forecasting" (as summarized by Jeroen).

I also agree that:

we should categorize projects too (optionally of course), so that a yearly project could be compared somehow to the last year's project.

Categorizing projects would also be very useful for tracking project progress ie. comparing current status with the original project plan; and for improving estimates ie. comparing project plan with project performance data.

Using the proposed copy-project function mentioned earlier in this thread, a "project plan" version could be created, then copied to create an "implemented project version X", which gets revised during project implementation. Then a "final-completed" copy could be made from the terminated project.

To visualize this, for a moment, consider a dotProject database as a 2 dimensional spreadsheet (should dotProjects be so simple!). Large spreadsheets usually go through a few revisions by "copying" the spreadsheet to a new name, where an additional report-spreadsheet summarizes and compares values.

General resources tracking

The following explanation extends beyond the scope of general resources tracking. My intention is to provide context for further discussion.

A WBS does not formally have an assigned sequence of events (dependencies) within a project. Though developing an ordered list is possible in some cases. Sequential order is determined through scheduling and building the activity networks. The WBS refers to activities (action), whereas the Resource Type refers to either "action by" or "action on" objects; The only exception are labor Resource Types, which consist of skill-based action descriptions, such as "inspecting", "installing", "welding" etc.

Tracking resources by price is a way of cost estimating, where resource categories and the WBS are associated with payments (or parts thereof). For example, a construction remodeling company might write a check to a supplier for $5,000. In the books, the payment would be associated with a collection of expenditures resembling the associated itemized invoice(s). Each expenditure would then be related to a job-site, WBS code, resource type, and date purchased.

Expense Ledger
item ref   : item to             : project : WBS              : Resource type                  
20020418.5 : Supplier Corp       : SR2101  : 24.576.10.1.6.12 : FramedStructure.Windows(2.8.1) 
20020418.6 : Sub & Daughters : SR2101  : 24.576.10.1.6    : *                              

However, costs do not let you know how resources are being used compared to the project plan. Continuing the above example, installing windows may have been budgeted at $5000. The actual cost may have been $5000 with labor taking a few extra hours and using less quality materials (or maybe left out some materials or used less qualified labor etc.). Project managers need more detail.

Earned Value Analysis offers that detail. Resources are tracked by units consumed. Scheduling complies with any consumption or resource availability constraints. Labor resources are consumed by time (hours). Materials consumed by "unit" sometimes linear foot, each, square-meter etc. Machinery might be rented by the day. A fabrication company might have a start-up fee for each day's work (cost/day) etc.

Essentially, each consumption or task can be made of other consumptions and tasks. Continuing the example:

Payment ref 20030418.5 to Supplier Corp.
QTY : item absolute ref : project : WBS              : Resource type                           
  5 : 20x20vinyl window : SR2101  : 24.576.10.1.6.12 : FramedStructure.Windows(2.8.1)           
 12 : 4 x 6 headers     : SR2101  : 24.576.10.1.6.12 : FramedStructure.Windows.headers(2.8.1.2) 

Payment ref 20030418.6 to Sub-contractor & Daughters Co.
QTY : item absolute ref    : project : WBS              : Resource type                  
5   : 2 hrs install window : SR2101  : 24.576.10.1.6.12 : house.labor.carpentry(2.3.4)
0.5 : window inspect       : SR2101  : 24.576.10.1.6.10 : house.labor.inspection(2.3.19) 

"item absolute ref" could refer to a line of a bill of materials ie. bill of resources which could consist of other "child" bill of resources --this option is especially useful for manufacturing project management and product development.

Using Earned Value Analysis, various useful reports can be made based on WBS, resource usage (by category), and project. One can track schedule, costs, and budget variances to manage projects. Deviation from any of these 3 can significantly affect the project.

The WBS is likely to vary in depth (resolution) --depending on the level of detail of each job(project) --which varies by price, size and other factors. So, reporting should be able to provide statistical analysis at choice depths. For instance, some remodeling jobs might be replacing nonstandard windows with standard windows. "Standard windows" might be one categorization. "Custom windows" might be another categorization. Labor would be a resource associated by WBS, resource category/task/role, and project. For estimating purposes, it might be useful to know the rate for replacing all windows, versus installing windows in new installations. Collecting this flexible level of data can help answer these and many other questions while not compromising operational demands.

With PERT, resource scheduling is priority; Schedules are built to minimize the critical path (and time) resulting in fastest completion time of project.

If project performance is higher priority than speed, other heuristics can be used to determine resource allocation. The "minimum slack first" prioritizes by ordering activities with least amount of slack first. Secondary sort is commonly "shortest task first". Some researchers (references follow) conclude this sorting method is most consistent in finding "best" allocation of resources, while minimizing scheduling delays, and resource scheduling conflicts for other projects.

• Fendley, LG "Towards the Development of a Complete Multiproject Scheduling System" Journal of Industrial Engineering. Oct 1968
• Kurtulus, I and EW Davis. "Multi-Project Scheduling: categorization of heuristic rules performance." Management Sci, Feb 1982.
• Kurtulus, I and SC Narula. "Multi-Project Scheduling: Analysis of Project Performance" IEEE Transactions on Engineering Mgmnt, Mar 1985.

PS. At some point it would be helpful to have dotProject (and the categorization package) include ability to import/export categorization trees via xml or soap.

the data model

Analyzing the general resource tracking, I see 3 separate categorization trees: Project, WBS, and Resource Type --each built from top-down, with increasing detail or depth-- and a bill of materials (BOM) tree --where part A is made of parts B, C, D and labor E and F.

At first, I was really concerned how the 3 separate categorization trees would impact scalability for dotProject. However, since these lists remain fairly stable over time, I think each of these trees can translate to a simple table with columns: reference, reference title, and perhaps reference abbreviation --if needing to integrate with existing alternate reference system.

Project categorization table example
Reference : Title
1         : planning
1.1       : progress, rev.0
1.2       : progress, rev.1
1.3       : progress, rev.2
1.4       : final

WBS table example
Reference   : Title
1           : Super WBS
1.1         : Construction WBS
1.2         : Space Shuttle WBS
1.3         : Open-air production WBS
1.24.576    : Job SR2101 Remodeling WBS
1.24.576.10 : renovate exterior walls

Resource categorization table example
Reference : Title
1         : Other, Super catch-all
1.2       : House
1.2.8     : FramedStructure
1.2.8.1   : Windows
1.2.8.1.2 : headers
1.2.3     : labor
1.2.3.4   : carpentry
1.2.3.19  : inspection

The BOM's tree could similarly convert to a flat table, for example as engineering design phases out and production/assembly is phased in. Of course, many projects wouldn't generate a BOMS tree anyway, but it's value in dotProject would be significant.

These general ideas apply to a majority of projects I have encountered. I believe they are applicable to many others too. Please let me know if I haven't presented this clearly, as I think careful consideration of these topics now could significantly reduce changes to dotProject later.

1) Could you post your data model somewhere once it's in a state we can look at? I think agreement on the data model is a good first step for this project.

2) I'm now usually against creating new Forums for new topics, but I think it makes sense in this case. It would make it much easier to sort through the postings and figure out what is dotWRK related. Those posting have a much higher priority for me.

I was planning to use the new workflow system.  However I am not sure where it will fit in at this point in time.  I must admit I haven't used either of the workflow or bug tracking packages.  I would appreciate any suggestions of how we can tie these packages into the system.

Cheers,
Nick.

I know that it was ditched a kzillion times, but is aD project-tracker really such a pile of manure that nothing could be re-used?

I have tried (never finished) to port it to Pg about a year ago, it was extremly limitted (aking more to what bugtracker does, rather than proper project mgmt), but stil...

Just a €0.02...

With respect to the four 'tables' - aren't those actually four 'object types' or 'content types'? I.e. what I'm hinting at would it make sense to model them as content-types, leveraging the CR (trees of objects/workitems ...) ?

What I'm currently (still) playing with is the idea, and implementation of it, of having something like 'file-storage' but then for any content-type. I won't go into details now - as soon as I've something that looks and feels like what I've in mind (it currently looks mostly like a nice demo of acs exception traces 😊 I'll post a demo-link.

I really like the new Bug Tracker and Workflow and definitely agree that is the technology that should be the starting place for any project management package. I'd like to learn more about what the difference between starting with Workflow and starting with Bug Tracker means. I haven't looked deeply at Workflow and Bug Tracker yet, can you help us understand what functionality is in which package?

Is your vision one of the following?

1. The Project Tracker package would have dependencies (built on top of) both Workflow and Bug Tracker
2. One package that could be configured as either a Project Tracker or a Bug Tracker
3. Two similar packages; Bug Tracker and Project Tracker, and both depend on Workflow

Each table is an object type.  I'm actually having problems writing a tcl procedure that recursively pretty prints the structure of the projects and their respective sub-projects. eg...

Project A
    Project A1
        Project A1.2
    Project A2
Project B
    Project C
etc.

When I display the page that calls this procedure, the whole OACS application crashes.  The algorithm looks sound, but its probably due to poor tcl coding.  Haven't used the upvar command... not sure what it does.  I've seen a few recursive examples that use this though.

Cheers,
Nick.

How do you create the hierarchy in the first place with acs_objects?  As I haven't implemented this part using acs_objects.  I was planning on doing this myself with a "parent_id" column in the projects table.  Are you meant to manipulate the tree_sortkey in some way?

Thanks,
Nick.

Tasks should allow you to enter either (your choice):
--------------------------------------------

Estimated completion time
      OR
Optimistic, Estimated, Pessimistic completion time.

This will allow us to create PERT or CPM charts, depending on what they enter. We can also compute confidence intervals (which as far as understand it, is the chance that we will meet the projected deadline).

Should tasks be hierarchical?
------------------------

It seems to me that it might be nice to provide a "Breakdown" option on tasks. That way, either the project manager or the individual concerned can break down a Task into several smaller Tasks. It would be nice to have the option to progressively break down a project into smaller and smaller pieces of work.

WBS
---

It looks like it's kind of standard practice to break down the Tasks using a decimal place system, where the number of the task shows the hierarchy of the tasks. So I guess having tasks hierarchical does make sense.

For example, 3.2.5 is a Task that is a subtask of 3.2.

However, at the company I work, I seriously doubt that people would accept numbers like 132.417.3135.31 as a unique identifier for a Task.

We use tickets currently, and people really like being able to refer to it by a number. They even use the number in ways I didn't forsee, like using it to keep track of what's being sent out to customers. I'd personally much prefer a unique identifier on each ticket to a long code. Perhaps that can be optional as well? Who would want the longer codes?

Projects and Tasks
----------------

I toyed with the idea of having these be the same thing. I don't think it makes sense, however, because there's going to be information about a project that you wouldn't need to keep track of for Tasks. I think.

What would some of that information be?

Deliverables - could be in both
Goals - could be in both
Team members - could be in both
Territory (northeast, northwest, california, etc) - not in both.

Hmmm, I'd like to hear other people's thought on this. However, right now it seems like it's not a good idea.

WBS
---

There seems to be some disagreement in the field about whether to have WBS be a list of deliverables ("nouns"), or a list of activitiess and their dependencies.

I think we should allow flexibility either way. Our company probably will want to break everything down and build the dependencies right away. Others might not. I'm not so sure how hard or easy this is going to be to do.

Individual member goals
---------------------

Team members:
- I'm scheduled for more tasks than I can accomplish today. I want to know which task is most critical. Which tasks affect other people (critical path), and which ones have hard deadlines?
- I want to be able to see my schedule for several months out, and see if I'm over or underscheduled at any particular time.

Managers and Project managers:
- When I'm scheduling the tasks of a project, I want to make sure I'm not overscheduling an individual team member. I want to see how an individuals' scheduling will affect my deadline date.
- I also want to see who's doing what on a project, and if it is on schedule. I'd like to know how likely it is we'll meet the deadline. I'd like to know if there are any problems that I need to address.

Milestones
---------

Do we want to separately track important dates and milestones? I guess these should just be tracked as part of the WBS.

Scheduling again
--------------

We're going to eventually need a calendar tie-in. What about holidays, for example? They are going to affect the scheduling of Tasks, and affect deadlines, etc.. Also, what if a person goes on vacation?

Here are some listed cons to MS Project
---------------------------------

(from the project management class link earlier)

- Illusion of control
- Workgroup features ok, still in-progress
- Scaling
- No estimation features

-------------

And we're in agreement that we're going to use:

- content repository
- workflow / bugtracker

Right?

Projects and Tasks

These are considered different animals. A "program" consists of many projects. A project consists of smaller projects or tasks.  Tasks can also consist of other tasks.  Resources consist of the lowest level of tasks, and materials, and may also consist of higher-level tasks (if not subdivided further by the WBS for a particular project).

There is some ambiguity depending on how one defines these terms --clients I have worked with have defined them differently and sometimes completely opposite of each other. For example, one client's "task" might be another's "process", or "procedure"; And one's "job" might be another's "project".

At some point soon, we should set some general definitions for dotProject so we can be clear on what we're talking about.  The actual name shown in any displays and reports (I call them Titles) should be defined on a "package mounted" basis (to keep them consistent within a project system).

In the lowest WBS resolution, tasks are unit-based (as defined in the resource table).  They generally do not have the granualarity of a project within the same project environment or else they would be projects in their own right, and consisting of more specific tasks.

Hopefully, I have the terms straight this time.

ps. Lewis refers the WBS more precisely as a "list of activities" ("Project Planning, Scheduling, and Control", 3rd Ed.c2001.)  From a complete WBS, the PM continues by adding material resources and creating scheduling networks for estimating...

My standards are pretty low for sharing work (so this is a little sloppy), but it might move the conversation along a little bit.

First, some caveats:

- I didn't tie things much into the object system. Of course we would do that, however.

- I have not yet added the following
  * workflow
  * content repository
  * constraints with pretty names
  * etc..

- this is just a dirty data model for discussion.

--------------

--
-- packages/dot-project/sql/postgresql/dot-project-table-create.sql
--
-- @author mailto:jader@bread.com
-- @creation-date 2003-05-07
-- @cvs-id $Id$
--

-- use categories package to keep track of types of projects

-- use categories to keep track of the status of the project too?
-- closed projects, research projects, in-progress projects?

create table dp_project (
    project_id        integer
                constraint dp_project_id_fk
                references acs_objects(object_id)
                constraint dp_project_id_pk
                primary key,
    -- for subprojects
    parent_project_id      integer
                references dp_project,
    title              varchar(255)
                constraint dp_project_title_nn
                not null,
    goal                varchar(4000),
    description         varchar(4000),
    start_date          timestamptz,
    end_date        timestamptz,
    ongoing_p        char(1) default 'f'
                constraint dp_project_ongoing_p_ck
                (ongoing_p in ('t','f'))
);

-- could be called project template

create table dp_project_plan (
    -- contains all the items project does, and perhaps a few more.
    -- can be copied to make a project.
    -- hmmm, they should then be categorized as having come from that
    -- template
);

-- slack time be always computed, and therefore not in the data model?

create table dp_task (
    task_id        integer        primary key,
    parent_task    integer        references dp_task,
    description    varchar(4000),
    -- dates are optional, because it may be computed in reference
    -- to all other items
    start_date    timestamptz,
    end_date    timestamptz,
    deadline    timestamptz,
    estimate_hours_work    number,
    estimate_days_work    number,
    -- these are used for PERT type charts, optionally
    estimate_hours_work_min    number,
    estimate_hours_work_max number,
    estimate_days_work_min    number,
    estimate_days_work_max  number
);

-- use ACS groups to make the roles of various users, or use roles?
create table dp_role (
    -- description of roles (manager, etc..)
)

create table dp_task_assignee (
    task_id        integer        references dp_task,
    user_id        integer        references person
    role_id        integer        references dp_role
);

create table dp_task_dependency_type (
    dependency_type_id    integer        primary key,
    description        varchar(200);
);

-- would add in start_to_start, start_to_finish, finish_to_start,
-- finish_to_finish

create table dp_task_dependency (
    task_id        integer        references dp_task,
    parent_task_id    integer        references dp_task,
    task_type    integer        references dp_task_dependency_type
)

-- processes are templates for a set of tasks. For example: deploy website.

create table dp_process (
    -- not defined yet
)

You ask: use categories to keep track of the status of the project too?

Yes and no. "project status" as a declaration, yes. This project is set at the "X" mode: pre-start, active, final, active-revision 2 etc. --realizing that each category has a separate set of data, so that project data can be used for simulation and analysis by stakeholders. I think the categories package would not track project status for the majority of roles.  Instead, each project would have a "stated" project-status. The chosen declared status would dominate as the current project that all scheduling and other actions would interact with. Otherwise, imagine the confusion as participants try to figure out how to associate resources and materials to multiple versions of projects?

We should start a list of defined terms. Meanings will change somewhat within roles, so we'll need to note any context. For PMs, I expect a "project status" to include some indexed based numbers and trend charts --information that helps a PM determine status --in addition to the PM declared status.

Looking at your honorable datamodel start, I am not sure about the separation of time and day time-units. I don't know about the performance implications from a scalability perspective, but I would think time calculations would be faster if a numerical date were used (assuming timestampz fits) where whole units are days, and hours-units are 1/24th day, much like spreadsheets. Perhaps the alternate of representing everying in fractional seconds is fastest from a machine perspective? In any case, relative times would be represented numerically in the same units or as a percent. As long as it's consistent, relative values can be  added to absolutes etc. as needed.

You ask:  slack time be always computed, and therefore not in the data model?

I envision slack time requiring two fields: a relative time-value (RTV), and a calculation field. For simple projects, the calculation field might default to 20% or something. The RTV would only be recalced on trigger of a change in the calc field or the time estimate.

You ask: use ACS groups to make the roles of various users, or use roles?

As I understand it, ACS groups handles permissions only. Even if I am wrong with that assumption, I expect there will be some additional data modeling needed for task-roles, where task-roles have resource and labor qualities.

I think you're on target with the suggestion of creating views that highlight different priorities. Let's define the role types etc. then work on the output objectives.

-- Project repository datamodel.
create table projects (
    project_id                  integer
                      constraint projects_id_fk
                      references cr_revisions on delete cascade
                      constraint projects_id_pk
                      primary key,
    owner_id            integer
                constraint projects_owner_id_fk
                references users(user_id),
    project_name        varchar(250),
    author            varchar,
    category            varchar,
    company            varchar,
    status_date            DATE,
    manager            varchar(250),
    subject            varchar,
    hours_per_day        integer,    -- 0 to 24
    days_per_month        integer,    -- 0 to 32
    week_start_day        integer,    -- 0 to 6
    year_start_month        integer,    -- 0 to 12
    hours_per_week        integer,    -- 0 to 168
    planned_start        DATE,
    planned_finish        DATE,
    planned_duration        integer,
    planned_work        integer,
    planned_cost        integer,
    actual_start        DATE,
    actual_finish        DATE,
    actual_duration        integer,
    actual_work            integer,
    actual_cost            integer,
    baseline_start        DATE,
    baseline_finish        DATE,
    baseline_duration        integer,
    baseline_work        integer,
    baseline_cost        integer,
    remaining_duration        integer,
    remaining_work        integer,
    remaining_cost        integer,
    acwp            integer,
    bcwp            integer,
    bcws            integer,
    start_variance        integer,
    finish_variance        integer,
    cost_variance        integer,
    early_start            DATE,
    early_finish        DATE,
    late_start            DATE,
    late_finish            DATE,
    total_slack            integer,
    free_slack            integer
);

-- Procedure new project
create function project__new (varchar, integer, integer, varchar, timestamptz,
                              integer, integer, varchar, varchar, varchar,
                              varchar, varchar, varchar, varchar, varchar,
                              varchar, boolean)
returns integer as '
declare
    p_project_name    alias for $1;
    p_parent_id        alias for $2;
    p_item_id        alias for $3;
    p_locale        alias for $4;
    p_creation_date    alias for $5;
    p_creation_user    alias for $6;
    p_context_id    alias for $7;
    p_creation_ip    alias for $8;
    p_item_subtype    alias for $9;
    p_content_type    alias for $10;
    p_title        alias for $11;
    p_description    alias for $12;
    p_mime_type        alias for $13;
    p_nls_language    alias for $14;
    p_text        alias for $15;
    p_storage_type    alias for $16;
    p_is_live        alias for $17;

    v_item_id        integer;
    v_revision_id    integer;
begin
    v_item_id := content_item__new (
    p_project_name,        -- name
    p_parent_id,        -- parent_id default null        ->null
    p_item_id,        -- item_id default null            ->null
    p_locale,        -- locale default null            ->null
    p_creation_date,    -- creation_date default now        ->now
    p_creation_user,    -- creation_user default null
    p_context_id,        -- context_id default null
    p_creation_ip,        -- creation_ip default null
    ''content_item'',    -- item_subtype default ''content_item''
    ''project'',        -- content_type default ''content_revision''
    p_title,        -- title default null            ->null
    p_description,        -- description default null        ->null
    p_mime_type,        -- mime_type default ''text/plain''    ->null
    p_nls_language,        -- nls_language default null        ->null
    p_text,            -- text default null            ->null
    p_storage_type        -- storage_type                ->text
    );

    v_revision_id := content_revision__new (
    p_title,        -- title
    p_description,        -- description
    p_creation_date,    -- publish_date
    p_mime_type,        -- mime_type
    p_nls_language,        -- nls_language        ->null
    NULL,            -- data
    v_item_id,        -- item_id
    NULL,            -- revision_id
    p_creation_date,    -- creation_date
    p_creation_user,    -- creation_user
    p_creation_ip        -- creation_ip
    );

    insert into projects (
    project_id, owner_id, project_name
    ) values (
    v_revision_id, p_creation_user, p_project_name
    );

    if p_is_live = ''t'' then
      PERFORM content_item__set_live_revision (v_revision_id);
    end if;

    -- Change admin to manager?
    PERFORM acs_permission__grant_permission (
        v_revision_id,
        p_owner_id,
        ''admin''
    );

    return v_item_id;
end;
' language 'plpgsql';

Should have posted it up earlier, but have been busy with other projects.  The datamodel isn't complete, which is why I haven't released anything.  But I guess some feedback would be useful before I make any further progress.

Cheers,
Nick.

Chapter 6 discusses integrating various statistical distributions in the Fortran IV program. The program is not listed, but the purpose and requirements of routines are described --as well as variables/fields. In line with Jade's model, he designates min and max slack-time fields as overall time duration of activity instead of (my proposal of) time difference (ie max duration less min duration) where min is the estimate value. Of course I'm just skipping through the book at this point. Perhaps he's just emphasizing the statistics calculations in this part... I have much more reading to do.

create table projects (
    project_id    integer
                 constraint project_id_pk
                   primary key,
    project_code  varchar(20)
                  constraint project_code_nn
                    not null
                 constraint project_code_uq
                   unique,
    name         varchar(100)
                 constraint name_nn
                    not null,
    --A project starts off as unapproved. Must be approved before tasks are scheduled.
   status        varchar(100)
                   default 'Pending Approval',
   mfg_po_number varchar(100),
   --The sponsering (paying) entity for this project
   manufacturer_id       integer
                         constraint manufacturer_id_nn
                           not null
                         constraint manufacturer_id_fk
                           references manufacturers (manufacturer_id),
   --This restricts a project to one company.
   --Its usefull because now the company can own the calendar and the survey
   --However, if they ever want to share a project between companies it will be hard.
    company_id           integer
                         constraint company_id_nn
                          not null
                         constraint company_id_fk
                           references companies (company_id),
   team_type_id  integer
                         constraint team_type_id_nn
                           not null
                         constraint team_type_id_fk
                           references team_types (team_type_id),
   --For book keeping only. Not used right now. Use team type and shifts.
   est_man_hours         integer,
   --Crew's can't leave during a shift and might do overtime so we collect how many shifts separately.
num_shifts            integer
                         constraint num_shifts_nn
                           not null,
   -- Completion Survey that teams will respond to when they finish each task.
   -- This will be from a hard coded master survey at least for the first round.
   calendar_id           integer
                         constraint calendar_id_nn
                           not null
                         constraint calendar_id_fk
                           references calendars (calendar_id),
   photo_folder_id       integer
                         constraint photo_folder_id_nn
                           not null
                         constraint photo_folder_id_fk
                           references cr_folders (folder_id),
   comp_survey_id        integer
                         constraint comp_survey_id_nn
                           not null
                         constraint comp_survey_id_fk
                           references surveys (survey_id),
   notes_survey_response_id      integer
               constraint notes_survey_response_id_fk
                           references survey_responses (response_id),
   department_id           integer
                           constraint customer_departments_fk
                         references customer_departments (department_id),
   store_type_id          integer
                        constraint store_type_id_fk
                        references store_types (store_type_id),
   --Eventually we may need to put work hours in a look up table. For now choices are set in the ad_form.
   prototype_pa_album_id integer
                         constraint prototype_pa_album_id_fk
                         references cr_revisions (revision_id),
   work_hours           varchar(100)
);

Project_code and Project_name: This is like short name and pretty name, or Key and pretty name. There tends to be a key that accounting systems and such use for each project.

Status: If I was starting now I would definitely use Workflow for status NOT store it here. I hope to get funding on this project to transition to workflow. I very much believe it can provide value to my client.

mfg_po_number: This is the PO number of my client's customer. Each implementation will have random pieces of information totally specific to that site, or even that project. It would be far better to have a general way of collecting, editing and displaying them then to put fields in the data model like this. Work on making attributes more functional perhaps?

Department_id: This is a nice obscure one. It refers to a set of look-up tables that model our client's customer's internal set of departments, and sub-departments that they use for keeping track of their inventory. If Categories were available when we wrote this I think that is what we would have used. Another important point for dotProject is each project may be classified on totally different category trees for each different type of stake holder.

Manufacturer_id, Company_id: Customer_id. For this site these are the stakeholders in the project. In We represent them all as groups and each has its own table with some extra info. One issue we have already run into is that a Project needs to be associated with more then one Manufacturer, or Company. For dotProject we should probably use rels to relate projects to their stake holders. This will should be the most flexible solution and will help dotProject use the toolkit.

Team_type_id: In this case each project requires a certain type of team (2-man, 4-man, reset team, etc.). The team types are stored in a look-up table. I think if we were doing it over I'd use categories for this.

Estimated Man-hours, num-shifts: In this use case they frequently schedule assuming overtime. Work rules and the sorts of estimates needed are going to vary a lot from industry to industry. For instance if this system were to expand we might end up modeling the overtime laws in each state. We may want a more general solution then trying to put all the combinations into the data-model.

Work_hours: This is currently modeled as a look-up table of things like 5pm to 12am, 7am to 4pm etc. A bad late patch for a requirements change. Something we should think about is how to model "when is work allowed to take place". There is both the issue of working hours (only days, only nights) and the issue of work days (what holidays do you observe, is it a project or task that can ONLY be done on weekend and holidays).

Calendar_id, photo_folder_id: One of the important roles of dotProject will be to provide a framework that lets you elegantly use all of the functionality of the toolkit. In this instance we are using Calendar, Survey and Photo Album. Using one instance of each package then putting the id in the model like this is very much WRONG in my opinion. It was a fast simple solution implemented to get results quickly before dotLRN 1.0 was released. dotProject should follow the dotLRN model and extend it to use rels to relate objects such as calendars, photo albums, surveys to one or more projects and tasks.

Use of Calendar: I personally think acs_events should be used to store all time related info. I suggest considering moving the project start-time and end-time to the project's calendar. I think once we start apply dotProject to real use cases we'll see an explosion of date related info that needs to be stored. For instance for our use case we need to store Material Arrival Date. A few other common dates would be, billing dates, current .contract start and end dates, no work days, meetings, deliverables etc. We use calendar items with specific item_types to keep track of project dates. We never end up using any of the pages in the calendar package but we use the api's and modified forms of the widgets extensively. It doesn't' make sense to duplicate date handling functionality.

Survey: We used survey in two different ways. The first is each project has a list of documents that are supposed to be associated with it. For instance, building plans and material lists. These need to be named and displayed consistently for all projects and File Storage provides too open ended an interface and makes it too likely that different people would name the documents differently. Thus we created one survey with a bunch of file type questions and each project has one response to this survey. It was quick and easy and survey has nice tcl api's.

The second (and probably more appropriate) way we used survey was to create one "completion survey" for each project with each task creating one response when the task is marked complete.

Photos: An extremely important part of this project was collecting and displaying photos of completed tasks. We used one folder per project with each task creating an album. One interesting requirement is in addition to one album per task, there also must be an album of "proto-type" pics that are at the project level and show what the end result is supposed to look like. Use of rels to relate photo albums and folders to projects and/or tasks would be a much more elegant and scalable way to use the tool kit then storing all the ids in the projects table.

I will try to post our Task data model and a similar discussion soon. Please don't take these data models as a starting point, rather to use them as an example of some of the issues in a real life use case.

The things I want to emphasize:

• Have dotProject be a tool for organizing packages and never repeat existing ACS functionality.
• use calendar to manage date information.
• use workflow to manage status information, including auditing when status changes and who makes the change.
• never put a constraint to users, always use parties so there is flexibility whether it’s a user, person or group.
• Mapping tables and look-up tables are not that scalable, expensive to maintain and requires that you have programmers for each new field you want to add, and each new filter on reports. I recommend dotProject minimizes these and work instead on improving the toolkits functionality and flexibility in areas such as rels, attributes, categories, list builder etc.

-Caroline
(with input from Rocael and Dave Bauer who will also be posting with more details)

Yes I think this is why we need to think in terms of scheduling resources. Resources are going to be available sometimes and not others. MS Project does a good job with this, and I think we can do something similar.

Can you describe how rels work a little more? I guess I'm unfamiliar with them. Or refer to where I could learn more about them?

Caroline suggest we use acs_events to keep track of all date related activity. I'm willing to do this, I guess, but that's another piece of software I'm not familiar with. Can you describe a little more what advantages acs-events would give us?

I like the idea of completion surveys for projects. This should probably be optional, however.

Interesting thoughts about photo-albums. Makes me very curious about rels.

Good point about users vs. parties

I'm not sure I completely understood your point about mapping points and lookup tables. Where are these used? Is this something one of the data models?

Thanks for all of your points, Caroline. It's very helpful to have real-world examples to work from (and your real-world experience in creating it). I look forward to Rocael and Dave's postings too.

http://rubick.com/openacs/project_management

Please do your best to rip it up, and provide as much feedback as possible. I'd love to whip this thing into shape!

Would people prefer that I post it here, so that the iterations of the code are preserved? Or is it better to keep this thread clean?

http://rubick.com/openacs/acs_rels

I'm also working on organizing all of the ideas people have presented in this thread. It's in progress, and will change a lot especially the next few days:

http://rubick.com/openacs/project_management/

I welcome feedback on these pages.

Question:

- what parts of the data model should be using the content repository?

http://rubick.com/openacs/project_management/use_case

• PMS (Project Management Super) with super pronounced like sue-pear.
• OpenProject (because everything that's open sourced should be called Open)
• dotPM
• project-manager
• PPM (Perfect Project Management)
• PPPM (Pretty Perfect Project Management) or 3PM (it's three o'clock, do you know where your projects are?)
• OnTime
• OnSchedule
• ProjectTracker
• InSync (The project management software that sounds better than a boy band)
• LockStep (keeps your organization's people running in lock step)
• Rowboat (somehow I get a mental image of a bunch of people rowing together)
• InMotion
• DProject (for distributed project management)
• Oaks Project (from OACS Project Management)

I've looked at your code and it is very similar to what I've done... which was modify the Notes package.  The main difference is that I'm using the content repository instead of ACS objects directly.  I'm just having problems with creating the project hierarchy, which Ola demonstrated above with his sample code.  The indented_name isn't being indented.  Once I've worked this out I'll contribute my code to CVS as well.

Cheers,
Nick.

How would I go about merging my code with yours?

Should I just check it into /contrib for the time being?  If so would you be able to tell me how I would do this?

Cheers,
Nick.

I'm just creating hierarchical project folders, so it is independent of your data model.  So the merge shouldn't be a problem.

The folders should contain resource items, task items, and a project description item.  These items can be added when viewing a specific project folder (view page).  I think we'll stick with your datamodel for the time being Jade.  My tables just have too many columns, and plpgsql functions don't take enough arguments (16).

That's my plan for the short term.

I'm not really a UI person.  My templates are really simple at the moment.

I've checked out your code, and making the modifications now.  I'm getting rid of the acs-objects code, and replacing it with the content  repository stuff.  I'll try and check the changes into CVS over the weekend.

- Nick.

Instead of porting room-reservations to OpenACS for dotWRK (which I believe nobody has done), make a more general scheduling application:

Here's what it would do:

It would allow you to schedule:

rooms
users
etc..

It would need some sort of service contract for you to use new "types", like users, with it.

Imagine this for an Intranet. You want people to schedule when they're available, and for how long. You set it up to automatically schedule people in for their schedules, 9-5, 5 days a week for full-timers. Then other apps, like our project manager, could query it through the API, and see how available that resource is.

This would have to be written carefully. It is very similar to the calendar app in a lot of ways. You want to be able to have almost any time of object be able to be "scheduled".

Anybody willing to write this for dotWRK?

I think this is a really important item for dotWRK -- we can't compute how long a project will take to accomplish if we don't keep track of people's schedules, for example.

It looks pretty simple to code. I think we should probably make this a small package of its own. It seems like a candidate for inclusion in the core, but I guess that's not my call.

acs-events doesn't handle any of this, does it?

The next step will be to work out how to incorporate work flow into the package, so that we can manage projects through states (proposal, open, closed).  This may take me a few more weeks.  Not sure how to use the workflow package yet.  Isn't there a new workflow package that I should be looking out for?

Another item on the "to do" list is design a better looking UI.  Should we bother with this now?  Or when there is enough functionality in place?

I would like to code the tasks stuff, unless you would like to take that on board.  I've been keen on writing some code that generates a Gantt Chart.  The Gantt Chart could very well be an HTML table.  However I will be looking into other display methods such as SVG, Java Applet, or generating a TIFF image.  The Gantt Chart will no doubt be tied in with tasks, so I would like to get involved with this part of the project.

Cheers,
Nick.

I will try and write up some documentation on the content repository in a theme similar to your workflow document.

In fact my supervisor wants me to concentrate on producing some documentation on where I am heading with this.  So I won't be churning out code over the next couple of weeks.  I think it would be a good opportunity for me to put down on paper the design/architecture of project-manager.  At least this will provide some food for thought.

In the mean time I will finish off the "edit project" functionality.

Cheers,
Nick.

Questions:

1) Who has experience with Workflow? Is it just Lars and Peter? I'd really appreciate it if someone could help me navigate this a bit. I promise not be a pain, and in exchange, I'll provide some documentation on how to add workflow to a project. I'll also be there to help out others who try to add Workflow to their project!

2) Is it difficult to add Workflow to a package after the fact? Is this a mistake?

3) Peter suggested using Workflow for Tasks. That makes sense to me. Should we also use Workflow for Projects?

Nick, unless I hear otherwise from you, I'm going to proceed to add in Tasks and Workflow. I'm going to be able to devote a lot more time to this in the next 6 weeks, so hopefully things should be kickstarted a little bit.

1. First of all, he'd like to be able to link Tasks and time logged in Logger. (jadeforrest: i definitely want a way to link time in time-logger to a bug in bugtracker)

2. He thinks maybe we can set up projects as keywords, which then can be used globally by other applications, such as logger and bug-tracker. They might be able to be used as the Project for logger, and the Component for bug-tracker.

Any thoughts on this? Here's our exchange:

[13:02] > daveb: That's the biggest problem with all these packages. They don't talk to each other.
[13:03] > daveb: so logger doesn't know anything about bugtracker, and bug-tracker doesn't know anything about project-manager..
[13:03] <daveb> jadeforrest: right. it can be done ina  general way.
[13:03] <daveb> think general-links from the knowledge management stuff.
[13:03] <daveb> or just use cr_object_rels
[13:04] <daveb> you can link a cr_item to any acs_object.
[13:04] <daveb> similarly a site-wide category package would allow using the categories to define bugtracker bug areas and project areas and time logger projects.
[13:05] > I'm only vaguely following you.
[13:06] <daveb> you don't need to store the bug_id in the time-logger, for example.
[13:06] <daveb> store the bug_id and the time-logger item_id in an acs_rel
[13:06] > You could just link them using cr_object_rels (which I guess are like acs_rels)?
[13:06] <daveb> that way you can link two different objects.
[13:06] <daveb> yes exactly.
[13:06] > Okay, I get that.
[13:07] > However, linking the bug-tracker to the project-manager does seem like it will require a lot more coding changes, right?
[13:07] <daveb> why?
[13:07] <daveb> you don't need to directly link bugtracker to project manager.
[13:07] > I have to replace the components section with project-manager's Project table.
[13:07] <daveb> just allow links to objects from bugtracker.
[13:08] <daveb> some might be project manager objects.
[13:08] <daveb> jadeforrest: no. what you _really_ want to do is replace the components and projects with categories.
[13:08] > Tell me more :)
[13:08] <daveb> then bugs or tickets can be part of a category which happens to be a project.
[13:09] <daveb> bugtracker projects and components are already cr_keywords now in the latest version.
[13:09] <daveb> so you could use that.
[13:09] <daveb> i think :)
[13:09] > Hmmm, so you're saying that we create site-wide "categories", which are equivalent to projects.
[13:09] <daveb> the new category package isn't ready yet.
[13:09] <daveb> yes.
[13:10] > I don't know that much about the CR, unfortunately. Bugtracker projects and components are cr_keywords.. what does that mean.
[13:10] <daveb> it means that they are not bugtracker specific objects.
[13:10] > Does that mean they could link to "categories" instead of whatever projects you create in bug-tracker?
[13:11] > Oh, that's cool. I thought they were local tables specific to bugtracker.
[13:11] <daveb> well cr_keywords is the existing "categories" mechanism in the CR.
[13:11] <daveb> maybe they have local tables, but they should refer back to the CR stuff.
[13:11] > Damn, the problem is the more I learn about OpenACS, the more I have to learn.
[13:11] > :)
[13:11] <daveb> Actually everyone should start with CR
[13:11] <daveb> that is where most of the cool stuff is :)
[13:12] > Hmmmm, so if you were me, you'd spend some time studying the CR first, then figure out how to link all these applications?
[13:12] <daveb> yes.
[13:12] <daveb> of course I have spent 2 years on and off studying CR :)
[13:13] > Do you think I could use bug-tracker without forking it? I do have to add things to it, like dependencies between bugs
[13:13] > (for project-manager type Tasks)
[13:13] <daveb> well, consult with the author.
[13:13] > I will.
[13:13] <daveb> maybe they would like that too :)
[13:14] > I'm going to have to chew on this a bit.
[13:18] <daveb> i would definitely attempt to not fork anything.
[13:18] > Well, it would not really be forking bug-tracker, but taking bug-tracker and using it as an example for another application built on workflow.
[13:19] <daveb> anyway bugtracker is aimed to be more general purpose.
[13:19] > True
[13:19] <daveb> but still in the end you would have two packages with similar code.
[13:19] > Yes.
[13:19] <daveb> maybe you can build a package on top of bugtracker alsom using bugtracker as a service.
[13:19] > Which would be not good if it were possible to keep them together.
[13:19] <daveb> it might not be possible.
[13:19] <daveb> but definitely look into it.
[13:20] <daveb> anyway good luck :) bbl

I was just browsing the project manager data model. I see you are storing some project data information in the projects table. I would like to convince you to use the calendar package to manage dates.

It will be much easier to show the relationship of project date based information on a calendar if you store the data in the calendar package. Generally a canlendar view is one of the views you would use to look at date-based information.

I know the calendar datamodel could use some work, but I think the benefits of being able to store an arbitrary unlimited number of dates related to a project are very important.

A few comments after reviewing the latter:

I'd agree that more use needs to be put onto acs_rels to handle project resource grouping.  As mentioned above, I think that a good way to do it is to have resources pool assigned to a project, yet each task should get a separate resource assignment (including multiple resources to a single task, although this may mean that a task is not granular enough).

Dependancies: just an other-task-wise dependancy is not enough -- one may have tasks that are not dependant on any other tasks, yet do have constraints (like must-finish-before, etc.).  In that sense `constraints' maybe a better word indeed.

- Added in tasks (although editing tasks is not done yet). We also might want to add more values for tasks, etc.. Tasks are created under the project they are associated with.
- Fixed bugs / added in functionality to edit projects (revisions are created, but I haven't added in the interface yet to show the different revisions)
- removed content repository folder for each project (only one folder
per instance now)
- added in a style sheet (will take this out once an openacs-wide style sheet is adopted)
- renamed files in line with (my understanding of) openacs conventions.

I've also added in documentation on the project-manager page:

https://openacs.org/projects/dotwrk/project_management/

(under getting the code)

that details how to set up yourself as a developer for project-manager. It is specifically for people with write access right now. Other people can email me patches or suggestions.

Nick also let me know that his thesis direction had changed, so he'll still be contributing, but not as much as he was previously. I think as this matures, more people will want to get involved in it, but you're welcome to get involved even now if you are interested, and have some time and skills to spend on this.

Do you have links to any of the products you've described?

Unfortunately, I've already started work on the project-manager, so a lot of the data model has already been completed. It is open to being changed, however.

I strongly agree with you that flexible hierarchies are extremely important. I'm trying to build this into project-manager, but I'd appreciate any insight into ways this could be improved.

Right now, I'm trying to get as much accomplished on this as possible by the end of August. So although my focus before now was on collecting information, right now, I'm focused on writing it.

However, I do want to make sure we're on the right track, and I'd welcome your help in whatever form you're able to give it.

---

If you or anyone else is interested in keeping abreast of what's happening with the project manager, you can get email notifications on the project-manager to-do items and bugs from the bug-tracker:

https://openacs.org/bugtracker/openacs/com/project-manager/

The current implementation of project-manager has a hierarchy both of projects and tasks, to arbitrary levels.

So tasks can be easily broken down into subtasks, and projects into subprojects. I aim to make it easy to move this hierarchy around, and see how it works.

The project-manager is built on the content repository, so it allows symlinks between objects (such as the tasks and projects), so potentially, a task could be part of multiple projects, for example. This may provide the interface you're describing, although I'm not familiar with the products you describe.

The trick is mostly going to be in the UI. Designing scalable interfaces for complex hierarchies, with thousands of projects and thousands of tasks is the challenge.

https://openacs.org/projects/dotwrk/project_management/user_interface

Feedback welcome.

Help even more welcome!

If you'd like to help out, but only have a little time, you can look at the to-do list, and do one of the items. I keep the status of everything on bug-tracker, under project-manager.

I very much appreciate your improvements. I'll incorporate them into project manager either today or early next week.

I'm happy to see someone else is test-driving project-manager. Feel free to post ANY suggestions or bugs in the bug-tracker:

https://openacs.org/bugtracker/openacs/com/project-manager/

Please keep in mind this hasn't gone alpha yet, so with each release of project-manager, you'll need to drop the data model, and start afresh. Upgrade scripts won't be provided until it goes beta.

Even if you don't have time to code, feedback like Andrei's makes a world of difference in the quality of this product. I very much appreciate it!

I'm not yet using workflow. I didn't have the time to get it in, and Lars said it was always something that could be added in later.

I agree that another forum would actually probably be useful in this case. I understand the arguments against creating separate forums, but this thread is ridiculously long!

Malte, have you thought about using SVG? It's going to be pretty amazing what you can do with SVG. We could make dynamic applications that do everything Flash does, but interacting with the database. I'm very impressed with it.

Here's a new thread on updates to project manager:

https://openacs.org/forums/message-view?message_id=152379