Old Proposal Copying
Requirement from ttaToolsSysDescription.pdf (2.2.4): "It shall be possible, with best efforts, to create a new draft from a proposal in the WITHDRAWN or COMPLETED state."
There is an expensive interaction between wanting to support copying proposals (as templates for new proposals) and supporting ever-changing telescope resources/backends. Supporting the edit view of historical resources implies having the code from every release of the PST. Some backends are simply deprecated. Decisions need to be made about how copying should work with backends that change or disappear entirely.
Rick says:
I don't think there is any need for long-term editing. During a release (same semester), Admins occasionally do edits to correct some issues, but that is usually within the first week post-deadline. Edits farther out are just not done, and really are against policy.
As for copying, that is an extensively used feature and as noted causes problems in the current PST. Deprecated backends (not uncommon with the GBT) are adequately handled in the current PST, but improvements could be made. As for resource changes, copying a proposal with a substantial change between versions of an active resource is problematic. UI issues, model issues, and database issues.
A particularly good example is GMVA for 21A. GMVA (much like VLBA) has some correlation options and a list of stations. The stations were grouped by US and European. There were some UI dependencies that allowed selecting all European stations by clicking one checkbox, etc. Some stations may also be disabled in conjunction with another station selection. This has always been a mess in the PST. But for 21A, they wanted to modify some stations, regroup them (Member and Other), and change some of the dependencies. Maintenance nightmare. This also means historical proposal will be using some columns that new proposals won't use and vice versa. And if you copy proposals, how do you map the stations. Supporting UIs for both versions of the resources would add a whole new level of complexity to the UI for the benefit of ~5 proposals / semester. We went for the quick fix: discourage GMVA proposal copying.
Now for the good news. For the GMVA the correlation parameters are fixed. So you can't select different values. That was the saving grace. Had this happened on the VLBA, many of the correlation parameters are dependent on stations (e.g., 4Gbps not available at Arecibo for HSA). That would have generated an explosion in the number of dependency changes.
Technical recommendation
One approach for handling this problem:
- When the call is closed, proposals for that call become frozen
- The freeze process generates a viewable form of the proposal which is no longer dependent on the schema (as an example, a PDF file) and this viewable form is stored with the proposal
- When backend changes are requested, an algorithm must be developed for converting the previous backend structure into the new backend structure. If no such conversion is possible (such as when a backend is removed), the algorithm simply removes usages of that backend
- As a result, copying an old proposal to make a new one is always like copying a proposal from the current semester, in terms of backends
- Backends that were dropped but used in old proposals are still visible in the frozen format of the proposal, just not in a machine-useful form
Performance Quality Attribute
SSA-6551 - Investigate responsiveness under high concurrency with Python web applications , <Rick puts an example here>.