# Polkadot (Core) Fellowship UX Guidelines

## Summary

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.

## Modules

In the interests of modularity and reusability, the Polkadot Fellowship is split across several on-chain modules (pallets):

- `pallet_ranked_collective`: This manages the members and candidates of the Fellowship body together with their rank.
- `pallet_referenda`: This gives an on-chain "voice" (specifically, several Frame `Origin`s) to the Fellowship body through proposals and voting by members, with eligibility and weighting of those votes according to a member's rank. Voting on induction of candidates, and promotion and retention of members are conducted by this module.
- `pallet_core_fellowship`: This controls the overall process of induction, promotion and demotion according to the Fellowship rules and timelines, and handles the retention of "evidence" which members and candidates submit for these processes.
- `pallet_salary`: This controls the payments which eligible members are afforded.

It must be understood that these module boundaries are an artefect of the technical implementation and **should in no way inform the user-experience**. Users are concerned only with their benefits and responsibilities which come with being a (perhaps aspirational) member of the Fellowship.

## Basic UX Structure

There are four main elements to Fellowship UX:

- *Overall activity*: A consolidated status feed on activity regarding the Fellowship including membership changes, rank alterations, salary payments and proposals.
- *General voting*: 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.
- *Membership*: Administration concerning one's member account, including rank and salary information and management functions.
- *Rank maintenance*: The inspection, discussion and judgement of rank-retention ("proving") and promotion requests.

Each of these four elements should probably have an associated "view" and series of actions allowing members to interact:

### Overall activity

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

### General voting

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.

### Membership

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).

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.

### Rank maintenance

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.

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.

### Grading

For Fellows, grading might easily become a laborious piece of administration leading to spurious and inconsistent voting. I and II Dans suffer a 3 month rank-retention period, meaning several dozen lower ranks must be appraised by each upper rank each quarter. In busy periods, a week-long vote may not be enough time for a Fellow to properly determine if the Member should retain their rank. Code needs to be checked, activity verified and judged, notes appraised and so on.

A more advanced UI will allow for *passive appraisal*. In its simplest form, the UI can provide the user with a simple table of each member who is at least two ranks their junior and allow them to mark the individual with either "promotable", "retainable", "not retainable" and "unknown" (the default).

If there are individuals whose retention or promotion is up for vote and who already have an appraisal by the user, then they would be prompted to sign a batch of votes reflecting their opinions.

A more sophisticated UI would allow tabulation of both qualitative entries (notes) and quantitative entries like strong-Promote, promote, retain, demote, strong-Demote; a simple graph could be presented to the user allowing them to see at a glance the relative quantities of P/p/r/d/D for each individual together with a default judgement based on them.

An even more sophisticated UI could see the UI scraping online sources such as GitHub, Element, the forum and StackExchange, looking for explicit interactions between the user and the individuals. Most platforms easily allow for a conversation point to be marked with an emoji, which can be very helpful in understanding levels of praise or correction. If the user is primarily bestowing 👍, ❤️ or 🎉 on the individual, then it is likely that they are impressed with their activity. If there are comparatively many exchanges between the two ending in no emojis from the user, it could be an indication of either a lack of independence or frequent mis-steps, and the UI can prompt the individual to examine and possibly grade these exchanges.

AI chatbots may also play a crucial role in analysing the discourse and summarising whether the user is impressed by the individual's output and to what degree the individual apparently needs to be corrected by their peers. Recent work by the Parity data team seems to indicate that chatbots are capable of doing accurate sentiment analysis which could help inform the UI and prompt the user into a vote representative of their interactions.

## User stories

### Application

#### Desire

User wants to become a I Dan member.

#### Process

1. User has presumably determined that they probably fulfil requirements of I Dan according to manifesto.
1. Off-chain, EITHER user finds a Fellow willing to put them forward; OR user finds a Member to bring forward

### Induction

### Rank-retention ("Proving")

### Promotion

### Salary payment

### Grading