The relative ease, informality and flexibility of the APO 3.5m scheduling process and forms (compared to many other facilities) is an advantage for users of the telescope, I hope and believe. However, this approach has also had some negative consequences that are making the scheduling of the telescope increasingly difficult and frustrating. Indeed, improperly and inconsistently prepared scheduling requests, submitted by 3.5m users through their institutional TACs and schedulers, have increased in frequency and "severity" to the point that they have become a major obstacle to the accurate and timely preparation of the telescope's quarterly observing calendars. I strongly request that all those submitting these forms take care to make sure that they are properly prepared and that each institutional scheduler carefully proofread their submissions before sending them to me. Starting in 1Q2003 I will begin to more freely exercise the option of simply not scheduling programs for which an incorrectly prepared scheduling request is submitted. Instead I will simply assign the relevant number of half nights of the appropriate moon phase to the institution at whatever time they most conveniently fit into the observing calendar (i.e., typically during low demand parts of the quarter). It will then be an institutional responsibility to assign the time as best it can internally. Obviously use of this option will cause everyone concerned a lot of extra hassle and result in a less scientifically productive use of the telescope, so I very much hope that it will rarely be necessary. Some examples of the specific problems which I hope that we can avoid in the future are given below. In a separate following message, I will send the current version of the scheduling request ASCII template and its accompanying instructions. Many of the problems result from users incorrectly understanding what information is being requested in specific fields of the template. It would be very helpful if everyone could consult the fairly detailed instructions to determine where to put all the necessary info. The current scheduling request template may be modified or perhaps replaced with a web form version fairly soon, but the issues discussed here will still apply to future versions of the template. This message will undoubtedly seem needlessly bureaucratic and nit picky to many, and it is indeed the case that a careful reading of most of the submitted requests provides all of the information necessary to schedule the program, even if it is not given in the right field or requested format or it requires an informed "reading between the lines" to guess omitted info. There would be no problem if only one or a few programs were involved, but with a few dozen per quarter to be scheduled, the added time and distraction of havng to give most requests an individualized reading to extract the necessary information becomes serious. The ASCII template was intended to be used for *scheduling requests*, not *observing proposals*, but most of the institutions are now using it for both. As a result, there is often information included which is not needed for scheduling and which makes it harder to quickly find the information that is needed. One approach would be to separate the proposal and TAC allocation process into two steps, so that a PI does not have to simultaneously try to make the scheduling request clear and concise while making the proposal detailed and compelling. Another, more streamlined approach, would be to stick with one form and step but to put all of the detailed information intended to "sell" the program into the SCIENTIFIC JUSTIFICATION section, which it should not even be necessary to read during the scheduling process. For those interested in some details of the types of problems that seem to be becoming more and more frequent, I list some of the more common ones below: - The most common single problem is putting important information in the wrong field. Some proposals put much critical information in a narrative form in the SCIENTIFIC JUSTIFICATION section or put information there which modifies or contradicts info given in the more specific fields higher up in the form. Or, for another example, a request might give a description of the program's filter requirements (which is not even a scheduling issue) under the SPECIAL REQUIREMENTS field where I look to find dates that the PI or observers cannot use for non-astronomical reasons. - Another common problem is that the necessary info is in the right field but that it is not readily located at a glance because a lot of other extraneous material is also included. For example, the best way to indicate dates on which the observer(s) will be unavailable is simply to list them, as opposed to "hiding" them in a narrative paragraph which explains how the observer(s) will be otherwise occupied. Similarly, if it is possible to just say that the program's targets require first halves early in the quarter, I can absorb that information more quickly if it is not diluted by a discussion of how these particular objects are needed to complete a magnitude limited sample and thus allow some specific statistical quantity to be determined (which would be an appropriate discussion for the SCIENTIFIC JUSTIFICATION section, of course.) Another example is that if both the time the PI requested and the time the TAC allocated are listed, I must be careful not to read off the wrong one when glancing at the form. - Scheduling requirements written by the PI for the requested amount of time are often rendered ambiguous or impossible if the TAC cuts the request. For example, a PI may request 6 half nights scheduled in blocks of two in each of the quarter's three dark runs, but when the TAC only allocates 4 half nights of dark time to the program, it is no longer clear how to proceed - two blocks of two half nights in just two of the dark runs (which two?) or some time in each of the three dark runs (how split up) or...? Again, by reading the request in detail, I can usually make a reasonable guess, but it is a distraction from assemblying the schedule and may not even be the right guess. In general, if a program's request is cut by the TAC, it would be best if the PI were allowed to revise the scheduling constraints/preferences before it is submitted. - It is clear that most regular users of the telescope edit previous requests and resubmit them in later quarters. I do that too, of course. The problem occurs when an old requests is not completely updated. For example, it is not uncommon to see scheduling requests that were clearly written for a different quarter (e.g., asking for September nights in a 4Q request). - Requests should not require me to run SkyCalc for the PI. For example, if a bright time program wants to impose the constraint that it be scheduled when the target is more than 30 deg from the Moon, it should specify the dates that are or are not acceptable for that reason explicitly. In general I should not have to think about the RA's and DEC's of a program's targets explicitly, and it is not even required to list them or give ranges. However, especially for low priority programs which cannot be scheduled on there ideal dates, it is often useful to know something about target positions, so there is no harm in listing them. It should not, however, replace an indication of preferred and acceptable dates or some more complex, but explicit, scheduling constraint. - Finally there are sometimes scheduling requests that are impossible to meet due to celestial realities, for example requests for full nights of gray time or for a program's bright halves to be scheduled before its dark halves in month which starts going into a dark run and ends coming out of a bright run. I feel, and hope that users agree, that our ability to schedule the 3.5m in an unusually flexible and responsive way is one of its unique strengths and better features. I will greatly appreciate your help in making the process of assembling the schedule work as well and smoothly as possible. As always, I welcome any comments or suggestions on the scheduling process; either post them on apo35-general or email them directly to me, as you prefer. Ed Turner APO APO APO APO APO Apache Point Observatory 3.5m APO APO APO APO APO This is message 611 in the apo35-general archive. You can find APO the archive on http://www.astro.princeton.edu/APO/apo35-general/INDEX.html APO To join/leave the list, send mail to apo35-request@astro.princeton.edu APO To post a message, mail it to apo35-general@astro.princeton.edu APO APO APO APO APO APO APO APO APO APO APO APO APO APO APO APO APO