polkadot-fellows / dashboard Goto Github PK

Explain in a new section how members should interact with the fellowship pallet and salary pallet

Create connectivity button/modal with web and hardware wallets

Rewrite the summary of the page - explaining what Fellowship is following the text below:
"The Fellowship collective is an on-chain body designed to ensure the Polkadot network is able to incentivise, recognise ans retain expertise and knowledge over its protocol to guarantee continued maintenance and innovation.

As an on-chain self-sovereign social body aspiring to be both technocratic and meritocratic, it is crucial that Fellowship members are active in both reviewing the level of expertise of their peers and, importantly, reporting these evaluations. Without a system which enables a fluid and barrierless review-and-report cycle, valuable peers worthy of merit may languish at low-grades or be demoted. A difficult or tedious process may mean a lower candidate intake leading to attrition. Finally, and most importantly, if the UX is not sufficiently painless then oversight of the processes, and particularly promotion, becomes compromised which itself could lead to systemic security problems with the overall Polkadot governance system.

The document presents an overview on how best to enable Fellowship members and aspirational candidates to utilise and service this on-chain collective."

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.

Following this repo we can integrate the Polkadot-SDK first issues as an onboarding support into the dashboard

Following the document: https://github.com/polkadot-fellows/runtimes/blob/main/docs/on-chain-identity.md add a new menu button called FAQ that will include this (and more in the future)

Add more information for:

• How to become a candidate
• How to not get demoted. i.e. the responsibilities. (for rank 1, 2, 3, and so on)
• How to get promoted (to rank 1, 2, 3, and so on)
• How to setup identity and link to github handle
• How to use review bot and merge bot
• How to use rfc bot
• How to find a mentor
• The online and offline events (e.g. the OpenDev Monthly Call)
• Meeting notes

There is the section "Becoming a Member" here https://polkadot-fellows.github.io/dashboard/#/membership, thanks for that. I think it should be extended with a "Preparations for joining" step:

• Studying the manifesto and subscribing to its vision + ideals.
• Set an on-chain identity on the Polkadot Relay chain (This needs to include your GitHub handle, see here).
• Put your account address into your GitHub Bio (example)
• Prepare a markdown document to outline your contributions and why you would make a valuable addition to the fellowship (example)
• Post this on the Polkassembly Induction request site from your correct Account
• Ping someone from the fellowship
• ???
• Profit

Ideally, some of these can already be checked by Polkassembly in the UI, but for now i think its faster if we write them down ourselves.

Wrote down some points here: https://hackmd.io/yoPVbx4BTgG_i3kDhCU_TA

These Qs seem to keep coming up over and over again and we are just at the very beginning of this 🤣
Should probably include it somewhere on the website.

In order to enrich Overview page we should add a Structure section, a Funding and History (mentioning GovV1) and probably also Goals.

A consolidated status feed on activity regarding the Fellowship including membership changes, rank alterations, salary payments and proposals.

A publically visible page displaying a classic "feed" of the activity happening across the Fellowship. Several events should be visible:

• New candidate inducted
• Candidate promoted to Member
• Member promoted
• Member proven
• Member demoted
• Candidate removed
• Evidence/request submitted
• Rank-request proposal created
• Rank-request proposal confirming
• General proposal (i.e. not concerning a member's rank) created
• General proposal confirming
• Member active
• Member inactive
• Fellowship parameters changed

We could either add it here in a new column, or a new page that shows the current status of a member.
AFAIK a member can be:

• unimported
• imported
• inducted into the core pallet
• inducted into the salary pallet
• registered for the next salary payout

I think they can be treated as a linear progression from the first to the last state. It would be nice to show this state, so we can know which member has to still do some calls (if they want). cc @wirednkod

There should be four main elements to Fellowship UX:

• #322 : A consolidated status feed on activity regarding the Fellowship including membership changes, rank alterations, salary payments and proposals.
• #323 : Facilitating eligible members to submit, inspect and vote on arbitrary Fellowship proposals generally as part of the wider Polkadot governance apparatus and often centering around whitelist_call. This is implemented to various degrees of usability in Subsquare, Polkassembly and Polkadot.js among others.
• #324 : Administration concerning one's member account, including rank and salary information and management functions.
• #325 : The inspection, discussion and judgement of rank-retention ("proving") and promotion requests.

Like it is done here: polkadot-fellows/RFCs#79 & polkadot-fellows/runtimes#202

A new popup/Overlay could be added - which upon clicking on the member's name/address, more info will appear.
These info could be all details that are retrieved already from the deriveAccountInfo

we have two fellowship UI and we should tell people about it

https://collectives.polkassembly.io/
https://collectives.subsquare.io/fellowship

A new section on more deep dives can be added, explaining the fellowship core pallet and salary pallet

Have a page lists all the open PR at https://github.com/polkadot-fellows/Evidences/pulls and extract information from the PR and display them nicely and have a button to aye / create proposal & aye or nay each request.

At the moment - for the first draft PolkadotJS API is used for fetching the members and querying their data;
It would be awesome to replace it with polkadot-api (see here: https://github.com/paritytech/polkadot-api/blob/main/experiments/src/client.ts)

Facilitating eligible members to submit, inspect and vote on arbitrary Fellowship proposals generally as part of the wider Polkadot governance apparatus and often centering around whitelist_call. This is implemented to various degrees of usability in Subsquare, Polkassembly and Polkadot.js among others.

Pre-existing user interfaces already include this functionality, so there is little to add here.

Rank-request voting, which is covered by other UX elements, should probably not be duplicated under the General voting portion of the UI, in order to minimise the possibility of confusion with two separate proposals.

At the moment - there is a fetch from Github that shows the RFCs that are currently open.
We should Add more info concerning these RFCs as can be seen here: https://github.com/polkadot-fellows/RFCs#bots

Administration concerning one's member account, including rank and salary information and management functions.

The concept of this UX element is essentially that of a user-account page. This should display all information relevant to a single candidate/member (which we would generally assume is the primary user account the UI is configured with).
Comment
Suggest edit

The information displayed should include:

• The current rank of the individual.
• Whether the individual is active (i.e. declared to draw a full salary).
• The deadline before which the individual must be promoted or retained/proven to avoid being demoted.
• The time at which the individual becomes eligible to request a promotion.
• The history of salary payments.

Several transactive actions should also be possible:

• The ability to set their status to active or inactive.
• The ability to reserve and request a salary payment if eligible.
• The ability to submit a request and evidence for rank-retention (proving) or, if eligible, promotion and (if a member) to open a vote on it.

As the deadline for demotion nears, the UI should warn the user clearly and encourage them to submit evidence and a request for retention.