Page History

• Date: //date
• Time: 9:00 ET
• Location: nraozoom04 
• Sprint Calendar

Attendance:

• Jeff Kern
• Dana Balser
• Mark Whitehead 
• Allison Costa
• Mark Ferguson 

Agenda:

• There is currently no way for the TTA member to makes changes to a proposal with the Proposal State of In Review. (There is no option to resubmit a modified Observatory Copy, as it must be saved first to trigger the re-submit button and any saved changes are applied to the Author Copy and not the Observatory Copy.) See 

  Jira
  showSummary false server DMS JIRA columnIds issuekey,summary,issuetype,created,updated,duedate,assignee,reporter,priority,status,resolution columns key,summary,type,created,updated,due,assignee,reporter,priority,status,resolution serverId eb2e750b-a83a-387e-8345-36eee8a98f01 key STT-863

  
  
  • What behavior(s) do we want?
    
    • TTA member modifies Author Copy and can resubmit (triggers notifications) at any time, regardless of Solicitation being Open or Closed and regardless of Proposal State.
    • TTA member modifies Observatory Copy and re-submits at any time (triggers notifications), regardless of Solicitation being Open or Closed and regardless of Proposal State.
    • TTA member saves Observatory Copy without resubmitting, regardless of Solicitation being Open or Closed and regardless of Proposal State. No notification is triggered.
    • It is expected that if a user is viewing the Author Copy when a TTA member modifies the the Observatory Copy, the user will not know that they are out of sync in the UI. They must first back out of the proposal to see that the copies are out of sync. Unless we choose to implement the feature to push such an update.

• Jira
  server DMS JIRA columnIds issuekey,summary,issuetype,created,updated,duedate,assignee,reporter,priority,status,resolution columns key,summary,type,created,updated,due,assignee,reporter,priority,status,resolution serverId eb2e750b-a83a-387e-8345-36eee8a98f01 key STT-861

  • Minor note - This story is titled wrong. By State Model, there is no proposal with a draft state at the close of a solicitation. Any draft proposal is now Hidden.  Will update story.
  • Could a Proposal with Proposal State of Hidden be Withdrawn?
    • Note, only Draft → Hidden is allowed; no Observatory Copy exists.
    • Currently, it can be withdrawn. Should the software explicitly block this state transition?
    • Cannot withdrawn a Hidden proposal.
    • OSRs can never be withdrawn; handled internally.
• Behavior of a Withdrawn Proposal
  • Should system restrict the ability to Withdraw a proposal for a TTA member, for example, until Review Process Configuration is Finalized? Though we likely have the Policy to never Withdrawn once the reviews have actually started, we might by some accident, find ourselves in an awkward state.
    • For example, the Primary, Second etc save reviews. Then the proposal is Withdrawn. The ISRs cannot be finalized and so essentially Consensus is locked out.
      • Concern: the state transitions for the Review Process stall because of a Proposal that is Withdrawn at some point and can never have its ISRs finalized because a Withdrawn proposal is not available in the Review Process UI, even for a TTA member.
      • Do we need an additional check on the Proposal State during the review process transitions to protect against this?
    • Yes, withdrawing a proposal in PPR is allowed until the Review Configuration is Finalized.
    • OSRs are different (never can be withdrawn
    • Created 

      Jira
      server DMS JIRA columnIds issuekey,summary,issuetype,created,updated,duedate,assignee,reporter,priority,status,resolution columns key,summary,type,created,updated,due,assignee,reporter,priority,status,resolution serverId eb2e750b-a83a-387e-8345-36eee8a98f01 key STT-1188

• Follow up from v0.3 White boarding discussion
  • Working Diagram to aid discussion
  • Mosaic Use case: A proposal asks for a 5 x 5 deg mosaic, for example.
    
    • It translates to one Science Target, which has a Pointing Pattern. The Requested Time is 40 hours.
    • All pointings are assigned to the same cluster (Observation Specification). The Observation Specification has a Repeat Count of 10, and thus a Total Time per Repeat Count of 4 hours. (Let's ignore overhead for now).
    • Step 1: Translating Observation Specifications into Effective Science Target Lists
      
      • If the Effective Science Target List (which lives in the Allocation Disposition) is created from the Observation Specifications in an Allocation Request, then (I think) it is possible to reprocess the contents of the Observation Specification in this case.
      • It would require new algorithms to carefully re-engineer it though, which requires more testing and room to be inconsistent with the "real" Science Target List.
      • If the user bypasses the Capability Request entirely, then the translation from Observation Specification made by an expert user may not accurately reflect their real request.
      • I think we would have to reveal what is given to the Review process more directly in this case (i.e., some variation of Effective Science Target List).
    • Step 2: Review Process and Modifications
      • The SRP Panel says "This is a great proposal, but I really think they need to do a pilot survey of the a smaller region: 1 sq deg at most. So they only need 1.6 hours and can do it in one scheduling block."
      • How does the Scheduler modify the Observation Specification Disposition to handle this?
        • A Science Target has no concept of a FOV. It has a concept of the Pointing Pattern. So the Scheduler cannot rerun the algorithm.
        • They could enter by hand the new Total Time, Repeat Count, and the LST Range (or maybe we have a button that does a calculation for a set of sources).
        • What about overhead?
  • If a user modifies the OS, then there is a flag on the OS for User Modified. The Effective Science Target list generated from it could be a shallow roll up of the OS(s), which captures the sources, hardware, and time.
  • When processing the Observation Specification Dispositions, the User Generated flag will be available to the Scheduler.
  • The Scheduler has a flag that tracks if the OSDs are modified sufficiently that they cannot be run, as is, through the algorithms. Thus manual generation of Scheduling Blocks will be necessary at Project Creation (User or TTA member duty TBD).
• Policy Discussion with Toney R.
  • Keeping Technical Reviews for Large Proposals
    • Would like ability to specify at Solicitation configuration a granularity to what proposals will have a review
      • e.g., Astrometry, VLBI, subarrays
  • Review of Past Disposition Letters at Consensus → No
  • Source Conflicts should be handled at TAC, not SRP panel level
    • Further clarification is needed.
      • If the Source Conflicts exist internally to the same panel in the same Solicitation, should the SRP be notified at the time of Consensus reviews?
      • If the Source Conflicts exist in the same Solicitation but different SRP Panels, should the relevant SRPs be notified at the time of Consensus reviews?
      • If the Source Conflicts span multiple Solicitations, this is only available to the TAC.
        • The range of Proposals checked needs qualified. e.g., Proposals that are currently running, in queue, in proprietary period. This is likely tied to the definition of Source Conflicts.
  • Need Definition of Source Conflicts still.
  • Are Past Proposals available to SRP panels?
  • Modification to Total Requested Time in a Observation Specification should trigger addition questions that belong with the technical justification
  • Timing of User Modification to Scan List
• Sprint 48 feedback

Open Actions: