@kcranston and I would like to propose some changes to the documentation wiki.
The main idea is to bring the different modules in the index to facilitate the finding of specific pieces.

Please see the proposed changes below regarding the Home.md file of the wiki. If we agree, I will change it directly in the wiki (and the links to other wiki pages will work).

Index of DINA-Web system documentation:

Overview

• [[Overview]] of the goals, guidelines, principles and decisions.

User manual

• [[User manual]] for collection managers.

Modules

Accounts management

• [[ Account Management ]] documentation
• GitHub Account-Management project

Collection management

• [[ Collection Management ]] documentation
• Use Cases
• GitHub Collection-Management project
• GitHub DINA-collections-data-model project

Taxonomy management

• [[ Taxonomy Management ]] documentation

Developers documentation

• Guidelines
• [[ Development manual ]] for developers
• [[ Technology-overview ]]
• [[ Docker Practices ]]

Private Space

Login required

Tasks

• Current tasks are tracked on Redmine
  (requires login)

Services

This contains all services related to DINA. Please see the [[User Manual]] for links only to regular user interface (requires login).

• Collections manager: https://alpha-cm.dina-web.net/login
  • Mockup data version: https://alpha-cm-mock.dina-web.net/login
• Style guide: https://alpha-style.dina-web.net/
• API schema and documentation: https://alpha-api-docs.dina-web.net/
• Keycloak account management console: https://alpha-keycloak.dina-web.net
• Slim-Taxonomy mockup API: https://alpha-slim-taxonomy.dina-web.net

Parts of the manual are work-in-progress or still awaiting final decisions (TBD).
Manual will be written in English. (Possible translations of stabilized documentation will be discussed later.)

It would be very useful to identify the top non-functional requirements for the DINA system.
These requirements should guide general direction and influence architectural and design decisions. As a multi-modules, multi-institutions system, I would suggest the following list:

• Maintainability
• Testability
• Documentation (code and user documentation)
• Interoperability (e.g. JSON-API)
• Extensibility

It doesn't mean other non-functional requirements are not important but more that in case of conflict, the requirement from the list above should be prioritized. e.g. Maintainability vs Performance

I have some high-level questions about the DINA system (triggered by discussion of the taxonomy module, but pertain to development as a whole). I assume that:

• DINA consists of multiple modules (collection, taxonomy, etc)
• An institution (e.g. Naturhistoriska riksmuseet, Agriculture and Agri-Food Canada) can have multiple collections (e.g. mammals, fungi, plants)

Will a single institution install:

1. A single DINA system with one instance of each module
2. A single DINA system with one or more instance of each module (e.g. one taxonomy module and multiple collection modules, or one collection module with multiple taxonomy modules)
3. Multiple DINA systems (one for each collection)

Will there be a single user interface for each institution or each DINA installation or each collection?