You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The inspection, discussion and judgement of rank-retention ("proving") and promotion requests.
This should be presented in a manner not entirely dissimilar to that of General voting. However with Rank voting, the human-readable body of text which describes why the proposal should be approved is submitted and held as part of the pallet_core_fellowship, and it is this which should be displayed prominently.
Comment
Suggest edit
Posting should be restricted to members of the Fellowship and the data should be stored on an easily accessible platform to avoid segregation of the discussion. Though not yet implemented, CoreFellowship pallet could reasonably provide a means of allowing members to place remarks in the block body (as per the remark transaction) for free subject to rate-limitation.
Vote eligibility should be prominently displayed according to the active user account's rank. The Fellowship whitepaper contains clear guidelines for a member's voting behaviour at each rank. The chain should be scraped for historical Fellowship votes, and voting behaviour of the member in question should be evaluated according to these guidelines and displayed.
Once evidence is submitted by a member/candidate, this view on it should exist. From there, there should a trivial means allowing the member (or some sponsoring member, if the individual is presently a candidate) to create a proposal to pass the request, assuming they see fit.
Voting to pass (or not pass) should be trivial.
Adding a second, duplicate proposal to pass the request should not be a action facilitated in the UI. However there can be no guarantee that only a single such proposal exists. Therefore all active proposals must be scanned by the UI and all proposals containing a call to pass the member must be displayed.
The page should track the overall timeline of the proposal, including when the request/evidence was first submitted, when proposal to retain/promote the member/candidate was created, when said proposal began being decided, when it began/ended being confirmed and when the result became finalised.
The text was updated successfully, but these errors were encountered:
wirednkod
changed the title
Rank maintenance: The inspection, discussion and judgement of rank-retention ("proving") and promotion requests.
Rank maintenance
May 6, 2024
The inspection, discussion and judgement of rank-retention ("proving") and promotion requests.
This should be presented in a manner not entirely dissimilar to that of General voting. However with Rank voting, the human-readable body of text which describes why the proposal should be approved is submitted and held as part of the
pallet_core_fellowship
, and it is this which should be displayed prominently.Comment
Suggest edit
Posting should be restricted to members of the Fellowship and the data should be stored on an easily accessible platform to avoid segregation of the discussion. Though not yet implemented, CoreFellowship pallet could reasonably provide a means of allowing members to place remarks in the block body (as per the remark transaction) for free subject to rate-limitation.
Vote eligibility should be prominently displayed according to the active user account's rank. The Fellowship whitepaper contains clear guidelines for a member's voting behaviour at each rank. The chain should be scraped for historical Fellowship votes, and voting behaviour of the member in question should be evaluated according to these guidelines and displayed.
Once evidence is submitted by a member/candidate, this view on it should exist. From there, there should a trivial means allowing the member (or some sponsoring member, if the individual is presently a candidate) to create a proposal to pass the request, assuming they see fit.
Voting to pass (or not pass) should be trivial.
Adding a second, duplicate proposal to pass the request should not be a action facilitated in the UI. However there can be no guarantee that only a single such proposal exists. Therefore all active proposals must be scanned by the UI and all proposals containing a call to pass the member must be displayed.
The page should track the overall timeline of the proposal, including when the request/evidence was first submitted, when proposal to retain/promote the member/candidate was created, when said proposal began being decided, when it began/ended being confirmed and when the result became finalised.
The text was updated successfully, but these errors were encountered: