Propose Navie Chan

[mkalinin]

Name: Navie Chan
Team: Independent Contributor
Discord Handle: NC#0558
Weight: partial, junior

Oct 2022 - Feb 2023: EPF

• Consensus client reward APIs overview
  • block_rewards and attestation_rewards in Lighthouse #3907
  • sync_committee_rewards in Lighthouse #3903

Feb 2023: Reth

• Adding test support for several API module to Reth #1288

Mar 2023 - Jul 2023: EIP-6110 prototype

• Besu implementation #5295, #5055
• EIP-6110 PEEPanEIP

May 2023: Erigon

• Diagnositc and debugging endpoints #7417, #10

Next plans

• Fixing some Hive tests for Besu
• Getting involved in ePBS implementation in Lodestar during at least next 3 months

[siladu]

Worked with Navie on and off throughout the Besu EIP-6110 implementation.

[philknows]

Transferring comment from Discord discussion on membership for juniors:

I can definitely see the risk we take by including people who have not yet "proven" themselves yet - but this is why we have the 6 month contribution minimum right? Though, the threshold of "proven themselves" is pretty subjective. If they have public work to show that they're capable in some useful way to protocol projects/teams, I'd be willing to support the individual and retain their drive + motivation to become better protocol contributors, especially since we don't weigh people's contributions here by the complexity of their work.

In the case of Navie, his own initiative led him to also reach out to Lodestar. Though he hasn't "proven" himself to our project yet, his past experiences outlined in @mkalinin's proposal is enough for us to give him some part-time work and a thumbs up to be part of PG, while understanding the risk that he may not be useful to us specifically or PG at all in the future... but the odds are he will be.

[siladu]

Regarding EPF devs, the current expected route to PG seems to be:

1. Complete EPF project
2. Get hired by client team
3. Client team proposes them for PG when they are willing to vouch for them

If it's not possible to be hired by a client team for reasons out of their control, then we risk losing this person and their expertise gained through EPF due to lack of funding. This is where I believe PG can help retain these people.

They are "junior" in the sense that they came into the space via EPF, however this route says nothing about their programming expertise. I think we could compare this situation to a new employee of a client dev team that joins the company with no prior blockchain knowledge. Should this new employee also be regarded as "junior" even after 6 months of working in the core protocol space?

Regarding external/independent devs more generally, I have put some thoughts on #92 (comment)

For Navie specifically, I can safely vouch for the portion of the proposed work that was done in Besu because I reviewed the code and had several in depth discussions. This was similar to working with a new employee of the Besu team: most of the questions were about the nuances of Besu. Upon completion of EIP-6110 they were immediately looking for the next thing to work on in Besu. I am confident they could continue having a positive impact in the Besu codebase should they choose.

In terms of keeping track of Navie's future contributions, that's harder to say since it's not clear whether they will mostly be in Besu, Lodestar or another area. All PRs are reviewed by at least one other Besu dev, so that is a natural collaboration point between Navie and the team. They may wish to collaborate to make use of our internal testing infrastructure as well.

I am happy to approve this PR based on my experience working with Navie, the other items on this PR (looks like 9 months of work total), Mikhail's endorsement and their plan for the future work.

[parithosh]

crossposting comment since it pretty much applies here as well: #92 (comment)