User Tools
voting_system_overview
Differences
This shows you the differences between two versions of the page.
| Both sides previous revisionPrevious revisionNext revision | Previous revision | ||
| voting_system_overview [02/01/2023 13:15] – gfactor | voting_system_overview [03/24/2025 13:44] (current) – crowetic | ||
|---|---|---|---|
| Line 1: | Line 1: | ||
| - | ====== Voting System | + | ===== Updated Information About ' |
| + | \\ | ||
| + | The previous concept of a 'Voting System' for Qortal is now being modified. In a similar fashion to the new Minting Methods, the ' | ||
| + | \\ | ||
| + | \\ | ||
| + | === ' | ||
| + | GROUP_APPROVAL is essentially a method of ' | ||
| + | \\ | ||
| + | \\ | ||
| + | Group approval transactions are currently what control both the auto-update signatures for the developer group, and now also the MINTER group INVITES, and promotion of ' | ||
| + | \\ | ||
| + | \\ | ||
| + | Group approval will be leveraged more in the future as well, as it is a means to have a true 'group decision' | ||
| + | \\ | ||
| + | \\ | ||
| + | ===== Polling ===== | ||
| + | \\ | ||
| + | Qortal Also has a ' | ||
| + | \\ | ||
| + | \\ | ||
| + | Polling on Qortal may be utilized for any reason. Any user may create a poll and obtain the opinion of the community within said poll. | ||
| + | \\ | ||
| + | \\ | ||
| + | === Polling in Mintership === | ||
| + | \\ | ||
| + | In the new Minting concept, ' | ||
| + | \\ | ||
| + | \\ | ||
| + | Seeing this in action may be done within the ' | ||
| + | \\ | ||
| + | \\ | ||
| + | In Q-Mintership, | ||
| + | \\ | ||
| + | \\ | ||
| + | The poll attached to the card keeps track of votes from both users and Minter Admins separately. When the amount of Minter Admin poll results in the positive direction reaches the number required to obtain the 40% needed for the GROUP_APPROVAL transactions, | ||
| + | \\ | ||
| + | \\ | ||
| + | The polling here also keeps track of the weight of both the Admin poll results, and the Minter poll results, so that the card's support by not only the admins, but the general minting community may be taken into consideration by the admins. | ||
| + | \\ | ||
| + | \\ | ||
| + | There is also a location for comments to be published on the card. This way if a Minter or Admin wishes to, they may explain the rationale behind their vote, and why they voted the way they did. It is also possible for the user publishing the card to comment and make their case as to why they deserve to be one of the Minters of the Qortal Network. Discussion then takes place, poll results are obtained, and depending on the results of the admin poll results, actions may or may not be available to the Minter Admins, such as sending a GROUP_INVITE to the user whose card received aforementioned positive results. | ||
| + | \\ | ||
| + | \\ | ||
| + | Upon such a GROUP_INVITE being created, and since GROUP_INVITE transactions for the MINTER group(s) is (are) controlled by GROUP_APPROVAL, | ||
| + | \\ | ||
| + | \\ | ||
| + | Following the number of GROUP_APPROVAL transactions reaching the required percentage threshold (at the time of this writing, March 2025, that threshold is 40%, or 10 signatures total with 25 Minter Admins) the GROUP_INVITE transaction is then (and only then) made active, thus allowing the invited account to issue a JOIN_GROUP transaction, | ||
| + | \\ | ||
| + | \\ | ||
| + | Polling allows the creation of any poll with any number of potential poll ' | ||
| + | |||
| + | |||
| + | |||
| + | ===== Voting System Overview (deprecated, | ||
| + | \\ | ||
| + | (this data is here for historical reasons only, the methods surrounding ' | ||
| {{: | {{: | ||
| Line 14: | Line 69: | ||
| Voting will be used to help steer the project’s direction when possible. Rather than leaving everything up to the DevTeam, the community will be able to vote on certain matters with how the DevTeam should allocate their time with options presented to the community. Such as which coins or features to implement next, or certain modifications needing to take place and which options the community thinks are the best ones to pursue. There will NEVER be any voting for sanctioning or censoring as this will never be a possible action by the DevTeam! In the case of the Voting System itself, there does not seem to be any alternative solutions that could be presented as ‘options’ to vote on. This is a small example of how the DevTeam has to make decisions on behalf of the community, and the track record of building a system with genuine intention, deserves credit and trust. | Voting will be used to help steer the project’s direction when possible. Rather than leaving everything up to the DevTeam, the community will be able to vote on certain matters with how the DevTeam should allocate their time with options presented to the community. Such as which coins or features to implement next, or certain modifications needing to take place and which options the community thinks are the best ones to pursue. There will NEVER be any voting for sanctioning or censoring as this will never be a possible action by the DevTeam! In the case of the Voting System itself, there does not seem to be any alternative solutions that could be presented as ‘options’ to vote on. This is a small example of how the DevTeam has to make decisions on behalf of the community, and the track record of building a system with genuine intention, deserves credit and trust. | ||
| - | Voting will also be used for the community | + | Voting will also be used to help approve new developers as an admin of the DevTeam. What this means is that we have two types of DevTeam members: 1) anyone can join the team and help develop the codebase who DO NOT have the ability to vote on the 60% approval to push updates to the chain, and 2) DevTeam admins who DO have the ability to vote on the 60% approval to push updates to the chain. The DevTeam will vote to approve new admins by pushing the update with their 60% approval. This update will then assign the admin permission to the vetted dev(s) and it's official. It is extremely important to have this layer of security with these two types of DevTeam members as the DevTeam admins will be the only ones who can vote for a 60% approval to push updates. This creates a way for the DevTeam admins keep the rest of the DevTeam in check as DevTeam admins are the only devs who can push the 60% approval updates to the chain. |
| The community will NOT be voting to directly approve code updates. There' | The community will NOT be voting to directly approve code updates. There' | ||
| Line 24: | Line 79: | ||
| Of course at any time, anyone is able to submit pull requests. That will always remain an option and has nothing to do with the Voting System. | Of course at any time, anyone is able to submit pull requests. That will always remain an option and has nothing to do with the Voting System. | ||
| - | Voting System is expected to be implemented | + | Voting System is expected to be implemented |
| + | |||
| + | We also have made a blog explaining how Qortal is not a DAO: https:// | ||
voting_system_overview.1675275335.txt.gz · Last modified: 02/01/2023 13:15 by gfactor