Discussion Post on the Proposed Changes to the 'Core Dev' Structure

[luckyparadise]

Introduction: Proposed Changes to the 'Core Dev' Structure at Filecoin

I am opening this discussion post to address two main objectives:

1. Responding to Suggestions: This section is focused on understanding and addressing the suggestions made to transform the Core Devs group from its current gated, closed nature to an open structure.
2. Aligning on Structure and Format: This section will present arguments and facilitate a conversation about the appropriate structure and format for this group.

Introduction

As Filecoin has scaled and matured, reliance has been placed on existing Core Devs to function in various roles, including governance. In recent months, there has been active discussion about opening the Core Devs group and shifting away from it acting as a governance group. A reference to a previous related discussion is included at the end of this post.

Openness and Diversity

The overall preference appears to lean toward an open group, serving as a technical advisory body. The pros and cons of this approach are evident:

• Pros: Enhances membership, embodies the collective intention for openness, and emphasizes diversity in skills and experiences.
• Cons: Challenges in tracking and gating the group's scope and membership.

The suggestion is to allow open membership for anyone within the ecosystem who meets certain criteria, with the details of this to be openly deliberated by existing members.

The Way Forward: Proposed Changes

The way forward is outlined as follows:

• Open Membership: Allowing for anyone who meets certain criteria to join.
• Coordination: The Filecoin Foundation will continue to moderate the Core Devs, coordinating meetings and invitations.
• Membership Flagging: A process to notify existing Core Devs of new members.

The Ask: Open Questions and Community Input

Open questions:

• How do we define who is a core developer?
• Who qualifies for membership, and how should they express their intention to join?
• How do we clearly identify next steps and move in the direction of effecting these changes

Please weigh in with ideas and suggestions. Sufficient contributions will allow this topic to be added to an upcoming meeting's agenda.

Reference to other posts

For further insights into past discussions regarding the structure and function of Core Devs, review 'Core Dev' Purpose and Structure by Kaitlin Beegle.

[jsoares]

I am generally in favour of opening up core devs and strongly in favour of shifting the group away from governance.

My main comment is that if we want the resulting open group ("open" as in "anyone can join without a voting process") to be a "technical advisory body", there need to be clear rules (e.g. with respect to the technical nature of the contributions) and requirements (e.g. with respect to activity) so that we can maintain a meaningful membership list. Moreover, these rules need to be applied across the board, both to "grandfathered" members and to newcomers.

Without rules and requirements, we end up with a forum rather than a body. There's nothing wrong with the forum model; it just seems duplicative and of limited value, given venues for open interaction already exist, and makes me wonder whether we need core devs at all.

Re the specific questions:

1. How do we define who is a core developer?
   Anyone who joins goes on the list; anyone who's inactive in a set of selected venues (so this can be easily automated) for a quarter (or whatever governance period we end up with?) gets pruned. Pruning is not punishment but a mere administrative action to keep the list current; a former member can always rejoin provided they meet the requirements.

2. Who qualifies for membership, and how should they express their intention to join?
   Any joining criterion should be objective/mechanical, or the group isn't open. One example would be "contributions to a Filecoin-related open source project/repo in the last cycle", which is super broad: contribution includes code but also discussion comments. We could raise the bar if deemed necessary, provided it doesn't depend on the subjective judgement of existing members. The barrier to remain could be higher than the barrier to join.

3. How do we clearly identify next steps and move in the direction of effecting these changes
   We probably need more feedback before going there :)

I'd avoid optimising early for a deluge of newcomers. My expectation is that separating governance from core devs will make this group boring (in a good way), so I'd expect those who join to be genuinely interested and for little gating to be required. I could be wrong, but always best to default to openness and adjust as necessary.

[luckyparadise]

I agree with you @jsoares, we share similar concerns in terms of "overopening" the group. My philosophy at the moment is that Filecoin is at a tipping point and we are not yet mature enough to wholly open membership of the Core Dev group. Perhaps we can revisit the idea of a forum after we have shipped FIP0001v2 and governance role is shifted away from Core Devs solely.

I think in the meantime, we can start documenting these rules and codify clear requirements, roles, responsibilities and expectations of Core Devs. Fortunately/unfortunately, existing Core Devs will need to throw full weight into defining these rules and consenting to these changes.

[anorth]

Openness makes sense if the group doesn't have governance responsibilities. The hard question seems to be how to achieve that (i.e. who else takes them).

[luckyparadise]

Million dollar question! I think with FIP0001v2 this governance burden is likely to be shifted to an extent. I am however keen to hear from you how best we can make this group open but still focused on protocol development.

[Stebalien]

Ideally, most discussion would happen async in FIPs and FIP discussions. Unfortunately, that's rarely sufficient when a FIP reaches the late stages.

I wouldn't make the meetings completely open as they're intended to be a high-context forum for technical discussion on open FIPs and completely open meetings aren't really conducive to such discussions. However, as long as we find a way to separate technical discussions from the issue of governance, I'd be all for making these meetings "more open".

That said,

Enhances membership, embodies the collective intention for openness, and emphasizes diversity in skills and experiences.

I would caution against this as synchronous calls are expensive. I've seen OSS projects run into significant trouble because they were too open. This can be managed in an async setting, but gets very difficult in a synchronous meetings where loud voices can become unmanageable distractions.

I.e., the reason the hacker news comments are such a cesspool: Those with the most time to pontificate are usually the least qualified; everyone qualified has has better things to do than to argue with random people on the internet.

If the core dev calls become too open, the core devs will go elsewhere. This, e.g., happened with the IPFS calls way back in the day because they became too focused on "show and tell"/Q&A so many of the core devs stopped showing up because they had jobs to do. That's not to say that the community calls weren't wonderful and absolutely necessary, but there needs to be a space for high-context technical discussion.

[Stebalien]

One concrete option is to allow "observers" in the core devs call:

1. Ideally the call would open up to Q&A from observers at the end (and comments in chat at any time), but observers wouldn't be able to speak directly, propose topics, etc.
2. Allow for "core devs" to invite non-core devs to present/comment on a particular topic (which we already do anyways).
3. Have a small private session before/after the call to nominate an "observer" as a "speaker". Not a full vote, just a nomination, second, and no strong objections. The base requirement would be "has observed at least one 'recent' core dev meeting" and has contributed meaningfully to Filecoin protocol discussions (either on the call or in FIP discussions).

This kind of setup would allow anyone to come in, watch, and participate without being disruptive or distracting from the technical discussion.

[jdjaustin]

I will echo the sentiments others have expressed (in this and other discussions) about wanting to logistically separate the core devs group from governance. I don't have the solution for how to handle governance outside of core devs or the process for getting there, but I do believe FF/PL are full of smart people who can figure that out given a mandate to do so. It's not a bad thing for core devs to weigh in on governance from time to time, but tasking core devs with governance is a burden that takes time and energy away from implementation, technical knowledge sharing, and coordination among teams.

As far as openness, I think we are afraid of too many "what ifs" in regards to opening up core devs. I am in favor of following the Ethereum model and allowing self-nomination based on contributions to the Filecoin ecosystem. If we are worried about disruptors or detractors, we can put in place mechanisms for dealing with those "what ifs" (e.g., "voting off the island"); however, I think creating a hierarchical core devs structure (based on worries about events which may never even come to pass) creates an administrative overhead/burden which likely isn't really necessary and again, takes time and energy away from more productive efforts.

I recall @jennijuju raising a valid concern about how we would address any potential network vulnerabilities that pop up in the future, and I do think we should have a subset of the core team (e.g., protocol PMs and team leads) identified to address such issues, but that could be something as simple as an ad hoc private channel on Filecoin Slack.