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.
As the period of time between meetings increases people will be able to do more work in between meetings which means that:
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:
Does that make sense?
If it does then I would argue that Optimism Fractal meetings should happen twice as often as EdenFractal meetings.
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.
From my experience, successful development requires a combination of different conflicting perspectives. I would express my best current approximation of them like this:
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.
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…
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.
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:
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.
First draft
So we have 3 types of fractals:
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:
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.
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.