Create specifications for regional science capability

[florianm]

Problem

RS = Regional Science RSP = Regional Science Project

Clarify with stakeholders:

Project documentation

• How are RSPs documented and how is that documentation approved? Is there a policy or guideline?
• How, if at all, are RSPs different to BCS Science Projects in terms of project details?
  • Could RSPs look like BCS Science Projects if we adjust the labels to be more generic?
  • Do we need different project types for RSPs or should they re-use the existing project types?

Project approval

• Who approves an RSP (project or document) in first and second instance? (e.g. a local program leader, a central directorate)
  • "review": One person approves each RSP OR there are different approvers for different regions/themes
  • "approval": Who gives final approval where necessary - Dir BCS or Dir RS?

Reporting

• RSPs are not part of the BCS annual report.
• Is there an annual reporting requirement for RS?
• With a link to the Scientific Sites Register (or its possible successors): how should spatial linkage of projects be represented and reported on? The current (11 year old) implementation is cumbersome and repetitive. Why not mini-maps?
  • Choose place names from a list (like current implementation) OR
  • draw a polygon or box on a map OR
  • upload spatial extent to the data catalogue

Feature

• [x] Answers to the questions above. (This determines the solution architecture and implementation.)
• [x] Screen wireframes for intended UX. (This is the product that senior stakeholders can understand best.)
• [x] Documentation of (intended) program, project, document structure and approval processes. (This becomes both a spec to implement and user documentation).

[florianm]

Simple start:

• [x] Create a test program on SDIS UAT https://sdis-uat.dbca.wa.gov.au/pythia/program/22/change/
• [ ] Change home page to separate BCS from RS
• [ ] Adjust labels to scope DBCA = BCS & RS -- this is iffy, we should add structure as needed to prevent overloading labels, otherwise we risk a scope clash of SDIS entities/labels and org structure

alternative:

• [x] Pretend we will create a model for Division, sitting above Program, so that the linkage is Division > Program > Project > Document
• [x] User has a FK to exactly one "Division" which is updated on profile creation from request headers (if any division info available that way), by user updating their own profile (link from home page top right), in bulk through the shell by a maintainer
• [ ] Start page hard-codes Division "BCS" in LHS column, Division "RS" in RHS column

[florianm]

Wireframes at https://dev.azure.com/dbca-wa/ecoinformatics-docs/_wiki/wikis/ecoinformatics-docs.wiki/1567/SDIS

[florianm]

Current assumptions to be confirmed or corrected:

Organisational Structure of SDIS

• [ ] The term "Regional Science" applies to science projects of other divisions and authorities than BCS: RFMS, CEM, ZPA, BGPA, RIA.
• [ ] Science projects of the BGPA and ZPA are already managed and reported on in SDIS under existing SDIS programs "Kings Park Science" and "Perth Zoo Science". They still can have projects outside BCS scope and therefore need their own SDIS Division.
• [ ] SDIS needs the new concept of Divisions (BCS, RFMS, CEM, RIA, BGPA, ZPA)
• [ ] BCS programs continue to exist, RFMS "programs" are the nine regions, CEM "programs" are the five branches, and so on
• [ ] Analogous to a BCS program leader, a RGMS regional leader is the appropriate reviewer for their region's science projects, similar for CEM branch manager and so on.

Project and Document structure

• [x] The existing SDIS project types apply to all Divisions
• [x] The existing SDIS document types apply to all Divisions
• [x] The existing SDIS approval workflow applies to all Divisions as follows

Approval workflow new to active project

This is a worked example based on the above assumptions. Following this example could help to either confirm or correct our assumptions.

• A regional staff member creates a new project, choosing from the existing project types
• The staff member adds their project team members to the SDIS project, which gives them permissions to update project details and documentation
• The project team draft the Concept Plan and submit for review
• The regional leader reviews and approved the Concept Plan
• The Dir RFMS approves the Concept Plan
• The project team gets notified and drafts the Project Plan
• The Project Plan is endorsed by the Animal Ethics Committee, the Herbarium Curator, the Biometrician (RFMS or BCS?), the Data Manager (new - create metadata for expected datasets created in the project)
• The Project Plan endorsements are communicated outside SDIS and entered by the regional leader (AE), or entered directly by the respective roles (BM, HC, DM)
• The Project Plan is approved by the regional leader, the project becomes "active" without the need for approval from the Dir RFMS
• Some project types (Student Projects, Ext Partnerships) have an abbreviated approval process (e.g. none, they are "active" immediately after creation)

Approval workflow active to closed project

• [ ] Project closure of RFMS projects follows the exact protocol of project closures of BCS projects, although with their own set of reviewers (regional leader) and approvers (Dir RFMS).
• [ ] The closure types (completed, suspended, terminated) are valid for both Divisions.

Reporting

• [ ] There is no annual reporting requirement for RFMS projects
• [ ] There is no requirement to produce PDFs of projects or document beyond the current implementation (e.g. a user can export any document as a well formatted PDF)

API

• [ ] The API shall provide all information on SDIS divisions, programs, projects, documents, users in a structured format which can be consumed by other DBCA applications