Threshold
Hello Gav !
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.
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 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, Issues with delayed responses, and finally documentation) to fully understand a concept (to the point where being able to properly explain it) 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:
currency to fungible) and,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 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.
As for the future, some improvement on my end might include the following actions:
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.
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.