============================== FIRST MEETING ON TASK PLANNING ============================== This file is a summary of the ideas and action items discussed during the first meeting on Task Planning in Radar. DATE: November 28, 2006 (3:30pm-4:50pm) PARTICIPANTS: Ulas Bardak, Jaime Carbonell, Scott Fahlman, Eugene Fink, Michael Freed (by phone), David Garlan, Geoff Gordon, Jordan Hayes (by phone), Cinar Sahin, Asim Smailagic, Stephen Smith, Aaron Steinfeld PURPOSE The purpose is to develop a Task Planner module, which will help the user to allocate her time; that is, it will help to decide on the priorities of tasks, and appropriate investment of time into each task. It may also invoke some required procedures automatically, which would prevent the user from omitting necessary actions. MAIN IDEAS -= Representation =- We need to develop a representation of the overall "Radar state," which describes the current progress toward organizing a conference and the remaining tasks. It may include a summary of the available and missing data, fully and partially completed tasks, quality of their completion, and pending tasks. The purpose of developing this representation is twofold: first, we will use it to provide a summary of the current progress to the user; second, it will allow reasoning about appropriate future actions. We also need to develop a representation of the main tasks and related actions, as well as a mechanism for reasoning about actions and their properties. The representation of tasks and actions may include their pre-conditions, dependencies on other tasks, expected time of completing each task, expected impact on the estimated score, and decomposition into smaller sub-tasks. We may potentially define two task hierarchies: the first would specify general tasks and their special cases, whereas the second would be an "abstraction hierarchy," which would show how to decompose high-level tasks into atomic sub-tasks. We may use Scone for representing tasks and actions, and for reasoning about them. Scott Fahlman and Cinar Sahin are already working on representing some tasks in Scone. We will use this representation for (1) learning properties of tasks and actions, (2) selecting appropriate actions for the current Radar state, and (3) learning of action-selection strategies. Note for discussion: I think we have not discussed whether "tasks" and "actions" is the same thing. I believe that we may need to distinguish between them, since tasks are similar to "goals" in planning, whereas actions are similar to "operators," and the user may have multiple ways of accomplishing a task. For example, improving a schedule is a task, whereas invoking an automated scheduler, manually editing the schedule, and requesting additional rooms from CMRadar are related actions. -= Planning =- The planning algorithm should determine a suggested ordering of tasks, and suggested investment of time for each task. It may also combine several related tasks into a higher-level task, as well as decompose large tasks into sub-tasks. The planner's decisions should be based on the dependencies among tasks, expected time of completing each task, expected improvements in the schedule quality (if known), "best practices" observed during war games, time left until the end of the test, and possibly work styles of specific users. -= Learning =- The system may learn (1) dependencies among tasks, (2) strengths of these dependencies, (3) expected times of completing tasks, (4) expected improvements to the overall score due to completing specific tasks, and (5) "best practices" for determining task priorities and allocating time to each task, observed during war games. We may use a technique similar to "derivational analogy," developed by Manuela Veloso and Jaime Carbonell, for learning appropriate sequences of tasks from the observation of effective human schedulers. We would use the initial knowledge of task preconditions in order to prune inappropriate task sequences, thus reducing the hypothesis space, and then select the most effective among the remaining sequences. If we implement a mechanism for learning an expected score increase for specific actions and sequences, we need some heuristic for evaluating the quality of completed tasks. We cannot use the IET scoring mechanism, since it is unavailable to the Radar system. We may try to divide users into classes by their work style, and learn different "best practices" for each class; however, it may potentially lead to two problems. First, it may result in overfitting, since the number of war-game users is small. Second, since war-game users are more experienced than test subjects, the classes learned during war games may not correspond to the classes of test subjects. -= GUI =- We need to develop a GUI mechanism for advicing the user about task priorities and allocation of time among tasks. We may implement an animated "to-do list," which will show the most important task and follow-up tasks, and re-arrange the tasks when necessary. We may add a pop-up reminder, but we should ensure that it is not annoying. We should also implement a "Why" button, which would allow the user to find out the rationale for suggested priorities. We may need to develop a Scone representation of standard explanations, in addition to the representation of tasks, in order to support this button. A more advanced approach would be to "coax" the user to work on appropriate tasks, by re-arranging the display of tasks and available data, rather than giving a direct advice. ACTION ITEMS We plan to implement a simple Task Planning mechanism during Year 3; it will serve as a "proof of concept," and help to motivate the work on a more advanced planner during Year 4. The initial planner should use dependencies among tasks, library of standard task sequences, and possibly expected time of completing each task, which is likely to give reasonably good initial results. We tentatively aim to complete a simple planner by Spring 2007, and an advanced planner by Fall 2007. The first step is to discuss the representation of the Radar state, tasks, and actions, and document the main elements of the representation. We may also discuss how to collect these data from Radar components, and how to present them to the user. We plan to discuss it through e-mails to the "radar-planning" list; Geoff Gordon has volunteered to coordinate this discussion. After completing the discussion, we may need to schedule a second meeting. We also need a detailed proposal of work on the Task Planner in Years 3 and 4; I think we have not yet found a volunteer for writing it.