Hi @jameskbh, thanks so much for your comment!
In crafting this proposal, we intentionally avoided language like “roadmap” or “deliverables” because we strongly agree with the spirit of @markus’ comment here.
In short, we interpret this as follows:
- Grant proposals are for funding projects. A project is a clear scope of work where the end goal is some tangible output for the ecosystem. As such, these have concrete deliverables, and it may make sense for a prospective grantee to provide a roadmap/Gantt chart.
- Service Provider proposals are for funding teams. A team fits an ongoing role within the ecosystem and has a fundamental mission. An SP should be funded with the expectation that this particular team will fill this particular role in perpetuity - until the team decides to disband or until a better team comes along.
We believe that long-term roadmaps don’t make much sense for an Integrations team. Integrations work is primarily reactive; we observe and respond to trends in the developer ecosystem, fill gaps wherever we see them, and help non-technical teams with whatever they need in close to real time. We prefer to plan over shorter time horizons (e.g., 1 month) because we have found that it is often futile to plan for longer periods (e.g., 5 months).
In January of this year, we were in the midst of several Linear Pool integrations when the read-only reentrancy vulnerability was discovered. We had to put most of that work on hold and spend the better part of a month working with partners to safeguard funds. In the end, we saved over $4,000,000, but it blew a hole in our long-term roadmap. Similarly, over the past couple of weeks, Aave has shown reinvigorated interest in migrating their Safety Module from Balancer V1 to V2. Rather than sticking strictly to our current roadmap, we believe it is best to dedicate significant time to helping one of Balancer’s highest-value partners.
So, moving forward, we prefer to take a more adaptable stance and eschew the notion of a long-term roadmap in favor of a priority-based framing. Each of our monthly community forum updates will inclue:
- Work completed over the month, so that the community has an opportunity to examine our team’s output.
- Changes in core metrics, both all-time and month-over-month, to show the community how our output directly impacts the Balancer protocol.
- Our strategy for the following month, especially highlighting any changes since the previous month, so that the community has an opportunity to provide feedback or ask questions. The strategy will focus on “why” rather than “what” - instead of a list of deliverables to be completed on a timeline, it will be a list of priorities according to which we filter all incoming opportunities. A working hypothesis will accompany each priority.
Tomorrow, we will post our update for the month of June, and we will include a list of the current top priorities for review. We haven’t yet started working under our new SP, but we will try to shift our updates more and more towards the new SP framework over the next few months. We are not yet ready to include the metrics section, as we need time to put together the correct data pipelines, but we hope that can be ready for our July or August update.