Call `set_params` for `CoreFellowship` about runtimes

[joepetrowski]

Some handy reference when evaluating:

• The Manifesto references time periods in months and years. Of course, these need to be converted to blocks.
  • The Collectives parachain creates 7,200 blocks per day.
  • One year is 365.25 days, or 2,629,800 blocks.
  • One month is 365.25 days / 12, or 219,150 blocks.
• The salary asset, USDT, has 6 decimal places. That is, 1 USDT is 1_000_000 units.
• On passive allowance, the Manifesto states that passive salaries should be "no greater than 50% of
  standard". I have set them to exactly 50%. Perhaps they should be lower and/or have a cap?

Values

• Active Salary (RFC 50)
  1. 10,000,000,000 (10,000 USDT)
  2. 20,000,000,000
  3. 80,000,000,000
  4. 120,000,000,000
  5. 160,000,000,000
  6. 200,000,000,000
  7. 200,000,000,000
  8. 200,000,000,000
  9. 200,000,000,000
• Passive Salary (Manifesto Section 8: Allowances)
  1. 5,000,000,000 (5,000 USDT)
  2. 10,000,000,000
  3. 40,000,000,000
  4. 60,000,000,000
  5. 80,000,000,000
  6. 100,000,000,000
  7. 100,000,000,000
  8. 100,000,000,000
  9. 100,000,000,000
• Demotion Period (Manifesto Section 4.3: Continuation)
  1. 657,450 (3 months)
  2. 657,450
  3. 1,314,900 (6 months)
  4. 1,314,900
  5. 1,314,900
  6. 1,314,900
  7. 0 (infinite)
  8. 0
  9. 0
• Min Promotion Period (Manifesto Section 5: Rank Summary)
  1. 0
  2. 2,629,800 (1 year)
  3. 2,629,800
  4. 2,629,800
  5. 2,629,800
  6. 2,629,800
  7. 2,629,800
  8. 13,149,000 (5 years)
  9. 21,038,400 (8 years)
• Offboard Timeout (No reference found)
  • 2,629,800 (1 year)

Execution Info

• Encoded call
• Call should be executed on the Fellows track, as per the Params Origin.

[andresilva]

Should we also approve all existing members from the fellowship-collective? This would make sure that everyone gets inducted into the core-fellowship pallet (otherwise they stay in a limbo where promotion/demotion rules aren't applied), and would also make sure that everyone's last_proof gets set to the same block (members that have already been inducted into core-fellowship have an older last_proof).

[joepetrowski]

These will do all ranks 1-4 but with unsynchronized enactment. Will change the dispatch time to a shared block number once we are ready to submit.

Accept all rank 1

• Preimage
• Referendum

Accept all rank 2

• Preimage
• Referendum

Accept all rank 3

• Preimage
• Referendum

Accept all rank 4

• Preimage
• Referendum

Rank 0 doesn't apply IIUC. Ranks 5 and 6 will need public referenda, see next comment below.

---

Calls generated using https://github.com/joepetrowski/core-fellowship-accept-all/

---

EDIT: Fixed Fellowship tracks (all were RetainAt1Dan before).

[joepetrowski]

Is this really based on collectives parachain blocks as opposed to relay chain blocks? If so, can we fix this (as a followup of course). Using the parachain blocks breaks once we switch to async backing and also prevents core sharing.

Yeah exactly, that was my plan that when we switch to async backing we will need to update anyway and should switch to using the Relay Chain block number as the "clock" to allow core sharing.

[joepetrowski]

Yeah, that's a good idea. But the origin to retain corresponds to each rank, so we will need to set up a series of referenda to do that. We can schedule them all to enact on the same block.

[joepetrowski]

Public referendum preimage (for Relay Chain) for ranks 5 and 6. Should be on FellowshipAdmin track.

0x630003000100a50f03242f0000060302943577821a0600903f03f0673d30606ee26672707e4fd2bc8b58d3becb7aba2d5f60add64abb5fea47100600060302943577821a0600903f037628a5be63c4d3c8dbb96c2904b1a9682e02831a1af836c7efc808020b92fa630600060302943577821a0600903f033c235e80e35082b668682531b9b062fda39a46edb94f884d9122d86885fd5f1b0600060302943577821a0600903f035c5062779d44ea2ab0469e155b8cf3e004fce71b3b3d38263cd9fa9478f12f280500060302943577821a0600903f03522523da8f16bc0b51cfd6e8b113f65f6be19f19681d5d6269cb980f9582c3340500060302943577821a0600903f03bc64065524532ed9e805fb0d39a5c0199216b52871168e5e4d0ab612f8797d610500060302943577821a0600903f032e1884c53071526483b14004e894415f02b55fc2e2aef8e1df8ccf7ce5bd55700500060302943577821a0600903f039c84f75e0b1b92f6b003bde6212a8b2c9b776f3720f942b33fed8709f103a2680500

Someone double check :). @muharem should the origin be Xcm or Superuser? IIUC Xcm is correct.

[joepetrowski]

Referenda are up:

• Set Params: https://collectives.polkassembly.io/referenda/57
• Accept 1: https://collectives.polkassembly.io/referenda/58
• Accept 2: https://collectives.polkassembly.io/referenda/59
• Accept 3: https://collectives.polkassembly.io/referenda/60
• Accept 4: https://collectives.polkassembly.io/referenda/61
• Accept 5 and 6: https://polkadot.polkassembly.io/referenda/400

[eskimor]

Is this really based on collectives parachain blocks as opposed to relay chain blocks? If so, can we fix this (as a followup of course). Using the parachain blocks breaks once we switch to async backing and also prevents core sharing.