# Fellowship Evidence Guidelines.

These are guidelines regarding rank retention and promotion. They are not (yet) official, but disregarding them may result in my abstention or downvote of your proposal.

## Care to Detail

Care must be taken. To have evidence reviewed is a privilege, not a right. Typos and spelling errors reflect very badly on the individual in question. Proper consideration should be given to grammar, punctuation and layout.

## Personal Responsibility

This organisation is not for you if you cannot take personal responsibility: The Fellowship is not a top-down militaristic organisation. You are expected to think for yourself, be curious and proactive in discovering the world and deciding your actions accordingly. You are expected to ask questions but beware that *lazy questions*--questions whose answers may be found by examination from first principle or whose answers may already be discovered easily--**will count against you**.

## Responsibility to Convince

It is the member's responsibility to ensure that their argument for retention or promotion is both transparant and in line with Manifesto requirements.

The member is making a claim: that they should attain or continue at a particular rank. The expectations for this are set in the Manifesto. It is their job to argue the claim in a sufficiently convincing fashion.

"I'm not a good writer", "I'm not a good arguer", "I'm not a good X, Y or Z" is unacceptable. This is a basic requirement to be in the Fellowship. Do not expect that to blindly write code alone is enough for even a rank 1 retention.

## Promotion to Rank III and beyond

I will generally downvote all such proposals unless I have conducted an in-person interview where the individual convinces me that they have reached a level of personal development and productive contribution to Polkadot in line with the Manifesto description.

What follows concerns only proposals for rank-retention or promotion to I or II Dan.

## Overview

The proposal must first and foremost be an *argument* to back up the *claim* of "I am worthy of rank ...".

It is crucial that a Fellow totally unfamiliar with your or your specific contributions can validate the argument within about ten minutes (a bit longer for promotions or higher grade retentions). If they cannot make a decision within that time after first seeing your propopsal, then they may reasonably downvote or abstain.

The argument should be made as a block of text which should be properly cited with links to *relevant* evidence. Not every single line of code written (or forum post reply, or response to query) may be worth linking.

Evidence is only there to help prove the claims of the argument, it alone is meaningless. Submitting a disinterested list of Github links vaguely concerning the individual's work will result in abstention or downvote.

## Basic arguments

Basic arguments (that for rank-retention of basic Members and Fellows who are active) should be half a page of A4 (around 2 minutes reading).

The argument should be an explanation drawing on the expectations given in terms the Manifesto, of why the member feels their contributions are worthy of rank retention at the given grade.

Code links (and indeed any other links, such as forum posts, articles, tweets, media) should be given only to help substantiate any arguments or claims within the main explanation and must be contextualised properly. *The reviewer will not to an undirected code review.*

## Other arguments

Passive or salaryless evidence need not be nearly so convincing on the basis that the Manifesto doesn't make so significant expectations.

Advanced arguments (Architects or I-Dan/II-Dan promotion) should be longer, and the review time accordingly more substantial.

## Thoughts on how to structure grading arguments

Understand that the point of a grading argument is to convince the viewer that your actions over the given period of time (since last grading) are of a quality and quantity in line with expectations set in the Manifesto.

An easy way of thinking about this is attempting to answer a question formed from each expectation. For example, Rank I (section 6.2) reads:

> The primary qualities which should be present and clear in those being given
the rank are aspiration, knowledge-discovery, knowledge-sharing and active main-
tenance. They should demonstrate commitment to the protocol’s development
through mastery of at least one major component as well as having a broad un-
derstanding across the protocol. They will demonstrate commitment to pooling
and sharing protocol knowledge through establishing a pattern of availability or
communication in one or more online media; forums, chatrooms, issue trackers or Q&A sites. A pattern of general avail- ability on synchronous communication media would also count in the individual’s favour and demonstrate a commitment to the network maintenance. The candidate should have a rudimentry awareness of, and ability to be educated on, overall priorities and tradeoffs in development & design of a global, decentralised and unstoppable network, including centralisation risks, non-jurisdictionality, privacy, automation & maintenance vs autonomisation & ownerlessness.
The Candidate must clearly demonstrate an independence of mind and spirit. They should be able to work alone and without direction, to investigate and problem-solve without need for assistance and to be responsible for the design, implementation and/or continued maintenance of a Polkadot component or sub-system which could reasonably be con- sidered important for the continued health and operation of the Polkadot network. The Candidate should be making clear demonstrations of protocol expertise.
There is no specific time which must have passed with Polkadot being the individual’s primary life-focus prior to attaining this rank, though a reasonable expectation would be that they have been working on core Polkadot technology continuously for around 12 months.
6.2.1. Requirements.
• Three clear examples of a modest but substantial contribution to protocol development.
• Actively been involved in the design of a component. The component should be either deployed into the protocol
or reasonably intended for future deployment into protocol *and* at the standard expected of a PRP2.
• Substantially assisted in the analysis, or authoring of formalisation or implementation of a protocol component. Formalisation should be at the standard expected of a peer-reviewed publication. Analysis should either lead to a change in the protocol or be at the standard expected of a PRP. Implementation should be in a functional
implementation of the protocol.
• Should be able to list all key goals, principles and tenets of Polkadot’s overall philosophy.

This can be transformed pretty much directly into a prompt:

1. Describe (along with evidence if needed) three clear examples of a Modest-but-Substantial (MbS) contribution to protocol development. In all cases, explain why the contribution fits the description of Modest-but-Substantial. See below for the description.
2. Explain the nature and extent of your active involvement in the design of a protocol component which forms (or is likely to form, with according reasoning) part of the Polkadot protocol in the future.
3. Explain the nature and extent of your assistance in the introduction of a protocol component. This should be either through implementing it, analysing it or formalising its design.
4. Provide a brief personal insight into one or more of the key goals, principles and tenets of Polkadot. Draw upon personal experience, which may or may not be related to your technical contributions, to explain it/them in concrete terms or through your personal experience. Why is Polkadot and Web3 something sensible to be building?
5. How have you demonstrated a commitment to knowledge-availability? Over what media have you contributed to active knowledge sharing and social coordination? Provide links to your active user-profile on one or more forums, chatrooms, issue trackers or Q&A sites where you have been sharing and collaborating. If not immediately obvious from the user-profile page, provide examples of consistent, substantial and valuable activity.
6. To what extent have you made yourself generally available? Can you demonstrate it?
7. How have the priorities and trade-offs in development & design of a global, decentralised and unstoppable network, including centralisation risks, non-jurisdictionality, privacy, automation & maintenance vs autonomisation & ownerlessness affected you? Can you point to one or more public posts, replies, or articles where you show an awareness of these issues, perhaps by discussing, answering or offering an insight?
8. Demonstrate an independence of mind and spirit. How you have worked alone and without being directed to arrive at a result which is considered within the Fellowship or wider community valuable for the network? Give evidence not merely of the existence of such a result, but also explain how it was under your own direction. What brought you to do it?

> Possible examples of a “Modest-but-Substantial contribution” may be:
• identifying and correcting a non-trivial issue in protocol code or formalisation;
• being available and playing a crucial operational role for a network fix;
• proposing a reasonable and non-trivial protocol innovation; or
• doing a valuable, innovative and insightful refactoring or simplification.

## Other bits

Fellows shouldn't generally be judging code as part of the review. I already wrote this in my guidelines: "The reviewer will not to an undirected code review."

Reading and reviewing code takes time. Large amounts of time is not something which we want every Fellow to be dedicating to every Member every 3 months.

In any case, digital-domain rank-evaluations are only done for retentions and I and II Dan promotions.

Whereas for III Dan and above promotions we can afford some time to evaluate, they still will not centre around code reviews. Nowhere in the manifest does it say that members will be judged even primarily on code quality. Nor should it. Membership and rank is about much more than that and it is not the responsibility of Fellows to judge code as part of rank-evaluation.

For promotions it may not be entirely unrealistic to test the water prior to putting in a motion.

For retention, it's different: the member should already be intimately familiar with the expectations of their rank and should have no trouble putting forth a clear argument for rank-retention. Links to evidence should be supplied, but only to ground and substantiate their argument, not for primary review.

The linked evidence should be of self-proving quality, either intrinsically or due to standing attestations of others (e.g. media, peer-reviewed articles, Fellowship-reviewed code).

Realistically, many members with ambition to climb the ranks are going to have to get more active on GH, forums, blog posting and chat. It's not all about code: it's also about explaining, conceptualising, helping, sharing and solving. None of these things can be proven by dumping a link to some code at the door.

It is up to the member to *make an argument*. If they are not familiar with this concept, The ability to argue constructively is pretty much a requirement to become a Fellow and really rather important even just to be a Member. Those unfamiliar or otherwise lacking confidence in their knowledge/ability here might want to read a little bit of philosophy and discover the basics of Critical Rationalism. A good start is [A Pocket Popper](https://www.amazon.com/Pocket-Popper-Karl/dp/0006861474).

Finally, take responsibility for your personal development and with it, your grade. Accept your weaknesses and strive to improve. Avoid placing the blame on others (or on fortune) for your own setbacks. Accept that ones environment is largely out of ones control and strive to manage your environmental interactions not through power over others but through self-discipline, self-improvement and self-empowerment. Read a little (or a lot) about [Existentialism](https://ethics.org.au/ethics-explainer-existentialism/) and consider the anti-Essentialist doctrine of "Every decision you make is yours. You create your own purpose through your actions."

### Again

Again, it's not so much about the code itself, but what the code represents.

More senior coding members should be helping affect changes which result in greater value to the project than might be expected at lower ranks. One potential reading of this is that they single-handedly conceive, design, architect, implement, document, test and integrate a major piece of functionality or refactor. But it's far from the only way.

Even in this case, it's not about reviewing the code they wrote and its size, quality or sophistication (all of which are important from a code-review perspective), but about the final result. Does anyone else understand it? Does it actually help Polkadot? Was it a good use of their time?

The answers to these questions should be established only minimally by looking at the code itself, but more so by looking around the work - how much do others value it? Did it pass review without major changes? How sensible/optimal/clever do others believe the design is? How much did the individual rely on others to find bugs in their code versus how many bugs did they find in others' code? Is it well-documented? Did they promote/explain any new functionality it brought in an appropriate way to a relevant audience?

There's likely only a need to take a substantial look the real technical work (code & API design, documentation, design & architecture) during the III and IV Dan gradings themselves. I and II Dan should rely on the usual Fellowship review.

> Anaelle LTD | Fellowship Secretary: For example, a Rank 1 member is often blindly trying to work his/her way around the Polkadot SDK. With all the good intentions in the world, s/he might decide that a certain PR demonstrate his/her skills and understanding of the Polkadot SDK at rank 1. But she is wrong: her PR is at candidate-level. Yet, because s/he hasn't got enough experience with both the Polkadot SDK and the Evaluation process of the Manifesto, s/he can't see that s/he has made an error of judgement on his/her own evidence. And thus, the retention proposal gets rejected.

Then they should read and re-read the manifesto, and ask sensible questions in the relevant channels rather than cluelessly submitting retention proposals. The Fellowship is not intended to create an army of blind worker-bees. If they cannot investigate and discover the world themselves proactively, then they are not worthy of I Dan.