Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Rank maintenance #325

Open
wirednkod opened this issue May 6, 2024 · 0 comments
Open

Rank maintenance #325

wirednkod opened this issue May 6, 2024 · 0 comments

Comments

@wirednkod
Copy link
Collaborator

wirednkod commented 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.

@wirednkod wirednkod changed the title Rank maintenance: The inspection, discussion and judgement of rank-retention ("proving") and promotion requests. Rank maintenance May 6, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant