ambassador

senior_ambassador

head_ambassador

The evidence supplied here is decidedly sparse and opaque. The point of having evidence at all is to minimise the time needed to be spent by all the Fellows.

The first item is trivial and barely deserves the time of the fellows to review it. The final item is no evidence whatsoever and unless there is additional evidence demonstrating *actual work done by the member* then should never have been placed in.

The second item is probably the bare minimum that's worth even mentioning and the third is where 98% of the relevant coding time appears to have been spent.

There is no description of why the work is of sufficient quality and depth that it should be considered relevant for renewal of an active I Dan grade. There is no description of what the member has learned during their three months of active protocol development. There is no attempt to connect work done to the Manifesto and its requirements.

Hello [Gav](16SDAKg9N6kKAbhgDyxBXdHEwpwHUHs2CNEiLNGeZV55qHna-collectives)!

I see your point. Being my first report ever, I wasn't completely sure as to what would be expected. After reading your notes on acceptable quality for a retention evidence report, I understand that more description is helpful not just to ease reviewing but also to help peers understand the worthiness and even—if willing to— help nurture those people who (like me) are starting on their path.

I acknowledge all those remarks, which I will heavily consider for future evidence reports.

That said, I'll use the remaining space in this comment to complement a statement that can help better understand the approach I've taken so far.

### Contributions so far

Paraphrasing a bit from the manifesto:

> After being inducted, every member finds themselves in a position where they must pick an initial component to show some degree of mastery to contribute as they learn about other parts and acquire a more integral knowledge of the protocol as a whole, then start contributing.

My initial component in the protocol to contribute to has been **tokens** (fungibles, non-fungibles). Since it is pretty much stable and mostly complete (at least on the fungible part), there's not much active development, and the maintenance work needed is pretty low (a quick search on the Mentor Issues [Dashboard](https://mentor.tasty.limo/) can illustrate this case). Another problem with this component is that review times are longer (as not many people are available to be actively involved in that part), and auditing needs to be exhaustive (for obvious reasons, this part is so close to the protocol's core).

This leads to the point where contributions in this field must be evaluated in terms of quality instead of quantity. As an example, it didn't take me almost two months to build `pallet-assets-holder` because of laziness, but because it took me weeks after discussions (on [OpenDev](https://forum.polkadot.network/t/2024-05-21-technical-fellowship-opendev-call/8264#define-and-implement-hold-for-assets-pablo-17), [Issues](https://github.com/paritytech/polkadot-sdk/issues/4315) with delayed responses, and finally documentation) to fully understand a concept (to the point where [being able](https://github.com/paritytech/polkadot-sdk/pull/4530#discussion_r1708418726) to properly [explain it](https://github.com/paritytech/polkadot-sdk/pull/4530#discussion_r1707715812)) as balance components. Only after that was it possible to spend some _coding time_ without incurring bad suggestions. This not only demonstrates how the process of documentation is still in progress but also my dedication to learning about the protocol.

Despite the challenges, two reasons motivated me to go forward on that path:

- There's still a lot to work to do in terms of maintenance (migrating from `currency` to `fungible`) and,
- There's still a lot of work to do about filling gaps (like completing implementations of `fungibles` for `pallet-assets`, migrating `pallet-vesting` to `fungibles`, NFTs trading with assets, etc.) to enable use cases the protocol will benefit from in a future perspective.

However, I acknowledge that a single contribution over a three-month period might not be enough. This is why I've also been open to learning about other parts of the protocol and attempting other contributions, with varying degrees of success (like this [other contribution](https://github.com/paritytech/polkadot-sdk/pull/4228) started in this period, which will probably be stale or closed due to the raising concerns). This helps to illustrate why additional contributions might look so sparse.

### Future Improvement

As for the future, some improvement on my end might include the following actions:

1. I should include more active maintenance to complement the few high-quality, high-effort contributions I've made to the protocol so far.
2. Get involved in reviewing code. In this particular case, I've refrained from doing so because reviewing code at this stage might sound too arrogant from my end, considering my experience working with the protocol spans about a year and a half.
3. Get involved in more areas. This is active work on my part. I've been observing how to contribute in areas like XCM and will definitely deliver some contributions regarding governance in the following days.

### Final concerns

A final concern I would raise to be addressed is that it's not clear who to communicate. Counterintuitively, I haven't struggled to ask for help (the Element chat and OpenDev Calls are there for a reason), but to receive it after that. A suggestion might be a directory of who to talk to when trying to address a question/asking for a review.

atRank

Executed

Submitted

DecisionStarted

DecisionDepositPlaced

ConfirmStarted

Confirmed

retain_at_i_dan

Retain Pablo Dorado at Rank I

# Evidence-0001: Retention at Rank _I_

|                 |                             |
| --------------- | ----------------------------|
| **Report Date** | 2024/07/31                  |
| **Submitted by**| Pablo Andrés Dorado Suárez  |

## Member details

- Matrix username: `@pandres95:bloque.team`
- Polkadot address: `12gMhxHw8QjEwLQvnqsmMVY1z5gFa54vND74aMUbhhwN6mJR`
- Current rank: 1
- Date of initial induction: [2024/04/19](https://collectives.subsquare.io/fellowship/referenda/105)
- Date of last report: N/A
- Area(s) of Expertise/Interest: Assets, NFTs, Governance, XCM

## Reporting period

- Start date: 2024/04/19
- End date: 2024/07/31

## Evidence

| Areas of Contribution | Tasks | Links | Notes |
| --------------------- | ----- | ----- | ----- |
| Fellowship Runtimes   | Allow Sending XCM messages using a Signed origin on Kusama | [Runtimes #290](https://github.com/polkadot-fellows/runtimes/pull/290) | |
| Polkadot SDK          | [Assets] Call implementation for `transfer_all` | [Polkadot SDK #4527](https://github.com/paritytech/polkadot-sdk/pull/4527) | _Approved_ / **In Auditing** ? |
| Polkadot SDK          | [Assets] Implement `pallet-assets-holder` | [Polkadot SDK #4530](https://github.com/paritytech/polkadot-sdk/pull/4530) | _In Progress_ / **Waiting for Review** |
| Fellowship Runtimes   | Implement Unbrick Collective | [Runtimes #376](https://github.com/polkadot-fellows/runtimes/issue/376) | _Preparing_ / **Gathering requirements** |

## Voting record

N/A

## Misc

- [ ] Question(s):

- [x] Concern(s):
  - Code Reviews / Merge Trains can be sometimes a bit slow, this might potentially affect what can be marked as completed by the time the evidence report comes.

- [x] Comment(s):
Consistent active participation to monthly Fellowship calls.

Evidence-0001: Retention at Rank 

members

proficient_members

fellows

architects

architects_adept

grand_architects

masters

masters_constant

grand_masters

retain_at_ii_dan

retain_at_iii_dan

retain_at_iv_dan

retain_at_v_dan

retain_at_vi_dan

promote_to_i_dan

promote_to_ii_dan

promote_to_iii_dan

promote_to_iv_dan

promote_to_v_dan

promote_to_vi_dan

fast_promote_to_i_dan

fast_promote_to_ii_dan

fast_promote_to_iii_dan

Origin aggregated through weighted votes of those with rank 1 or above; `Success` is 1. Aka the "voice" of all Members.

Origin aggregated through weighted votes of those with rank 2 or above; `Success` is 2. Aka the "voice" of members at least II Dan

Origin aggregated through weighted votes of those with rank 3 or above; `Success` is 3. Aka the "voice" of all Fellows

Origin aggregated through weighted votes of those with rank 4 or above; `Success` is 4. Aka the "voice" of members at least IV Dan

Origin aggregated through weighted votes of those with rank 5 or above; `Success` is 5. Aka the "voice" of members at least V Dan

Origin aggregated through weighted votes of those with rank 6 or above; `Success` is 6. Aka the "voice" of members at least VI Dan

Origin aggregated through weighted votes of those with rank 7 or above; `Success` is 7. Aka the "voice" of all Masters

Origin aggregated through weighted votes of those with rank 8 or above; `Success` is 8. Aka the "voice" of members at least VIII Dan

Origin aggregated through weighted votes of those with rank 9 or above; `Success` is 9. Aka the "voice" of members at least IX Dan

Origin aggregated through weighted votes of those with rank 3 or above when voting on a fortnight-long track; `Success` is 1

Origin aggregated through weighted votes of those with rank 4 or above when voting on a fortnight-long track; `Success` is 2

Origin aggregated through weighted votes of those with rank 5 or above when voting on a fortnight-long track; `Success` is 3

Origin aggregated through weighted votes of those with rank 6 or above when voting on a fortnight-long track; `Success` is 4

Origin aggregated through weighted votes of those with rank 7 or above when voting on a fortnight-long track; `Success` is 5

Origin aggregated through weighted votes of those with rank 8 or above when voting on a fortnight-long track; `Success` is 6

Origin aggregated through weighted votes of those with rank 3 or above when voting on a month-long track; `Success` is 1

Origin aggregated through weighted votes of those with rank 4 or above when voting on a month-long track; `Success` is 2

Origin aggregated through weighted votes of those with rank 5 or above when voting on a month-long track; `Success` is 3

Origin aggregated through weighted votes of those with rank 6 or above when voting on a month-long track; `Success` is 4

Origin aggregated through weighted votes of those with rank 7 or above when voting on a month-long track; `Success` is 5

Origin aggregated through weighted votes of those with rank 8 or above when voting on a month-long track; `Success` is 6

Origin aggregated through weighted votes of those with rank 3 or above when voting on a 30 day long track; `Success` is 1.

Origin aggregated through weighted votes of those with rank 4 or above when voting on a 30 day long track; `Success` is 2.

Origin aggregated through weighted votes of those with rank 5 or above when voting on a 30 day long track; `Success` is 3.


Report Date	2024/07/31
Submitted by	Pablo Andrés Dorado Suárez

Areas of Contribution	Tasks	Links	Notes
Fellowship Runtimes	Allow Sending XCM messages using a Signed origin on Kusama	Runtimes #290
Polkadot SDK	[Assets] Call implementation for `transfer_all`	Polkadot SDK #4527	Approved / In Auditing ?
Polkadot SDK	[Assets] Implement `pallet-assets-holder`	Polkadot SDK #4530	In Progress / Waiting for Review
Fellowship Runtimes	Implement Unbrick Collective	Runtimes #376	Preparing / Gathering requirements

Retain Pablo Dorado at Rank I

Evidence-0001: Retention at Rank I

Member details

Reporting period

Evidence

Voting record

Misc