This is a referendum to create the OpenGov Tech Committee. 

The committee consists of members with technical knowledge of Moonriver and has the power to whitelist proposals on the WhiteList Track.

The Technical Committee serves to help make well-informed decisions on a technical basis. It also helps safeguard the network in the case a proposal moves to referendum that is not technically sound, or if there is an immediate need for a network upgrade that must be fast-tracked.

Members of the committee are subject to governance and can be added or removed from through governance in the Root Track. 

The following members were chose because of their technical knowledge of Moonriver and Moonbeam; and their dedication to the network(s):

- Alan Sapede (@Alan_PureStake) – VP Engineering at PureStake. Over 20 years programming experience. Has deep technical and hands-on knowledge of the Moonbeam protocol. Is an active contributor to the Moonbeam codebase and has a large amount of Substrate and Polkadot expertise.
- Gorka Apecechea (@girazoki) – Research Developer. Developer actively working on the Moonbeam protocol with specific expertise in relay chain interaction, XCM, and other Moonbeam subsystems. PhD in Computer Science / Cryptography.
- Aaron Evans (@aaron.mbf ) – Director of the Moonbeam Foundation. Engineering Executive background. Has 20 years of experience in software engineering and technical leadership roles. Has been working with Moonbeam and ecosystem projects since 2021.
- Sicco Naets (@sicco-moonbeam) – Director of the Moonbeam Foundation. Software Engineering Leadership background. Has led teams implementing and designing complex software for over 20 years.
- Linkou (@linkou) – Runs the MoonEntropy collator on Moonriver and Moonbeam. IT & Security background and is engaged in governance votes on the Moonriver and Moonbeam networks.
- Boony (@Boony) – Runs the MoonWorld collator on Moonbeam network. IT background and engaged in governance votes on the Moonbeam network.
- Jim Farley (@Jim_CertHum) – Runs the CertHum Collator on Moonriver and Moonbeam. Setup the independent collator coalition where collators support each other to stay in the active set. Also providing a snapshot service as a public good to the network, so collators can sync new nodes faster with known good images.
- Blackk Magiik (@blackk_magiik) – Runs the Paradoxx collator on the Moonriver/Moonbase networks. Extensive network security engineering and architecture background. Active in Discord and governance discussions.
- Tim Baldwin (@tdb) – VP Engineering at PureStake – Technical Lead for Dapps and Infrastructure. Familiar with Moonbeam APIs, SDKs, and development applications on Moonbeam. Has been working with Moonbeam since 2020. Over 25 years of experience in software engineering and IT.


For the full details about the Tech Committee, it's composition; and it's role in the OpenGov process; please refer to the following article:

https://moonbeam.network/announcements/opengov-moonriver/

Set the collective's membership.

- `new_members`: The new member list. Be nice to the chain and provide it sorted.
- `prime`: The prime member whose vote sets the default.
- `old_count`: The upper bound for the previous number of members in storage. Used for
  weight estimation.

Requires root origin.

NOTE: Does not enforce the expected `MaxMembers` limit on the amount of members, but
      the weight estimations rely on it to estimate dispatchable weight.

# WARNING:

The `pallet-collective` can also be managed by logic outside of the pallet through the
implementation of the trait [`ChangeMembers`].
Any call to `set_members` must be careful that the member set doesn't get out of sync
with other logic managing the member set.

# <weight>
## Weight
- `O(MP + N)` where:
  - `M` old-members-count (code- and governance-bounded)
  - `N` new-members-count (code- and governance-bounded)
  - `P` proposals-count (code-bounded)
- DB:
  - 1 storage mutation (codec `O(M)` read, `O(N)` write) for reading and writing the
    members
  - 1 storage read (codec `O(P)`) for reading the proposals
  - `P` storage mutations (codec `O(M)`) for updating the votes for each proposal
  - 1 storage write (codec `O(1)`) for deleting the old `prime` and setting the new one
# </weight>

- **Problem Statement:** Polkassembly is proposing a Polkadot runtime update to v23.
- **Significance:** Enhancing the Polkadot runtime to v23 is crucial for improving the platform's performance and security.
- **Proposed Solution:** Upgrade the Polkadot runtime to version 23.
- **Expected Outcomes:** Improved performance and security for the Polkadot platform.

#3 Creation of the OpenGov Tech Committee