Skip to content

Recent scope and rule changes #17

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
mwapst wants to merge 1 commit into
base: main
Choose a base branch
from
Open

Recent scope and rule changes #17

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
8 changes: 5 additions & 3 deletions docs/Design/BusinessRules.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -31,9 +31,11 @@ Polaris must not offer the Maintain Polaris observatory reference data option to
### *Observations*

<ul><li>A proposal has one or more observations</li>
<li>An observations has one target</li>
<li>A target has one set of technical goals, one or many timing windows, and zero, one or many constraints, and must be identified as either Observation or Calibration</li>
<li>A set of technical goals consists of one set of performance parameters and one or more spectral windows</li></ul>
<li>An observation has one or more targets, but usually just one</li>
<li>A target is an attribute of one or more observations, and one or more proposals</li>
<li>A target has one set of performance parameters, one or many spectral windows, one or many timing windows, and zero, one, or many constraints, and must be identified as either Observation or Calibration</li>
<li>Performance parameters and spectral windows are known collectively as technical goals, usually just one per target, and maybe even per proposal</li>
</ul>

### *Proposal cycle*

Expand Down
30 changes: 24 additions & 6 deletions docs/Design/PurposeAndScope.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -7,13 +7,30 @@ The application will be known as the Polaris Proposal Submission Tool (Polaris).

## **Overall scope and goals**

Polaris will be used for the following activities:-
Polaris will manage the following activities:-

Participating observatories publish their future observing cycles, typically of six months duration. Each observatory maintains an inventory of available resources.
* Participating observatories publish their future observing cycles, typically of six months duration. Each observatory maintains an inventory of available resources.

Astronomers create, maintain, and submit observing proposals for one of those cycles. They may submit their proposals to more than one observatory and may also create another proposal from an existing one, submitting it after editing.
* Astronomers create, maintain, and submit observing proposals for one of those cycles.

* * Their proposal will include sufficient scientific and technical details for the TAC to be able to make an informed decision about the proposal, but no more.

* * They may submit their proposals to more than one observatory and may also create another proposal from an existing one, submitting it after editing.

* TAC nominated reviewers discover and read astronomers’ submitted proposals and assign to them a score which will determine whether or not observing time is allocated. The final decision regarding observing time allocation rests with the TAC. In the event of an observing cycle being oversubscribed, the TAC may revoke any allocation.

Polaris will *not* manage the following activities

* Providing full configuration details to enable the observatory equipment to fulfil the observation needs of the proposal

* * These will be provided independently by the astronomer once the TAC have agreed to allocate time and resources to the proposal

* Scheduling of resources at an observatory following allocation of time to a proposal by the TAC

* Managing proposal state beyond completion

* * There are complicated rules around publication accessibility

TAC nominated reviewers discover and read astronomers’ submitted proposals and assign to them a score which will determine whether or not observing time is allocated. The final decision regarding observing time allocation rests with the TAC. In the event of an observing cycle being oversubscribed, the TAC may revoke any allocation.

The desired outcomes are that astronomers are able to make their observations using their nominated observatory’s resources, and that the observatory's resources are used effectively.

Expand All @@ -33,9 +50,10 @@ The desired outcomes are that astronomers are able to make their observations us
| Allocate time for a submitted proposal | Must - NB Polaris captures this decision but does not have access to the observatory schedules in order to make it |
| Assign roles to users | Must |
| Automate scheduling of proposals | Won’t – it does provide the input data for a scheduling tool however. |
| Capture all technical configurations necessary to operate the observatory equipment | Won't |
| Capture observatory details, eg location, equipment, availability, observing cycles, etc | Must |
| Capture state of a completed proposal | Could |
| Capture published state of a completed proposal | Won't - there are complicated rules around publication accessibility |
| Capture published state of a completed proposal | Won't |
| Capture state of a submitted proposal | Could |
| Capture system details, eg users and roles | Must |
| Clone a proposal | Must |
| Communicate with users | Should |
Expand Down