Update public engagement statements based on collab cafes

[manics]

✅ Checklist

• This pull request has a meaningful title.
• If your changes are not yet ready to merge, you have marked this pull request as a draft pull request.

☑️ Maintainers' checklist

• This pull request has had the appropriate labels assigned
• This pull request has been added to the SATRE backlog project board
• This pull request has been assigned to one or more maintainers

⤴️ Summary

Updates wording of the Public Involvement and Engagement, see issues below

🌂 Related issues

Closes

• [Change]: Involving members of the public in TRE operations #255
• [Change]: Transparency principle #258
• [Change]: Involving members of the public  #259

🙋 Acknowledging contributors

• All contributors to this pull request are already named in the table of contributors in the README file.
• The following people should be added to the table of contributors in the README file:

[JimMadge]

Ah, I see now 😄.

I would prefer to keep the importance options minimal.

This also removes the consistent "You must", "You should", "You could" style of the statements.

Do we think it is reasonable to have the statement include "if"?
I think that came up in the evaluation we ran at the Turing with some requirements being "0, because we don't need to do this or the requirement is n/a".

[manics]

I think the status needs to be clear, since we want to combine the scores to get an overall result
https://satre-specification.readthedocs.io/en/latest/evaluation.html#combining-scores
and I think we should move towards a more machine readable/generated spec #254

If we want to keep the statuses simple I vote for making it Recommended. @Katie-RDS how would you feel about making these statements Recommended so we don't need to have a conditional status, but making it clearer in the statement/guidance that it should be considered mandatory for public sector data?

[Katie-RDS]

I think the difficulty with making them recommended is that if it is a public sector one and they filter by mandatory they could tick all the boxes without that? But appreciate trying to maintain simplicty

[craddm]

Ah, I see now 😄.

I would prefer to keep the importance options minimal.

This also removes the consistent "You must", "You should", "You could" style of the statements.

Do we think it is reasonable to have the statement include "if"? I think that came up in the evaluation we ran at the Turing with some requirements being "0, because we don't need to do this or the requirement is n/a".

I agree that we should keep the importance options minimal - we really want to avoid having lots of caveats in those options. I think it's ok to make clear in the guidance that there are some statements that are more/less important in certain circumstances

[Katie-RDS]

I think that works that it is mandatory then in the statement it says 'if' so people can mark down N/A if it is N/A for them

[JimMadge]

I think that works that it is mandatory then in the statement it says 'if' so people can mark down N/A if it is N/A for them

This is the way we interpreted requirements when completing the Turing evaluation.

For example, 4.3.1 is N/A for us so we marked it as 2 as there is nothing for us to do there.

[manics]

I've changed the statuses to Mandatory* (with the asterisk to make it clear there's more to it).

[manics]

I've also added #290 for discussion of how to score non-mandatory items.

[manics]

Following discussion today there's no consensus on whether we should make things conditionally mandatory, and what exactly "public sector data" means. We'll therefore return to this after the 1.0.0 release.

[drchriscole]

The text for mandatory* should be about "personal data" not "public sector data".

[drchriscole]

Discussed in detail with Katie, Antony, Chris and Simon.