Is your feature request related to a problem?

Some time ago, we introduced changes to Assembly members and private participants to address an overlap between them (#13414). However, this unintentionally affected the public visibility of assembly members, reducing transparency and accountability.

Assemblies, by definition, must have members, and these members should remain publicly visible regardless of the access configuration. Processes may also require members (e.g., a Citizens’ Assembly structured as a phased process), and should therefore follow the same predictable and consistent behavior.

The current combination of “Private space” and “Is transparent” does not quite convey the intended access model.

Finally, because of the evolution of these features, we have the section and a functionality (Members) that refers to something called "Participatory Space Private Participants" or "Participatory Space Private Users" or "Members".

Describe the solution you'd like

Introduce a unified access model applied to both processes and assemblies:

• Members can be enabled when creating a process or an assembly.
• Admins can define the access scope of the space using a new radio-button with the following options:
  • Open: everyone can see the process or assembly and participate.
  • Transparent: everyone can see the process or assembly, but only members can participate.
  • Restricted: only members can see and participate.
• When I go to this section, all the wording, URLs, models, controllers, commands, etc refer to the Members, so we have a consistent and ubiquitous language when we talk about this
• When members are enabled, the default access level should be open.

These three options translate to the following current settings:

• Open: unchecked "Private space"

• Transparent: unchecked "Private space" and checked "Is transparent"

• Restricted: checked "Private space" and unchecked "Is transparent"

Mock-ups / Prototype

How it looks and works now

How it will look and work after

New card: Access

Describe alternatives you've considered

Maintaining the current behavior, but this forces the admin to always set the assembly as private and/or transparent in order to display members.

Acceptance criteria

• Given a new process or assembly is created with members enabled, then members are shown by default.
• Given an admin is configuring a process or assembly, when they view the access options, then they can choose between open, transparent, and restricted via a radio-button.
• Given a new process or assembly is created with members enabled, when no changes are made to its access settings, then the default access level is open.
• Given a process or assembly with access set to open, when a participant views it, then they can see it and participate.
• Given a process or assembly with access set to transparent, when a participant views it, then they can see it but cannot participate.
• Given a process or assembly with access set to restricted, then participants that are not members cannot view it nor participate.
• Given an admin goes to this section, they always see the word Member referred for this feature.
• Given a developer goes to the code, they see references to Members instead of Private Participants.