Review: 'Core Dev' Purpose and Structure #121
Replies: 7 comments 10 replies
-
|
What teams would be considered, if we limit the membership to a fixed number of people per team? |
Beta Was this translation helpful? Give feedback.
-
|
Having a cap is not a way of prescribing which teams should or should not be included. As mentioned above, by design, most teams at PL working on Filecoin will be working on some project of relevance to the protocol. This is all well and good, and it should be individuals who are considered for inclusion on their own merits and committed work, rather than building a quota from teams. The purpose of the cap is to introduce a layer of scrutiny, so that we do not have the entire CryptoEconLab or 10 representatives from Filecoin Foundation distorting the group's ability to levy fair governance decisions. It's also a management issue- contributing public work, being engaged with FIPs, etc., is something that I hope more people take time to do, and it's obviously of particular importance for your team's work. However, it should be necessary for the entire team to be on all meetings, etc., as these things can be delegated. Of course we've always had observers and people into meetings when it was relevant, they may just not be standing members. |
Beta Was this translation helpful? Give feedback.
-
|
Hey @kaitlin-beegle! Thanks for capturing the crux of the matter here and potential alternatives. I wanted to briefly touch on some of the mechanisms and philosophies at the Apache Software Foundation for potential inspiration.
|
Beta Was this translation helpful? Give feedback.
-
|
IMHO, the focus on attending a monthly synchronous meeting as a bar for having achieved the context, knowledge, and strategic leadership needed to "review, assess, and elevate technical priorities" for Filecoin isn't the optimal metric for Core Dev engagement in our mostly async community. I get the need to set a bar for knowledge and engagement - however I don't think monthly participation is the right metric due to cyclical constraints on when such a meeting will be valuable and benefit from a particular technical stakeholder. For example, the proofs team may only be needed in a core devs meeting when there is active work on landing a consensus critical proofs change in an upcoming network upgrade (last one was in Q22021, next one will be Q1 or Q2 2022), and for them to attend always just so that they can be a technical steward for the core part of Filecoin they are experts and custodians for, isn't a good use of their time. Similarly, I think someone like Juan will always be a core dev (as the designer and creator of Filecoin - and a key technical steward for how the project continues to evolve), but I wouldn't expect him to attend this meeting every month (only when important / needs his perspective). This is why we have an agenda - so that folks have the opportunity to engage async, and also identify when the subject matter does or doesn't require their expertise. If attendance is required, we don't get to optimize for efficiency/focus. I like Raul's example of a "merit" bar for proposing new core devs - with some ongoing participation requirement that includes both sync and async engagement venues for participating in FIPs, calls, slack, etc as a core dev stewarding technical priorities. Core Devs would then be pruned when they'd been inactive both in sync / async core dev or FIP channels, and stopped participating in technical priority stewardship for the network. Also open to other ideas that support both sync and async participation! |
Beta Was this translation helpful? Give feedback.
-
|
Attendance once a month has the extremely valuable benefit that it's actually measurable. I do think other ongoing async participation/engagement could be part of the picture, an acceptable or maybe even preferable alternative metric. But I think we have to select something where the expectations are clear, so that there's no argument when someone drops out of active engagement. I will put my neck out and dispute both of your examples. You describe the proof team's engagement well, and I would say that it's not necessary for them to be members of a core, engaged governance committee in order to technically steward that part of Filecoin they are experts in. I agree that engaging in governance for everything else could be a poor use of time for anyone not deeply interested in it. They don't need to be on the protocol's standing governance committee in order to contribute technical leadership. Ditto for a number of other teams – if a member wants to be actively involved in governance and put in the time to have high context, they'd be welcome; but I don't think they should get to choose when to flip on or off caring about it. Likewise, I don't think we should say anyone is "always a core dev" – you'll get both good and bad with that. Juan has many other things that he should and does focus on. His engagement (measured by written comms or attendance) in ongoing development of the core Filecoin protocol is minimal. I would love for him to take an active role, and understand why he doesn't. But I don't think we should set a different standard for him. I concur that the ASF-inspired proposal of a group that effectively votes its own members in and out could work well - albeit with a bootstrapping challenge. They key thing is that the membership is clear, and that the requirements for gaining and maintaining that membership are also fairly clear. |
Beta Was this translation helpful? Give feedback.
-
|
One of the things that maybe leads to the perception of need for 'scarcity' of core devs is considering them as a constituent for FIP voting. It seems like part of the role that the core devs have been co-opted to play by being a constituent of FIP voting is to try to represent a view of future potential for the network - we don't want to consider just the opinions of groups using filecoin today, but also the future users and the opportunity potential we may otherwise miss out on. We may want considerate separating participation in 'core devs' and evolution of filecoin protocols and mechanisms from this role of advocating for the future of the network. Developers with a broader view across teams in the ecosystem isn't the worst proxy we can use, but it has it's own biases. It may be worth considering how to optimize the FIP voting aspect of stewardship separately from the other technical alignment work that is associated with the core dev group. |
Beta Was this translation helpful? Give feedback.
-
|
I would not assume that FIP voting in the style of FIP-0036 will be a regular part of governance process. Indeed, whether or not to is a decision for Core Devs as the governing body to make. This governing body is entrusted with the decision-making responsibility – putting it out to a vote from other groups is a bit of a cop-out, IMO (not that polling for sentiment doesn't have a place). So I wouldn't say Core Devs were co-opted to a role of voting. Making that decision was their job in the first place. |
Beta Was this translation helpful? Give feedback.
-
|
The Filecoin "core devs" was formulated based on the Ethereum Core Devs: https://github.com/ethereum/pm. While the Ethereum Core Devs group does intend to "bring together various Ethereum teams who play major roles in determining the direction of the protocol" including "Protocol developers, client developers, and core Ethereum researchers" - it does not aim to be an explicit governance body for the evolution of the protocol or network. Similar to Ethereum, the Filecoin core devs call and slack channel was designed as a forum for discussion and alignment - not a voting body or system, and it WAS unintentionally co-opted to provide a governance "vote" in this case, in a way it shouldn't be, and was not intended for its role and purpose. Totally agree that any FIP voting (hopefully none - any future FIP polls should be purely informational) should happen separately - and the core devs call and communication forum should maintain a good representation of "Protocol developers, client developers, and core Ethereum researchers". |
Beta Was this translation helpful? Give feedback.
-
|
Thanks @kaitlin-beegle this is a great orienting discussion. I think it's particularly valuable to state and ensure we're clear on the purpose. No-one has questioned that yet so I assume general agreement, but perhaps we can get some stronger signal somehow? Your description of the purpose of Core Devs is spot on for me:
The role is governance, not technical contribution. The group is not defined (only) by their expertise or prior work, but by active ongoing engagement in governance itself. I think the Core Devs label causes a bit of trouble here. From various discussions, I've observed two different interpretations:
I have the impression that many people perhaps unfamiliar with the origins consider themselves part of (2.), and then think that the intention is to give everyone in (2) the rights of (1). So I'd raise the possibility that maybe a renaming could help, while we re-constitute the group following these discussions. |
Beta Was this translation helpful? Give feedback.
-
|
I think we made a mistake and have some things backwards here. This effort to strictly define who a core dev is (and who is not), to limit the body of core devs to a certain number of people, and to create secret channels for coordination is a red flag for open-source governance. And this does not touch the decentralized nature of the protocol and the community we are dealing with.
I'm sorry, as I said that I disagree on all points across the board and also that I raised this so late. Reviewing this was triggered by accidentally adding three of the Forest protocol engineers to the core-devs channel on Slack without asking for permission. I would have never guessed that this is an exclusive group (even though the three engineers are working on Filecoin at full capacity). |
Beta Was this translation helpful? Give feedback.
-
|
I basically agree with @q9f said here. I will also add that what Afri is describing here is pretty much how we functioned for many years. Meetings were pretty open, most work happened in public channels, and we didn't really think much before adding Core Devs (and basically never subtracted any, unless they had explicitly asked to be excluded). I think the FIP-0036 (and subsequently FIP-0056) experiences necessitated a lot of the changes that moved us away from that model. This was basically because the Core Devs role as a "governing body" grew in scope considerably. I think the changes we made were (and are) important if we want the Core Devs to act as analysts of community sentiment, or otherwise arbitrate difficult decisions. I personally do not think we should ask Core Devs to do so (I do not personally want to play that role myself). This is somewhat avoidant -- someone (or some group of people, or some process) IS still going to be necessary to make difficult decisions. I think Core Devs certainly have a role to play in those decisions, thanks to our deep familiarity with the Filecoin protocol, as well as experience with other Web3 projects that may have faced similar problems. I think our role is especially important when we need to raise security blockers to proposed changes. But having us vote as a group on contentious community decisions in which our various different teams may have differing perspectives or interests is difficult, and necessitates this group's membership being guarded in a manner that I personally dislike. |
Beta Was this translation helpful? Give feedback.
-
|
I apologize for not vocalizing this before, despite MANY requests for feedback. I was never happy with the proposed changes, but they also seemed reasonable and necessary enough that I was disinclined to express opposition. More broadly, I think we may have something of a problem with Core Devs, especially my teammates on Lotus (and especially me personally!) disliking engaging with the "process". I think a lot of us just want to be able to have what we need to secure and improve the network, but are somewhat reluctant to express our opinions on how we can get there. (Apologies if I'm pushing my own personal experience onto others :D) |
Beta Was this translation helpful? Give feedback.
-
|
I agree with most points mentioned in this thread and would advocate more teams/groups to work in open. There is a need for one “secret” channel to disclose and coordinate security issuers before it goes in public imho - other than that, I don’t see any of the work we do needs “privileged access”. One flag I have is related to the point raised here
I have always taken, and constantly emphasized that being titled as a core dev is not a privilege , but means commitment to responsibilities: actively and constantly engage and review new fip discussions, facilitating aligning the problem & enhancement needed for Filecoin network, provide technical guidance to help forming and shaping the solution, and in addition importantly for me/my team(or anyone that can) contribute to the code base to make things happen. In addition, I also think have a deep and broad overview of the state of the art of filecoin from different perspectives (protocol, data client, SP, token holders, builders, ecosystem development) is important to help facilitate prioritization & alignment of finalization of the accepted fips via network upgrades - and this is one of the core devs core responsibilities as well. It’s already the case that ANYONE can participate in FIP discussion and upgrades discussion as all happens in public forums. And it is already the case anyone can propose agendas to be discussed in the open core dev calls & one can easily join and engage as an observer. To me being a core dev only means more “enforcement” - as in it is your duty to engage and contribute to filecoin protocol evolvement. The more people willing to take these responsibilities reliably, the better for progressing the network protocol! |
Beta Was this translation helpful? Give feedback.
-
|
With that being said, I think it is important to define a clear expectation of a core dev & the goal of core dev calls so to be productive. I like to use the Ethereum one as a quick reference
|
Beta Was this translation helpful? Give feedback.
-
|
Hey @q9f - I don't disagree what your saying; I think @arajasek has the appropriate context. What you're describing as a technical review body is structurally different from the description of Core Devs as governing body. And when our governance processes were overloaded, and we had no options, we ended up needing to squeeze Core Devs into a model that folks clearly don't like. In fact, it has worked for no one, but had been sort of a necessary evil for a long time. We're working on a system of changes to FIP0001 that I hope removes Core Devs from being in a place to govern at all. IMO we could certainly facilitate a more effective, open group- this just wasn't possible when there was no other decision making body or mechanism to process high-risk, high-complexity FIPs. @luckyparadise can help draft updated guidance for the group, if you'd like. |
Beta Was this translation helpful? Give feedback.
-
|
I am inclined to pick up this discussion and throw some weight behind what is being proposed by @kaitlin-beegle. I am afraid we have come to that point where we need to enforce participation standards for this group. Core Devs should bear a sense of responsibility that comes with the role, which should mean there should be a minimum level of effort and commitment by all Core Devs. These responsibilities could be;
I recommend that these commitments are tracked and Core Devs who are not actively participating will be contacted to re-establish their membership or consider leaving the group. At this point, many teams are nucleating or leaving the ecosystem, this and many more could be reasons we are seeing a significant drop in interest and participation from existing Core Devs. Proposed Next Steps:
|
Beta Was this translation helpful? Give feedback.
-
For over a year, myself and others have been working to assess and define what it means to be a 'Core Dev'. There are different functional models for 'Core Devs' in other open-source ecosystems; our goal is to devise definitions, norms, and- ultimately, an institution- that is unique to the Filecoin community.
Activity around FIP0036 drove renewed attention to this goal, as well as an uptick in demand for a broader swath of community members to be counted as 'Core Devs'. Managing to this increased expectation surfaced a misalignment between community members as to the purpose and structure of the 'Core Dev' designation.
The purpose of this document is to realign expectations for 'Core Devs' so that we can ensure that 1) coordination needs are being met, and 2) norms for good governance are being established.
Purpose
There are many instantiations of 'Core Devs' across open source projects- some denote technical maintainers, others indicate governing authority, some are highly technocratic, and others less so.
Within the Filecoin ecosystem, Core Devs ought to be a technical governing body that provides the ecosystem with decision-making capacities. This is similar to how other low-layer, blockchain protocols utilize 'Core Devs', and addresses a clear and specific need within the Filecoin ecosystem.
Ideally, Core Devs are an engaged and knowledgeable group who offer their time and expertise in exchange for privileged governing rights. To this end, 'Core Devs' operate much like a technical counsel, weighing in on governing issues and other high-level topics of interest and concern to the protocol.
The size of the 'Core Dev' body matters less than having members who are engaged and knowledgeable beyond their immediate work domain. There are many individuals whose expertise could qualify them as being 'core' to the protocol; what ought to differentiate these people from named 'Core Devs' is the latter's commitment to governing the ecosystem and participating in the strategic development of the protocol above and beyond their immediate domain.
Ultimately, Core Devs opt to review, assess, and elevate technical priorities, uniting a cross-section of expertise across protocol operations. Filecoin has the resources and staff talent necessary to address specific management needs and decisions in other arenas. Removing rote technical coordination from the context of meetings is one improvement area we've been moving towards in order to better align the content of meetings with the purpose of the group.
A frequent challenge within Filecoin governance is balancing standards and ideals (i.e., the operational best practices that will allow us to scale sustainably) with the practical demands of everyday work. It is my hope that FIP0036 provided evidence of why it's important to consider the former when setting policies and procedures for core operational units, including Core Devs.
Structure
After several months of trial and error, existing Core Devs (or, at least those who were attending meetings and engaging on Slack) agreed to the following structure:
More recently, and following FIP0036, we also discussed introducing:
The purpose of the above is not to exclude or generate competition. It is simply intended to ensure that there is a clear marker for who is a Core Dev, and that the threshold for participation is high enough (i.e., attending a meeting once per month, barring timezone difficulties) that those who attend are invested in actively participating.
We saw during and prior to the FIP0036 process that the 'Core Dev' label is meaningless when applied broadly and without standards.
I greatly welcome feedback on the above, and expect we will continuously iterate depending on needs. However, I do ask that suggestions prioritize the goals and objectives of the group. We should be flexible around considering the needs of participants who want to be included in the group and have a legitimate reason why existing standards are a challenge for them. However, we have grown too large to consider everyone's preferred optimizations, and cannot base significant design choices around constraints that do not serve the entire group.
Existing Knowledge and Open Questions
We learned, after months of trials and iterations, that:
Currently, I'm wondering...
Lastly, once we're more agreed, we should publish the list of current Core Devs, and should update the name of this repo for consistency's sake :)
Beta Was this translation helpful? Give feedback.
All reactions