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?Proposed changes:
  • Saves to the Observatory Copy should not affect the Author Copy
  Modification by TTA Member:
  
  • 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 (currently)

• 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

• This work is scheduled for STT-863

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 soon.
• Could
Can
• 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?
• Behavior of a Withdrawn ProposalBehavior of a Withdrawn Proposal
  Withdrawn proposals should not be displayed in Review Process Configuration, ISRs, etc or in the OSR reviews.
  
  • In Review → Withdrawn is a valid State Model transitions. Currently, the UI still displays a proposal if it went Submitted→ In Review → Withdrawn during the Vetting and ISRs. This is obviously not desirable.
  • It works properly for OSR proposals.
  Presumably, the withdrawn proposal is not even shown for the TTA member.
  • 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?
• 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
  • 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
• 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 of a Mosaic. The Requested Time is 40 hours.
    • All pointings are assigned to the same Cluster cluster (Observation Specification Group). 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).
    • Issue 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 that answer 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 actually be what they wantaccurately 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).
    • Issue Step 2: Review Process and Modifications
      • The SRP Panel says "This is a great proposal, but I really think they only 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 execution 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?
• 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
  • 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

Open Actions: