Comments (8)
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)
- 10,000,000,000 (10,000 USDT)
- 20,000,000,000
- 80,000,000,000
- 120,000,000,000
- 160,000,000,000
- 200,000,000,000
- 200,000,000,000
- 200,000,000,000
- 200,000,000,000
- Passive Salary (Manifesto Section 8: Allowances)
- 5,000,000,000 (5,000 USDT)
- 10,000,000,000
- 40,000,000,000
- 60,000,000,000
- 80,000,000,000
- 100,000,000,000
- 100,000,000,000
- 100,000,000,000
- 100,000,000,000
- Demotion Period (Manifesto Section 4.3: Continuation)
- 657,450 (3 months)
- 657,450
- 1,314,900 (6 months)
- 1,314,900
- 1,314,900
- 1,314,900
- 0 (infinite)
- 0
- 0
- Min Promotion Period (Manifesto Section 5: Rank Summary)
- 0
- 2,629,800 (1 year)
- 2,629,800
- 2,629,800
- 2,629,800
- 2,629,800
- 2,629,800
- 13,149,000 (5 years)
- 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.
from runtimes.
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
).
from runtimes.
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
Accept all rank 2
Accept all rank 3
Accept all rank 4
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).
from runtimes.
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.
from runtimes.
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.
from runtimes.
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.
from runtimes.
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
from runtimes.
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.
from runtimes.
Related Issues (20)
- [Ambassadors] Reduce `MaxRank` to 3 HOT 1
- `Fail when author pushes new code` should check if the user is not a fellow HOT 1
- Optimistic Project Funding HOT 22
- Implement Unbrick Collective HOT 3
- [CI] Publish unoptimized runtime blobs for debugging HOT 2
- [People] Add new registrar HOT 11
- PeopleKusama, PeoplePolkadot and Encointer don't have price for parent delivery set up HOT 2
- Add fee estimation support for XCMs over P<>K and P<>E bridges
- Treasury Configuration(s) for Multi-Chain Spends HOT 1
- [bridges][AHs] Include ExportMessage fees in XCM message from AH to BH HOT 2
- Update CI for Polkadot People Chain HOT 2
- Remove `chain-spec-generator`
- Check `merge bot` and required pipelines HOT 8
- Add test for coretime Runtime API HOT 1
- Coretime Runtime API: Refactor `burn_at_relay`
- Review bot error: Reviews may only be requested from collaborators HOT 6
- Field `image` on people chain is unusable HOT 5
- Enable StorageWeightReclaim for all the runtime HOT 2
- Consider using `RuntimeGenesisConfig` instead of directly constructing json for the preset genesis patch
- Actually benchmark `pallet_xcm::execute` for all runtimes HOT 2
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from runtimes.