Basic requirements

• Proposals should be submitted electronically.
• All technical input should be stored in a database, and should therefore be computer readable. There should be enough information to provide the proposer (and the reviewer) with a detailed idea of the technical feasibility of the project. This would be easiest if a web-based proposal preparation tool performed certain calculations, i.e. of time required under average conditions, fraction of time available at the site for the specified requirements (e.g. phase stability < xy degrees at a specific frequency), etc.
• The technical data input for proposals should have several layers:
  • Basic interface for non-experts: input in terms of proposal goals
    • angular resolution, largest structure (instead of configurations),
    • source Flux and S/N or RMS (instead of observing time),
    • line frequencies and desired resolution in km/s (instead of correlator setup),
    • image fidelity needed (instead of specifying particular calibration strategies).
  • This translates into observing mode, configurations, observing time, correlator setup, all of which should be checkable (and changable).

  • Expert interface: one should be able to override the basic mode and specify ALL parameters manually.

• Scientific justification could be postscript or pdf add-on. We don't think this needs to be computer parsable, if all the technically relevant data are available elsewhere. People should be free to use their favorite text processing system to prepare the text and to include figures.
• Basic checking for conflicts against a database of already conducted observations should be done at time of submission to give instant feedback to the proposer. This database should also be accessible for interactive searching prior to proposal writing. People shouldn't be wasting time on proposing things that have been done already.
• The proposal preparation tool should allow storing of intermediate stages to local disks, to enable trying out different parameter settings.
• Proposer should specify what is needed for real-time checking of data quality. In some cases, breakpoints could be defined, after which an observations is stopped and only resumed (possibly in modified form) after examination of the data obtained so far by the proposer.
• The proposal should be detailed enough to judge technical feasibility and time, but does not need to go to all the detail necessary for observations. The observing script should be prepared after acceptance of the proposal with a tool that is a superset of the proposal preparation tool.