Propose Kevin Bogner

[mkalinin]

Name: Kevin Bogner
Team: Independent Contributor
Discord Handle: Kevin Bogner#3923
Weight: partial, junior

Oct 2022 - Feb 2023: EPF

• First Commit
• Consensus client reward APIs overview
  • block_rewards and attestation_rewards in beacon-APIs #260
  • sync_committee_rewards in beacon-APIs #262
  • attestation_rewards API in Lighthouse #3822
• Development Updates
• IRL Meetup, Denver
• ETHDenver Presentation

Extra

• Lighthouse Node Guide

Mar 2023 - Jul 2023: EIP-6110 prototype

• EIP-6110 Prototype
• Devnet Config Update
• Genesis Generator Fix
• EIP-6110 PEEPanEIP
• EIPs Typo Fix

Next plans

• Finish deposit fuzzer tool, https://github.com/kevinbogner/deposit-fuzz
• Keep contributing to Lighthouse and probably Reth

[potuz]

I have mixed feelings about these PRs so I'll leave some remarks here. I am torn about on the one hand the fact that these are good candidates that are actively contributing and we want to attract these people to the field, which is one of the core tenets of the PG. On the other hand, it worries me a bit with regards to fairness. These are external contributors and it's very hard, if not impossible to be able to vouch for the time invested. If anything the projects to which they contribute are the most qualified people to judge the level of contributions, particularly compared with their peers. In this particular case for example, I understand LightHouse already has fully employed ex EPF that are working full time and they aren't being currently proposed. This signals to me that those candidates (or these candidates in fact) haven't passed the bar for nomination within the Lighthouse project. Approving this case without approving a fully employed case I think can even be source of friction (I am talking without knowledge here, pure speculation).

I would rather be cautions on external and independent contributors to fully established teams. And in particular I would think that when is that team the one nominating, that would make for a stronger case.

[AgeManning]

@potuz comments are accurate in my opinion. We (Lighthouse) keep track and curate our internal team members and attempt to uphold the PG standards as we have interpreted them. This may mean some of our team members are not applicable, or may get proposed later (like some prysm team members being proposed > 6 months).

I think on rare occasions (we typically err on the side of caution) we will propose outstanding external contributors that have shown continual development and we believe will continue to do so. If we propose a candidate, we would keep track of members we proposed in the spirit of the PG self-governance.

Because we err on the side of caution, I think (other's may want to chime in here) that we wouldn't have proposed Kevin.

I can only add my personal opinion here and I do not speak for the Lighthouse team here, in that I am not against adding Kevin. I think this decision will help set some precedence or standard as to how PG treats new external contributors. I'd be weary about who is keeping track of the future progress of external contributors that are not part of a client team however.

Also, if PG sets a set of standards/precedence of how we want to include new external contributors, the Lighthouse team can adjust how we are proposing members also.

[siladu]

I have put my thoughts on this PR #93 (comment)

But just to respond to a specific point on this PR...

These are external contributors and it's very hard, if not impossible to be able to vouch for the time invested.

I think this problem is present even for members of the same team/company to varying degrees. Some (most?) teams are highly distributed and interactions between some internal devs may be just as frequent/infrequent as interactions between other client team devs. I think timezone is a bigger factor in this than team membership.

I think the best way to vouch is via members' open source output...I'm not sure it's feasible to track actual time spent in all cases. Keeping track of a member's output can be done equally well for internal or external/independent contributors IMO.
At most, it may require some upfront ownership of the situation, e.g. matching an independent contributor with the subset of a client team who is in the same timezone.

Also, there are surely cases where some degree of eligible contributions are not visible in Github. I think these have to be dealt with on a case by case basis. Perhaps visibility of future work is a factor in vouching for an independent contributor. For client implementation work, this is usually quite visible. In Besu we review all PRs, so that is an obvious touch point with independent contributors. Testing work on our infrastructure may be another.

[parithosh]

I just wanted to chime in that I worked with both Kevin as well as Navie and can definitely vouch for their work. After some initial introduction to the tooling and some doc updates, they were able to maintain the testing infrastructure with minimal input from my side.

That being said, I'm taking away from the other comments that we might need to have "special" rules for external contributors due to the nature of them not being a direct part of a team. I guess we could probably consider that the bar for joining PG is higher as an external contributor that isn't strictly working with a single team as opposed to directly from a client team. Perhaps with this higher bar + knowing that the nomination came from a member (which I'd assume most of us don't do lightly) would imply that there was enough due diligence?

Before the next part, I'd like to clarify my position on what i think PG is aiming to achieve (I understand we might not all be on the same page on this): I think the PG is meant as an incentive to provide upside to prevent people from leaving protocol work for jobs with a higher direct upside (i.e, companies with stocks/tokens). This tends to often happen in the 1-3y marks when people might have made their first "Big" changes to the protocol and PG aims to offset that by providing members the upside to continue working on the protocol during the years they might have the highest impact.

Coming to the bar for external contributors, perhaps an easy number is 1 year instead of 6 months? If a person is a part of a client team, they tend to have a lot more support and are usually "assigned" tasks that would help them easily contribute to the core protocol. Coming as an external contributor has its own friction and perhaps if they did stick around for a 1y timeframe and have impressed a PG enough member enough to make a nomination, then its in Ethereum's interest to keep them around instead of letting them move on to other challenges?

[mehdi-aouadi]

I agree with @potuz that it's hard to evaluate external contributors work. I think we could consider the PG member who introduces them as a sponsor/mentor and responsable for reporting any change of their contribution if they fail to do so. The introducing PG member and the external contributor, might be considered, in some way, part of a team since they know each other and they have probably been working closely.
I also agree that we could set a higher entry bar for external contributors for the same reason (hard to evaluate their contribution in time and effort) and a 12 months seems fair compared to the 6 months for team members. When working in a team, the candidate have more peers which help they to get the grips more rapidly and their work is evaluated more accurately compared to an external contributor.
To go back to the PG main goal (attracting, encouraging and keeping core devs), external contributors are definitely good candidates and should be encouraged. Their introduction should be diligent and could mean clarifying some rules though.