This post will consider some of the problems I currently see in Optimism Fractal and Eden Fractal and how to fix them. First I present an overview of the motivations (problems) and then I present one potential solution that involves the creation of project-specific fractals to address specific needs of Optimism Fractal while keeping average meeting frequency across all fractals the same as in currently passed proposal.
Motivation
Relationship between meeting cadence vs level of detail and size of contributions
As the period of time between meetings increases people will be able to do more work in between meetings which means that:
- the level of detail in presentations of contributions decreases;
- the impact of the presented contributions increases;
- comprehensiveness for a larger number of people increases (potential userbase (participants of the meeting) and potential audience of recorded videos expands);
Now this relates in an interesting way to the mission of a fractal (and in turn the respect-game prompt of a fractal). The more specific the mission of a fractal the more often it makes sense for people to meet. That's because they are aligned more and benefit an increased level of detail in the presentation of contributions.
On the other hand, a more general mission of a fractal means that a longer time period makes more sense because people will come from vastly different backgrounds, which means that:
- they will be less familiar with each other's work, and so they would benefit from a decreased level of detail in presentations and more impactful contributions being presented (makes respect game process more understandable and valuable for them);
- possibilities of collaboration decrease, which, in turn, means less benefit from more frequent meetings;
Does that make sense?
If it does then I would argue that Optimism Fractal meetings should happen twice as often as EdenFractal meetings.
The need for smaller fractals to test the next versions of fractal apps
Testing (and testing with other people in particular) is a key part of development and if we want our meetings to be friendly for newcomers and not have anything break every other release, we have to test our apps before deploying them to the main fractals. We have to test them in an environment and use cases that are as close to those of production as possible.
The need to separate testing and support from the development of new features
From my experience, successful development requires a combination of different conflicting perspectives. I would express my best current approximation of them like this:
- Delivering - getting things done in a timely manner (hitting deadlines, but scope and quality have to become flexible - you might need to compromise on them);
- Developing - developing a system in a way that does not compromise the quality of a system. Avoiding technical debt (but then timing and/or scope has to become flexible);
- Testing and support - fixing stuff, improving reliability while avoiding big destabilizing changes;
The thing is that these approaches are conflicting - I can apply only one of them at a time, but you need all of them.
Another key thing is that the third mode is often compatible with work on other projects (because it's least demanding most of the time), while the other two are much harder to balance with other projects.
I'm mentioning this because this is relevant to the schedule question which I will consider later.
This is partly inspired by project management triangle.
The need for funding
Funding is a key problem for fractals right now and I think it is time to focus on it. We need to reward contributors to sustain current development and invite more developers.
For the kind of fractals that EdenFractal and OptimismFractal are, we need a unique solution (not something that other DAOs use). Of course, it is up to the community to decide but from my perspective principles on which we have been building these fractals so far would be broken if we adopt any of the solutions other DAOs use.
A lot can be discussed here and I don't think my perspective is perfect. Which brings me to the next point...
The need for more deliberation on key issues of a fractal
One thing we had in EdenFractal that I miss right now is more focused discussions where we try to reach consensus on a key issues of a fractal. This is where a lot of good ideas were born.
Now we Optimism Town Hall, but it is not quite the same. I think partly because in EdenFractal we had a consensus process that required a successful vote during the meeting to pass a proposal. This task to pass or reject a proposal I think is a key ingredient to make discussions more productive and motivate people to join. By "productive" I mean that people come from them having learned something (so it is not just about proposals being passed - I consider a lot of EdenFractal meetings where we did not pass any proposals to have been very productive). Anyway, with a biweekly schedule we will have those meetings even more rarely.
Potential solution: sub-fractal of OF focused on one specific problem
I'm not suggesting going back to what EdenFractal was doing, but I think we can arrive at the same benefits in a different (better) way:
- Create a fractal whose mission would be to solve one specific problem. For example, a fractal with a mission to solve funding problems for Optimism Fractal.
- Structure its meetings into two parts: the first part focuses on proposals, the second on respect game with a prompt - "who contributed the most to the discussion in this meeting".
I think this model (with a more focused goal and opposite meeting structure to what we have now) is superior to what we were doing in EdenFractal. The great thing about this kind of structure is that it awards (with respect) people for listening to each other and integrating each other's perspectives. If someone modifies their proposal to integrate my ideas, I will likely rank him highly in a game about "who contributed most value to the discussion?"
I think we need something like this to solve the funding problem.
A schedule derived from the considerations above
First draft
So we have 3 types of fractals:
- Project-specific (projects of Optimism Fractal);
- Platform specific (Optimism Fractal);
- Eden Fractal (whole fractal ecosystem);
The full cycle would last 7 weeks. Each cycle would be divided into two parts, 4 weeks each, with 1 week in the middle where these parts overlap:
| Weeks | Meetings | App development state |
|---|---|---|
| 1-4 | Project-specific | Testing and support |
| 4-7 | OF and EF | Development |
So new app versions would first be deployed to project-specific fractals and tested and refined there during weeks 1-4. Then once they would reach maturity they would get deployed to Optimism fractal at which point I would start developing a new version.
Week by week schedule of meetings could look like this:
- Project-specific meeting
- Project-specific meeting
- Project-specific meeting
- Project-specific and Optimism Fractal meetings
- Eden Fractal meeting
- Optimism Fractal meeting
- Break from meetings
During the 7th week, people have time to reflect and decide what project-specific meetings to participate in during the next cycle. We could have polls where people would express what meetings they would participate in and at what times. No need to reach consensus on this - people will just gather in meetings that are meaningful for them. I suspect there will be one type of project-specific meeting per week, but there can be more. Furthermore, if there are more than 6-8 people who want to solve a particular issue, or if people are split regarding what time to use, multiple working groups could be formed that would meet at different times.
Key features:
- That's 7 meetings in 7 weeks - the same average frequency of meetings as in the current proposal that was passed;
- 4 project meetings, 2 OF meetings, 1 EF meeting per cycle. 3 levels of fractals, from project-specific to EF encompassing the whole ecosystem, structured according to the "Relationship between meeting cadence vs level of detail and size of contributions" I talked about in the beginning;
- Compatible with the development process of the fractal app in a way where I can focus on participating in specific projects and discussions for Optimism Fractal as well as provide consistent development and support;
- Enable easy transition to big upgrades of a fractal app or even switching to a new fractal app. - Simply create a project fractal for this upgrade and discuss, test, and pass a proposal to start using it there;
- Newest versions would first get tested in smaller project-specific fractals. This makes sense because main OF meetings are core to Optimism Fractal and there is more damage if something does not work in them.
- New people are more likely to join OF and EF first before entering project-specific fractals. I think you will agree that we want newcomers to have a smooth experience, so it makes sense to test in smaller project-specific fractals first;
- Also more frequent meetings reduce the importance of individual meetings (inflation of meetings) which makes fractals with more frequent meetings more suitable for experimenting with new versions of the app (less is at stake);
Conclusion
About half a year ago I wrote an article called "Embracing competition within fractals". Now here, I urge us to come back to consensus building. We need both aspects, but to apply them to the right areas and at the right times.
Competition made more sense at the time of that article when it came to implementations of fractal apps. Firstly because there was no one developing a fractal app at the time for Optimism Fractal, so any kind of development needed to be welcomed. Secondly, because we already had enough consensus building about fractal app design before and even though we did not arrive at consensus it was crucial for me to understand what the needs are and what is more likely to be accepted by the community. This is a key point: if done the right way consensus building process provides benefits even if it does not produce consensus. It creates a very good setting for understanding needs and coming up with ideas.
Now I don't think we had enough consensus building on how to solve funding problems for Optimism Fractal yet, therefore I think it makes sense to start that.
The kind of schedule I propose above creates an environment fitting for both competition as well as consensus building. The first part of a cycle is geared towards consensus building, while the second is more fitting for everyone to develop their own solutions. This should create the right balance between these competing perspectives.