Questionnaire summary: Decide how to handle multiple choice Qs

[edwardchalstrey1]

Handling multiple choice questions:

- 3) Admin control over data movement
- 4) User authentication
- 5) Network connectivity
- 6. Ability to forbid copy and paste
- 7. User experience
- 8. Programming language support
- 9. Enable users to install packages from selected external repositories (e.g. PyPI, CRAN, Conda, Maven)
- 10. Commercially licenced software
- 11. Containerisation
- 12. Logging
- 13. Automatic updates
- 14. Compliance checking
- 15. Automatic backup
- 16. Customisable compute resources
- 17. Additional compute beyond workspaces
- 18. Collaborative/shared tools

Notes:

• Order by most essential to least essential/ most mixed responses
• Comment on whether you think the question was clear enough, based on the results
• Identify ways to interpret multi-choice survey results E.g.
  • what % means accepted?
  • Mode option (for multiple choice)
  • MoSCoW method
  • What is a majority? 25%+1 (four options), 50%+1
  • Metric based on some weighting of choices

[drchriscole]

My vote would be 50%+1 as first pass.

[harisood]

~@edwardchalstrey1 I've just opened a PR to include the source of issues in the templates so we can show these came from the SATRE survey: https://github.com/sa-tre/satre-specification/pull/48~

I'm thinking we can use the pre-existing issue templates to share results from the survey: https://github.com/sa-tre/satre-specification/blob/main/.github/ISSUE_TEMPLATE/change.yml

I've drafted an example using admin controls, where the multiple choice questions clearly suggest some kind of features for the specification - this is not any actual analysis, but just to elucidate what an example could look like:

Admin controls

Summary

The percentage splits of responses to the SATRE survey question of what controls admins should have over data within a TRE.

Source

SATRE specification survey responses

Detail

Survey Results

Feature	No opinion	Not important	Nice to have	Important	Essential
Ingress (data entering the environment)	x%	y%	z%	a%	b%
Egress (data leaving the environment)	x%	y%	z%	a%	b%
Streaming ingress	x%	y%	z%	a%	b%

Summary blurb, e.g.: The community seems to be in consensus that admin control over data egress is essential, and most also agree that admin control of data ingress is essential. There is less consensus on whether streaming ingress is an essential feature or not

Where

Specification features

Proposal

• Include admin control of data ingress in the 'required' features of the TRE specification
• Include admin control of data ingress in the 'required' features of the TRE specification
• Include admin control of streaming ingress in the 'optional' features of the TRE specification

[harisood]

@JimMadge @arronlacey @martintoreilly @drchriscole and others thoughts?

[harisood]

Example for the discussion point (where the answers to the multiple choice don't suggest anything clear about what features to include or not include) - these aren't actual analyses, just examples of what an issue could look like:

Network connectivity

Summary

The percentage splits of responses to the SATRE survey question of what connectivity settings workspaces within TREs should have

Source

SATRE specification survey

Detail

Survey Results

Feature	No opinion	Not important	Nice to have	Important	Essential
Configurable connectivity between workspaces	x%	y%	z%	a%	b%
Configurable connectivity between a project and resources outside the TRE	x%	y%	z%	a%	b%

Summary blurb, e.g.: There was lack of consensus over how network connectivity should be provisioned for a specification

Intended output

• Clarity over what features of network connectivity to include within the specification

[harisood]

If we do it this way it also means we aren't doing set decision tree rules, e.g. 50+1% means recommend it goes to required features etc., but leaving it up to the discretion of the person adding the issue/those in the comments, which I think is more in line with what @JimMadge was saying?